This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Linux synthetic target & JFFS2
- From: Andrew Lunn <andrew dot lunn at ascom dot ch>
- To: "Koeller, T." <Thomas dot Koeller at baslerweb dot com>
- Cc: "'Andrew Lunn'" <andrew at lunn dot ch>, "ecos-discuss (E-Mail)" <ecos-discuss at sources dot redhat dot com>
- Date: Tue, 19 Aug 2003 14:19:23 +0200
- Subject: Re: [ECOS] Linux synthetic target & JFFS2
- References: <850597605E79D21182830008C7A4B9CF1EB4264D@COMM1>
On Tue, Aug 19, 2003 at 02:06:15PM +0200, Koeller, T. wrote:
> This seems to be a misunderstanding. I understand that the
> option in question controls whether writing to the memory region
> (the simulated flash) modifies the underlying file as well, just
> like the description says.
Actually, the description does not say that. Well, not the way i
understand the English. It say "contents of the emulated flash". It
does not mention the memory region. So to me this means its talking
about modifying the contents using the API and not about writing
directly to the mapped region.
> I am not talking about the effects of running two synth processes in
> parallel, nor do I want the simulated flash to be read-only. I also
> do not quite understand why someone would use lseek() or other
> File-I/O functions if the file is memory mapped.
The file is mapped as a read only region since writing to the mapped
memory by an application is obviously a bug. It should be using the
flash API to change the content. But since the region is read only,
the flash functions themselves cannot write to the region. So file I/O
is the simplest option to actually make changes.
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