This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


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

Re: [cgf@redhat.com: fhandler redesign]



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.


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