Oh, I see. Do you happen to remember where that lock is acquired/released? I saw the up/down macros in the eCos code at the points where the RTEMS mutex_lock/unlock would be called (e.g. in jffs2_new_inode). up/down end up calling Cyg_Mutex::unlock/lock, which aren't empty, so it seems that there's a bit of fine-grained locking there.
On Thu, Dec 3, 2015 at 3:19 AM, Sebastian Huber <sebastian.hu...@embedded-brains.de> wrote: > Hello, > > I used the eCos port of JFFS2 as a base for the RTEMS port. Like in eCos, a > global lock for a JFFS2 file system instance is used. > > ----- Martin Galvan <martin.gal...@tallertechnologies.com> schrieb: >> Hi everyone! I'm working on porting F2FS from Linux based on the JFFS2 >> port Sebastian did. When inspecting the code I found that >> libfs/jffs2/include/linux/mutex defines struct mutex to be empty, and >> all the mutex-related functions to do nothing. >> >> This seems to imply that there's no concurrency management in the >> JFFS2 code. Is this intentional? Should I do the same when porting >> F2FS? > > -- > Sebastian Huber, embedded brains GmbH > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > Phone : +49 89 189 47 41-16 > Fax : +49 89 189 47 41-09 > E-Mail : sebastian.huber at embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. -- Martin Galvan Software Engineer Taller Technologies Argentina San Lorenzo 47, 3rd Floor, Office 5 Córdoba, Argentina Phone: 54 351 4217888 / +54 351 4218211 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
