Hello Charles, ----- Am 30. Jan 2020 um 23:51 schrieb Charles Manning cdhmann...@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. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
