This is the mail archive of the
ecos-discuss@sourceware.cygnus.com
mailing list for the eCos project.
RE: [ECOS] Block devices and I/O Package API
- To: Glenn Serre <gaserre@spiresoftware.com>
- Subject: RE: [ECOS] Block devices and I/O Package API
- From: Gary Thomas <gthomas@cygnus.co.uk>
- Date: Thu, 03 Jun 1999 07:45:10 +0100 (BST)
- Cc: "ecos-discuss@sourceware.cygnus.com" <ecos-discuss@sourceware.cygnus.com>
On 03-Jun-99 Glenn Serre wrote:
> Good evening,
>
> We're going to be writing a CDROM driver (and file system functions) to use
> with eCos and I'd like some thoughts on how the I/O APIs were intended to
> be used with block devices. In other systems, the parameters to the device
> functions allow the caller to specify which blocks to operate on, but I don't
> see how this would fit into the cyg_io_write and cyg_io_read functions unless
> I passed some kind of block request struct as the buffer pointer.
>
> I'd be happy to hear any thoughts on how this is meant to work (or how it
> should work).
>
You're correct that the intended usage is not clear. Since we've not done
any block devices yet, the methods are not yet "cast in stone".
I've thought about doing this two different ways:
1) Normal read and write are considered sequential (perhaps modulo
the block size). The get/set_config functions would be used to
select the next block to operate on (if different from the last
sequential one).
2) Read and write use some sort of descriptor for the "buffer". This
would contain the block number, as well as the actual buffer address.
Personally, I prefer option (1) since it is the simplest and potentially
lowest overhead (the upper levels don't need to worry about block numbers
unless necessary, etc). It would require the lowest level driver to keep
track of the next block to read/write, but these drivers certainly have
other instance specific data anyway, so this should not be too large a
burden.
I'd be glad to discuss either of these options, or others, as you wish.