From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 707 invoked by alias); 27 Nov 2003 09:36:38 -0000 Mailing-List: contact ecos-discuss-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@sources.redhat.com Received: (qmail 685 invoked from network); 27 Nov 2003 09:36:34 -0000 Received: from unknown (HELO imladris.demon.co.uk) (193.237.130.41) by sources.redhat.com with SMTP; 27 Nov 2003 09:36:34 -0000 Received: from localhost.localdomain ([127.0.0.1]) by imladris.demon.co.uk with esmtp (Exim 4.22) id 1APIZW-0004i4-LS; Thu, 27 Nov 2003 09:36:26 +0000 From: David Woodhouse To: Vincent Catros Cc: ecos-discuss@sources.redhat.com In-Reply-To: <000001c3b4c7$023894e0$7407a8c0@figuier> References: <000001c3b4c7$023894e0$7407a8c0@figuier> Content-Type: text/plain Message-Id: <1069925786.18076.8.camel@imladris.demon.co.uk> Mime-Version: 1.0 Date: Thu, 27 Nov 2003 09:36:00 -0000 Content-Transfer-Encoding: 7bit X-SA-Exim-Mail-From: dwmw2@infradead.org X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Subject: [ECOS] Re: RE : [ECOS] Is JFFS2 thread-safe? X-SW-Source: 2003-11/txt/msg00415.txt.bz2 On Thu, 2003-11-27 at 10:15 +0100, Vincent Catros wrote: > If I understand, JFFS2 should be thread safe, but this has never been > tested since multual access is avoided by fileio layer when using > CYG_SYNCMODE_FILE_FILESYSTEM flag? The core code of JFFS2, which is shared by both Linux and eCos ports, is definitely thread safe -- assuming the semaphore and spinlock operations from Linux are mapped to the correct locking primitives under eCos. I wonder if spin_lock() should be mapped to a preemption lock. This locking is documented in the file README.Locking. The eCos-specific code of JFFS2 lacks locking on its _own_ inode cache data structures (i.e. struct _inode, not anything used by the JFFS2 core). In particular the i_cache_{next,prev} lists and the use counts (i_count) need protection, to deal with simultaneous jffs2_iget() and jffs2_iput() of the same inode, etc. That is all currently protected by the CYG_SYNCMODE_FILE_FILESYSTEM flag, but ideally we'd be able to lose that flag and provide our own finer-grained locking. Currently, if the garbage collect thread is implemented (I've put in place only a skeleton), it would need to LOCK_FS(mte) before calling into jffs2_garbage_collect_pass(). That would prevent even _read_ activity during the GC pass, which is suboptimal. -- dwmw2 -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss