This is the mail archive of the ecos-discuss@sourceware.cygnus.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: I/O driver lookup handler: read/write mode



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 :-)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]