This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: jffs2 garbage collection
- From: Andrew Lunn <andrew dot lunn at ascom dot ch>
- To: "Koeller, T." <Thomas dot Koeller at baslerweb dot com>
- Cc: "ecos-discuss (E-Mail)" <ecos-discuss at sources dot redhat dot com>
- Date: Fri, 27 Jun 2003 10:27:35 +0200
- Subject: Re: [ECOS] jffs2 garbage collection
- References: <850597605E79D21182830008C7A4B9CF1EB4260E@COMM1>
> Another question, if my multithreaded application
> is running from flash, do I have to lock/unlock the
> scheduler before and after writing data to a file,
> if the application code and the file system share
> the same physical flash chip? This would of course
> be unacceptable, given the time it takes to erase a
> sector.
Interrupts have to he disabled and scheduling locked. Otherwise you
risk a crash while the flash is in programming mode. There isn't
really any choice about it when your application is running from
flash. If you cannot live with this, you need your application to run
from RAM.
You the application programs should not have to deal with this
IMHO. The underlying flash drivers should sort this out. This has been
talked about before on the list, but i don't remember the outcome. ie
does the locking actually happen automatically.
Andrew
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss