See
struct _rtems_filesystem_operations_table {
rtems_filesystem_mt_entry_lock_t lock_h;
rtems_filesystem_mt_entry_unlock_t unlock_h;
...
};
On 03/12/15 15:30, Martin Galvan wrote:
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.
--
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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
