RTEMS FS locking

[Charles Manning]

On Fri, Jan 31, 2020 at 12:09 PM Chris Johns <chrisj at rtems.org> wrote:
>
> On 31/1/20 9:51 am, Charles Manning wrote:
> > I'm the Yaffs Guy and have been asked to do some work refreshing the
> > Yaffs core code that is in Sebastian's rtems-yaffs git as well as
> > integrate it into the Yaffs tests.
>
> Excellent and welcome.

Thanks.

Over the last few years we've seen a lot of interest in Yaffs in the
space segment and RTEMS seems to have made good inroads there.
A lot of this interest stems from Yaffs working well on raw NAND
(rather than managed NAND like eMMC) and people prefer raw NAND in
satellite applications.
We're building RTEMS into our test harnesses ("test farm" would be
over-egging the pudding) so that we can keep the RTEMS wrapper fresh.

Hopefully this will also help row the  RTEMS "eco-system" forward.

>
> > After a few false starts I now have an understanding of how to build a
> > simulation test environment based on the quickstart guide - thanks to
> > those that helped me.
>
> Nice. Which BSP?

I used the quickstart HowTo and using erc32 and followed on from there.
I am using a simulator because that allows me to run something
relatively easily on a tests system without extra HW etc.

>
> > When going through Sebastian's wrapper I noticed that some functions
> > are locked with the yaffs lock and some are not. At first I thought
> > that might be a locking bug, but then I noticed that some higher level
> > functions call rtems_filesystem_instance_lock() and some do not.
> > rtems_filesystem_instance_lock() results in the yaffs lock being
> > taken, so that is all good.
> >
> > Can someone please explain the rationale for when
> > rtems_filesystem_instance_lock is used and when not?
>
> It is a file system level interface to a specific file system's lock so higher
> level operations can be grouped together to make a transaction. Calls to other
> file systems can happen concurrently.
>
> For example have a look at the call `fchmod` ...
>
> https://git.rtems.org/rtems/tree/cpukit/libcsupport/src/fchmod.c#n65
>
> The implementation does a file system `fstat_h` handler call and then a
> `fchmod_h` handler call. With the lock held this sequence cannot be interrupted
> on this file system.

Ah, Ok, so basically this is used where locking is absolutely requires
at the whole-fs level and the default is to allow the FS to do its
only locking as required. Is that a reasonable summary?

Thanks

Charles

>
> Chris