[ECOS] I/O driver lookup handler: read/write mode

[ECOS] I/O driver lookup handler: read/write mode

[Masaki Sawanobori]

Hello,

I am implementing a simple flash memory file system in the framework of eCos
I/O device driver model and C language libc stdio module so the user can
access a file using fopen() as follows.

    FILE *fp = fopen("/dev/flash0/filename", "r");
    FILE *fp = fopen("/flash0/filename", "w");

The problem is that the second paramter(read/write mode) of fopen() is not
passed down to a "lookup" device driver handler(via the cyg_io_lookup
function). The "lookup" handler has no way of returning a correct
return/error value without knowing whether a file(existing or non-existing)
is for read or write.

I would not like to resort to a workaround of adding a read/write mode
specifier as part of a filename parameter like "/nvram/filename/w" or
"/nvram/filename/r" or "/nvramR"/filename" or "/nvramW/filename".  This
would be redundant for fopen().

Is there any other workaround or a solution for this situation? Am I missing
something ?

Here is another wish about I/O device driver handlers. There is no "close"
handler.  I could use a "close" handler since it seems to be a right place
to free memory allocated in my "lookup" handler.

-- Masaki S.

Re: [ECOS] I/O driver lookup handler: read/write mode

[Jonathan Larmour]

Masaki Sawanobori wrote:
> 
> I am implementing a simple flash memory file system in the framework of eCos
> I/O device driver model and C language libc stdio module so the user can
> access a file using fopen() as follows.
> 
>     FILE *fp = fopen("/dev/flash0/filename", "r");
>     FILE *fp = fopen("/flash0/filename", "w");

Gosh. That's good. Are you considering contributing it back? 
 
> The problem is that the second paramter(read/write mode) of fopen() is not
> passed down to a "lookup" device driver handler(via the cyg_io_lookup
> function). The "lookup" handler has no way of returning a correct
> return/error value without knowing whether a file(existing or non-existing)
> is for read or write.
> 
> I would not like to resort to a workaround of adding a read/write mode
> specifier as part of a filename parameter like "/nvram/filename/w" or
> "/nvram/filename/r" or "/nvramR"/filename" or "/nvramW/filename".  This
> would be redundant for fopen().

Quite, although it wouldn't need to be passed that way for fopen, only
cyg_io_lookup.

> Is there any other workaround or a solution for this situation? Am I missing
> something ?

Using cyg_io_get_config() after the cyg_io_lookup() would seem a better
approach.
 
> Here is another wish about I/O device driver handlers. There is no "close"
> handler.  I could use a "close" handler since it seems to be a right place
> to free memory allocated in my "lookup" handler.

This is true. We intend to do something about that in the eCos
implementation of EL/IX, but that may take some time. We intend to do
pluggable filesystems as well, so everything should get sorted out
eventually.

Jifl
-- 
Cygnus Solutions, 35 Cambridge Place, Cambridge, UK.  Tel: +44 (1223) 728762
"I used to have an open mind but || Get yer free open source RTOS's here...
 my brains kept falling out."    || http://sourceware.cygnus.com/ecos
Help fight spam! http://spam.abuse.net/  These opinions are all my own fault

RE: [ECOS] I/O driver lookup handler: read/write mode

[Gary Thomas]

On 30-Nov-99 Masaki Sawanobori wrote:
> Hello,
> 
> I am implementing a simple flash memory file system in the framework of eCos
> I/O device driver model and C language libc stdio module so the user can
> access a file using fopen() as follows.
> 
>     FILE *fp = fopen("/dev/flash0/filename", "r");
>     FILE *fp = fopen("/flash0/filename", "w");
> 
> The problem is that the second paramter(read/write mode) of fopen() is not
> passed down to a "lookup" device driver handler(via the cyg_io_lookup
> function). The "lookup" handler has no way of returning a correct
> return/error value without knowing whether a file(existing or non-existing)
> is for read or write.
> 

I have been thinking along these lines myself.  It definitely makes sense
to be able to pass some flags down into 'cyg_io_lookup()', but I'm not sure
I like the idea of strings (mostly because of the overhead).  How about
a flag word with bits to indicate the desired state?  If you really want/need
to use strings, you could add a layer which handles the translation.

