RTEMS FS locking

[Chris Johns]

On 31/1/20 12:48 pm, Charles Manning wrote:
> 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.

Reach out to me if you need a hand. We have the ability to run tests on hardware
with the rtems-test command.

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

Awesome.

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

I think so. I suppose looking at the handler that get hooked to do the locking
would help. I am not sure if it a default one or set by each FS. Sebastian did
these changes and he is back next week.

Chris