Timeline
10/29/21:
- 17:12 Ticket #4540 (Healthcare Mailing Lists) closed by Joel Sherrill
- invalid
- 17:08 Ticket #4540 (Healthcare Mailing Lists) created by Albert
- Removed all links as spam.
- 06:27 Ticket #4539 (rtems_filesystem_table compile) created by chenjin_zhong
- Hi, when the macro CONFIGURE_APPLICATION_DISABLE_FILESYSTEM is …
10/28/21:
- 18:29 Ticket #4536 (acess JFFS2 sb->s_root) closed by Sebastian Huber
-
invalid: Replying to chenjin_zhong:
> Replying to Sebastian Huber:
> > Thanks for your interest in the RTEMS port of JFFS2. If you have questions, then you could also ask them on the devel@… mailing list. The RTEMS port of JFFS2 does not use a file system internal locking. There is a global lock for each JFFS2 instance:
> > {{{#!c
> > static void rtems_jffs2_do_lock(struct super_block *sb)
> > {
> > rtems_recursive_mutex_lock(&sb->s_mutex);
> > }
> >
> > static void rtems_jffs2_do_unlock(struct super_block *sb)
> > {
> > rtems_recursive_mutex_unlock(&sb->s_mutex);
> > }
> > }}}
>
> Suppose that a GC thread or other thread/task calls jffs2_garbage_collect_pass, and then operates sb->s_root by jffs2_iget.meanwhile, the main task accesing sb->s_root. a global lock for each JFFS2 instance can't work.
It is not a high performance approach, but it works. See
testsuites/fstests/fsjffs2gc01/init.c
. - 18:26 Ticket #4538 (mutex is not initilaized in jffs2_read_inode) closed by Sebastian Huber
-
invalid: Replying to chenjin_zhong:
> Replying to Sebastian Huber:
> > Yes, the f->sem is an empty structure, it is not initialized, it is not used, locked or whatever in RTEMS. This is intentional and not a bug. I repeat: The RTEMS port of JFFS2 does not use a file system internal locking. There is a global lock for each JFFS2 instance.
>
> Thank you! I got it. but we Suppose that a GC thread or other thread/task and main task calls jffs2_do_readinode simultaneous. a global lock for each JFFS2 instance can't work.
It is not a high performance approach, but it works. See
testsuites/fstests/fsjffs2gc01/init.c
. - 15:07 Ticket #4538 (mutex is not initilaized in jffs2_read_inode) reopened by chenjin_zhong
- 14:53 Ticket #4536 (acess JFFS2 sb->s_root) reopened by chenjin_zhong
- Replying to Sebastian Huber: > Thanks for your interest in the RTEMS port of JFFS2. If you have questions, then you could also ask them on the devel@… mailing list. The RTEMS port of JFFS2 does not use a file system internal locking. There is a global lock for each JFFS2 instance: > {{{#!c > static void rtems_jffs2_do_lock(struct super_block *sb) > { > rtems_recursive_mutex_lock(&sb->s_mutex); > } > > static void rtems_jffs2_do_unlock(struct super_block *sb) > { > rtems_recursive_mutex_unlock(&sb->s_mutex); > } > }}} Suppose that a GC thread or other thread/task calls jffs2_garbage_collect_pass, and then operates sb->s_root by jffs2_iget.meanwhile, the main task accesing sb->s_root. a global lock for each JFFS2 instance can't work.
- 14:45 Ticket #4537 (mutex is not initilaized in jffs2_new_inode) closed by Sebastian Huber
- invalid: Yes, the f->sem is an empty structure, it is not initialized, it is not used, locked or whatever in RTEMS. This is intentional and not a bug. I repeat: The RTEMS port of JFFS2 does not use a file system internal locking. There is a global lock for each JFFS2 instance.
- 14:43 Ticket #4538 (mutex is not initilaized in jffs2_read_inode) closed by Sebastian Huber
- invalid: Yes, the f->sem is an empty structure, it is not initialized, it is not used, locked or whatever in RTEMS. This is intentional and not a bug. I repeat: The RTEMS port of JFFS2 does not use a file system internal locking. There is a global lock for each JFFS2 instance.
- 14:42 Ticket #4537 (mutex is not initilaized in jffs2_new_inode) reopened by chenjin_zhong
- 14:40 Ticket #4538 (mutex is not initilaized in jffs2_read_inode) reopened by chenjin_zhong
- Replying to Sebastian Huber: > Thanks for your interest in the RTEMS port of JFFS2. If you have questions, then you could also ask them on the devel@… mailing list. The RTEMS port of JFFS2 does not use a file system internal locking. There is a global lock for each JFFS2 instance: > {{{#!c > static void rtems_jffs2_do_lock(struct super_block *sb) > { > rtems_recursive_mutex_lock(&sb->s_mutex); > } > > static void rtems_jffs2_do_unlock(struct super_block *sb) > { > rtems_recursive_mutex_unlock(&sb->s_mutex); > } > }}} I have compared it with Linux JFFS2. The peice of source code in Linux is as follows,As shown in black-body section, the f->sem is not be initialized and locked in RTEMS. […]
- 05:20 Ticket #4538 (mutex is not initilaized in jffs2_read_inode) closed by Sebastian Huber
- invalid: Thanks for your interest in the RTEMS port of JFFS2. If you have questions, then you could also ask them on the devel@… mailing list. The RTEMS port of JFFS2 does not use a file system internal locking. There is a global lock for each JFFS2 instance: […]
- 05:20 Ticket #4537 (mutex is not initilaized in jffs2_new_inode) closed by Sebastian Huber
- invalid: Thanks for your interest in the RTEMS port of JFFS2. If you have questions, then you could also ask them on the devel@… mailing list. The RTEMS port of JFFS2 does not use a file system internal locking. There is a global lock for each JFFS2 instance: […]
- 05:19 Ticket #4536 (acess JFFS2 sb->s_root) closed by Sebastian Huber
- invalid: Thanks for your interest in the RTEMS port of JFFS2. If you have questions, then you could also ask them on the devel@… mailing list. The RTEMS port of JFFS2 does not use a file system internal locking. There is a global lock for each JFFS2 instance: […]
- 05:19 Ticket #4535 (acess JFFS2 sb->s_root question) closed by Sebastian Huber
- invalid: Thanks for your interest in the RTEMS port of JFFS2. If you have questions, then you could also ask them on the devel@… mailing list. The RTEMS port of JFFS2 does not use a file system internal locking. There is a global lock for each JFFS2 instance: […]
10/27/21:
- 15:13 Ticket #4538 (mutex is not initilaized in jffs2_read_inode) created by chenjin_zhong
- HI, I have found when call jffs2_read_inode to read inode. the f->sem …
- 14:59 Ticket #4537 (mutex is not initilaized in jffs2_new_inode) created by chenjin_zhong
- HI, I have found when call jffs2_new_inode to create inode. the f->sem …
- 14:47 Ticket #4536 (acess JFFS2 sb->s_root) created by chenjin_zhong
- Hi, I have found when access global structure without mutex or …
- 14:34 Ticket #4535 (acess JFFS2 sb->s_root question) created by chenjin_zhong
- Hi, I have found when access global structure without mutex or …
- 07:40 Ticket #4534 (SMP EDF scheduler violates priority group ordering) created by Sebastian Huber
- The SMP EDF scheduler supports one-to-one and one-to-all thread to …
10/25/21:
- 06:10 Ticket #4528 (rate monotonic: reset of CPU usage time not always detected) closed by Sebastian Huber <sebastian.huber@…>
- fixed: In [changeset:"feb46875584c05f0dbd005e4b4e7eaa1af414d88/rtems-docs" feb4687/rtems-docs]: […]
- 02:55 Ticket #4533 (libdebugger should only build for archs with a backend) closed by Chris Johns <chrisj@…>
- fixed: In [changeset:"3f0ad2b3b70d62bee6b2effb4ff9b31650aff726/rtems" 3f0ad2b/rtems]: […]
10/21/21:
- 02:04 Ticket #4533 (libdebugger should only build for archs with a backend) created by Chris Johns
- Libdebugger has limited backend support however the generic parts are …
10/20/21:
- 05:37 Ticket #4532 (Priority inversion issues with MrsP locking protocol implementation) created by Sebastian Huber
- While a thread is scheduled on a helping scheduler, while it does not …
- 05:32 Ticket #4531 (Data corruption in SMP schedulers) created by Sebastian Huber
- Certain operations involving sticky thread queues, thread to processor …
10/19/21:
- 13:49 Ticket #4218 (aarch64 as internal error with spconfig01) closed by Ryan Long <ryan.long@…>
- fixed: In [changeset:"e04fddccf9ecf187c6b66b7caf61f64af24c4f0a/rtems-source-builder" e04fddc/rtems-source-builder]: […]
10/18/21:
Note: See TracTimeline
for information about the timeline view.