> I would not like to resort to a workaround of adding a read/write mode
> specifier as part of a filename parameter like "/nvram/filename/w" or
> "/nvram/filename/r" or "/nvramR"/filename" or "/nvramW/filename".  This
> would be redundant for fopen().
> 

This is _not_ the way to go (IMHO).

> Is there any other workaround or a solution for this situation? Am I missing
> something ?
> 

Not at this time.

> Here is another wish about I/O device driver handlers. There is no "close"
> handler.  I could use a "close" handler since it seems to be a right place
> to free memory allocated in my "lookup" handler.
> 

I can also see this having value.  I'll look into adding it.

What are you using for your source base?  I could see about adding some of
this, but the timing would depend on my/our workload.  Perhaps you'd like
to propose some changes and I could review and integrate them?  (Not that
I'm trying to get out of work, but that's part of what Open Source is all
about :-)

Re: [ECOS] I/O driver lookup handler: read/write mode

[Masaki Sawanobori]

Gary Thomas wrote:
> What are you using for your source base?  I could see about adding some of
> this, but the timing would depend on my/our workload.  Perhaps you'd like
> to propose some changes and I could review and integrate them?  (Not that
> I'm trying to get out of work, but that's part of what Open Source is all
> about :-)

I am working on eCos 1.2.7 for Matsushita MN10300/AM33.

The following changes to the I/O driver model came to my mind. I could just
do with READONLY and WRITEONLY for my driver, but these R/W modes seem to be
needed for supporting ANSI C fopen.

#define    CYG_IO_LOOKUP_MODE_READONLY    0x0001
#define    CYG_IO_LOOKUP_MODE_WRITEONLY   0x0002
#define    CYG_IO_LOOKUP_MODE_READWRITE   0x0003
#define    CYG_IO_LOOKUP_MODE_CREATE      0x0100
#define    CYG_IO_LOOKUP_MODE_APPEND      0x0200
#define    CYG_IO_LOOKUP_MODE_TRUNCATE    0x0400

Cyg_ErrNo cyg_io_lookup(const char  *name, cyg_io_handle_t *handle,  int
mode);
* Add a mode parameter for cyg_io_lookup() and a lookup handler.

Cyg_ErrNo cyg_io_close(cyg_io_handle_t handle);
* Add a new cyg_io_close function and a close handler.

This would break existing I/O device drivers. But it seems to be most
straightforward.

Jonathan Larmour wrote:
> Using cyg_io_get_config() after the cyg_io_lookup() would seem a better
> approach.

This would be fine, too; in this case,  the changes could be done locally in
the fopen code and would not affect the existing I/O device driver model.
But I like the other approach better since using cyg_io_get/set_config()
would seem to divide the task unnecessarily into two separate functions
which should  be done in cyg_io_lookup() as a unit.

> Gosh. That's good. Are you considering contributing it back?

Sure I will consider it if I can make it generic enough.

-- Masaki S.

Re: [ECOS] I/O driver lookup handler: read/write mode

[Nick Garnett]

"Masaki Sawanobori" <masaki@zentek.com> writes:

> Jonathan Larmour wrote:
> > Using cyg_io_get_config() after the cyg_io_lookup() would seem a better
> > approach.
> 
> This would be fine, too; in this case,  the changes could be done locally in
> the fopen code and would not affect the existing I/O device driver model.
> But I like the other approach better since using cyg_io_get/set_config()
> would seem to divide the task unnecessarily into two separate functions
> which should  be done in cyg_io_lookup() as a unit.
> 

I think that this is probably the best route for you to take at
present. We are in the process of developing a full filesystem
interface specification that will do what you need. I don't want you
to spend too much time trying to squeeze your code into the current
structure when things are going to change for the better in the
future.

Of course you have sources and can so what you want with them! But the
fewer changes you have to make to the distribute sources, and the more
you concentrate in your own code, the easier it will be for you to
take new versions.

-- 
Nick Garnett           mailto:nickg@cygnus.co.uk
Cygnus Solutions, UK   http://www.cygnus.co.uk