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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
