[ECOS] File access under linux synthetic target

[ECOS] File access under linux synthetic target

[Andrew Over]

Hi.

For various reasons, I'd like to be able to get at native files from
under the linux synthetic target.  I also need fseek and ftell.
Before I started coding, I thought it might be an idea to get others
opinions on the "best" way to do this.

Out of interest, has anyone done any work along these lines?

My current plan is to hack the cyg_devio_table_t to include a few
extra functions (open, close, seek), fix the stdio code to use the new 
callbacks, add a new device which implements native file access under
the synthetic target, and hope not to break anything in the process :)

Suggestions welcome :)

Cheers,
--Andrew

Re: [ECOS] File access under linux synthetic target

[Andrew Lunn]

> For various reasons, I'd like to be able to get at native files from
> under the linux synthetic target.  I also need fseek and ftell.
> Before I started coding, I thought it might be an idea to get others
> opinions on the "best" way to do this.
> 
> Out of interest, has anyone done any work along these lines?

I've used the undocumented back door to the host OS to do write access
to files. I just needed to be able to log results from a test runs to
a file so the demands were pritty low and quite easy to do using the
back door. I'd consider this a hack rather than the "best" way to do
this. You have to be very carefull with the backdoor. If its blocks
the who of eCos blocks, not just a single thread.

How would i do it in a better way? I think i would look at the pseudo
device driver work thats been mentioned here lately. That will take
care of the blocking issue. I'd look at implementing a generic file
system interface for ecos, one with the standard calls, mount, umount,
open, close, read, write & seek. Under this interface i'd write a very
simple 'network file system' protocol which talks to a virtual device
which does all the real work with the filesystem.

File systems support is something that comes up quite often on the
mail list, probably second to TCP/IP. Now that TCP/IP is in beta, i
personally think this is the next thing RedHat should work on. Not the
file systems themselves, but the generic part, libc down to the
generic interface to the file system. I don't think they should work
on specific filesystems since the requirements are so wide, FLASH,
NFS, RAM Discs and even real drives. Let people contribute such file
systems, or contract RedHat for a specific filesystem. Specifying the
generic interface is the important thing or we will end up with lots
of incompatible file systems.

        Andrew

Re: [ECOS] File access under linux synthetic target

[Gary Thomas]

On 03-Apr-00 Andrew Lunn wrote:
> File systems support is something that comes up quite often on the
> mail list, probably second to TCP/IP. Now that TCP/IP is in beta, i
> personally think this is the next thing RedHat should work on. Not the
> file systems themselves, but the generic part, libc down to the
> generic interface to the file system. I don't think they should work
> on specific filesystems since the requirements are so wide, FLASH,
> NFS, RAM Discs and even real drives. Let people contribute such file
> systems, or contract RedHat for a specific filesystem. Specifying the
> generic interface is the important thing or we will end up with lots
> of incompatible file systems.
> 

Indeed, this is _definitely_ on our "to do" list.  We are most interested
in the architecture of the "file system layer", not file systems themselves,
and will be looking to make proposals in this area.

If the community at large has any ideas and/or feedback, we certainly
welcome the input.

Re: [ECOS] File access under linux synthetic target

[Andrew Over]

On Mon, Apr 03, 2000 at 02:09:43PM +0200, Andrew Lunn wrote:

> How would i do it in a better way? I think i would look at the pseudo
> device driver work thats been mentioned here lately. That will take
> care of the blocking issue. I'd look at implementing a generic file
> system interface for ecos, one with the standard calls, mount, umount,
> open, close, read, write & seek. Under this interface i'd write a very
> simple 'network file system' protocol which talks to a virtual device
> which does all the real work with the filesystem.

I'm actually looking to do something a bit more high-level than the
file system itself, I just need pseudo-working versions of the fxxxx
stdio functions.

I'd like to expand the current capabilities of IO "devices" a bit
further (ie open/close/seek), but this fits in above the file system
level.  Eventually (ie when someone actually needs it!), a filesystem 
(talking to a raw device) could be implemented underneath this layer,
but I'm mostly interested in the high-level bit.

My goal is just to come up with a quick hack that'll let me get at the
host file system using a few syscalls, but I figure I may as well do
it in some way that might be useful to others :)

Cheers,
--Andrew

Re: [ECOS] File access under linux synthetic target

[Jonathan Larmour]

Andrew Over wrote:
> 
> My goal is just to come up with a quick hack that'll let me get at the
> host file system using a few syscalls, but I figure I may as well do
> it in some way that might be useful to others :)

Cool, although we (Red Hat) are already making the first steps towards this
as part of our initiative to implement the EL/IX level 1 API
( http://sourceware.cygnus.com/elix ) in eCos. This will very much be an open
development, and once we get a few more details thrashed out, we would
encourage you to help out in any places you feel like. There'll be more of
this shortly!

Andrew Lunn wrote:
> File systems support is something that comes up quite often on the
> mail list, probably second to TCP/IP. Now that TCP/IP is in beta, i
> personally think this is the next thing RedHat should work on. Not the
> file systems themselves, but the generic part, libc down to the
> generic interface to the file system. I don't think they should work
> on specific filesystems since the requirements are so wide, FLASH,
> NFS, RAM Discs and even real drives. Let people contribute such file
> systems, or contract RedHat for a specific filesystem. Specifying the
> generic interface is the important thing or we will end up with lots
> of incompatible file systems.

That's exactly what the group here thinks too. In saying that, a RAM-based
FS or something would be a useful starting place as a proof of concept, and
for testing, if nothing else. But with the implementation of "full" CDL, we
now have the functionality available from the configuration system to
support proper plug-in filesystems cleanly.

More shortly...

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault