Mail Archives: cygwin-developers/2001/05/17/17:01:13
There's actually four layers we should have:
1. The physical device/file. Two programs could be writing to
different parts or instances of the device simultaneously. I think
NT takes care of this for us, but virtual devices we create we'd
need to think about this. I can't think of examples, though, so we
can probably leave it up to the #2 layer to figure out how/where to
deal with this, rather than have it as an explicit layer.
2. The "file". This is where the file pointer and other state (baud
rate, foreground color, whatnot) are kept, for example.
3. The "file descriptor". This is the int (and whatever state is
behind it) that open() returns. There are a few things that are
descriptor-specific, like blocking or opened/closed.
4. The filesystem. While independent of the other three, we should
consider how this fits into the system so that we can do things
like mounting EXT3 volumes, or NFS, or faking /dev, /proc, and
/proc/registry.
As for the API, I suggest having the first two words of the structure
be (1) sizeof(the structure) and (2) a compatibility-broke version
number (which, hopefully, never changes). The spec should allow for
cygwin1.dll to convert the structure into a "current" API, so the
sub-dll should never expect that changing the structure's contents at
runtime would work. The DLL should export one such structure for each
device type (not instance) that it supports, so "io_handle" probably
doesn't belong there. The API would need to have a "create_instance"
method that returns a state pointer that cygwin uses to communicate
with the dll. This state would have as its first word a pointer to
the device type structure, then two words for cygwin's use
(presumably, one for a pointer to a common structure and one for an
instance id).
I'd also like to see cygwin support this: For file "/foo/bar.dll" if
you open "/foo/bar=4,5,x" it loads the dll and calls some well-known
method, passing "4,5,x", and gets back a pointer to such an instance.
- Raw text -