RTEMS FS locking

[Sebastian Huber]

Hello Charles,

----- Am 30. Jan 2020 um 23:51 schrieb Charles Manning cdhmanning at gmail.com:

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

do you intend to do a clean room re-implementation of the RTEMS YAFFS2 support under the YAFFS2 dual licensing conditions?

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

The RTEMS file system layer is a home grown solution which evolved over time. Originally, it had no locking. Some years ago I introduced a new path evaluation scheme which uses a global file system instance lock. All current RTEMS file systems re-use this lock for other operations. In theory, operations which work on file system nodes (rtems_filesystem_file_handlers_r) could use finer grained locking. There is no high level documentation available. It would be good to document the locking in the Doxygen documentation:

https://docs.rtems.org/doxygen/branches/master/group__LibIOFSHandler.html

The YAFFS2 and JFFS2 code are good examples.