Concurrency in JFFS2?

[Sebastian Huber]

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.huber at 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.galvan at 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.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.