RTEMS FS locking

[Chris Johns]

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.

> 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?

> 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.

Chris