From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gary Thomas To: Masaki Sawanobori Cc: ecos-discuss@sourceware.cygnus.com Subject: RE: [ECOS] I/O driver lookup handler: read/write mode Date: Tue, 30 Nov 1999 07:47:00 -0000 Message-id: References: <062c01bf3b22$2a8be000$437201aa@atlantis7> X-SW-Source: 1999-11/msg00081.html 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 :-)