Re: Concurrency in JFFS2?
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 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 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
[PATCH] Store task_id of the current thread for the ISR before waiting for the transient event
The ISR will send a transient event to the task specified in bus->taskid.
Make sure that the correct task_id is written to this field before waiting
for the transient event to arrive.
Fixes #2483
---
c/src/lib/libbsp/arm/raspberrypi/i2c/i2c.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/c/src/lib/libbsp/arm/raspberrypi/i2c/i2c.c
b/c/src/lib/libbsp/arm/raspberrypi/i2c/i2c.c
index 14a2467..6d9a2cd 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/i2c/i2c.c
+++ b/c/src/lib/libbsp/arm/raspberrypi/i2c/i2c.c
@@ -92,6 +92,7 @@ static int rpi_i2c_bus_transfer(rpi_i2c_bus *bus)
/* Sleep until the TX FIFO has free space for a new write. */
if (
+ bus->task_id = rtems_task_self();
rtems_event_transient_receive(RTEMS_WAIT, bus->base.timeout) !=
RTEMS_SUCCESSFUL
) {
--
1.9.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Concurrency in JFFS2?
On 12/04/15 01:30, Martin Galvan wrote: Oh, I see. Do you happen to remember where that lock is acquired/released? Have a look here ... https://git.rtems.org/rtems/tree/cpukit/libfs/src/jffs2/src/fs-rtems.c#n318 Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 0/6] rtems-source-builder patche series for graphic libraries
On 12/01/15 20:44, Pavel Pisa wrote: Hello Chris, On Monday 30 of November 2015 22:52:28 Chris Johns wrote: On 30/11/2015 10:16 AM, Pavel Pisa wrote: I have applied your patches on RSB master the result is identical to the last one with updated libPNG. I have rerun build and all packages has build OK. Thanks. Joel, please, apply patches. I am looking at them now. please, push them first to master branches of git.rtems.org/rtems-source-builder.git and t1lib-5.1.2.diff git.rtems.org/rtems-tools.git I will. I am just sorting out the release things in the RSB first. I expect these changes to not break these patches but I want to get the release working. As the other progress, I have received confirmation from Greg Haerr for pushing the first round of RTEMS related patches to Microwindows/Nano-X mainline https://github.com/ghaerr/microwindows Nice. Great to see Greg about and accepting patches. so we can switch after more testing the RSB Microwindows source to the real Microwindows mainline and get rid of local patches in next development steps. But I consider commiting actual tested state to RSB as the right step now. Excellent. Many thanks for looking after this for us. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Concurrency in JFFS2?
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
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 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
