Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Date: Thu, 17 May 2001 17:01:06 -0400
Message-Id: <200105172101.RAA22405@envy.delorie.com>
X-Authentication-Warning: envy.delorie.com: dj set sender to dj AT envy DOT delorie DOT com using -f
From: DJ Delorie <dj AT delorie DOT com>
To: cygwin-developers AT cygwin DOT com
In-reply-to: <20010517164155.A25918@redhat.com> (message from Christopher
	Faylor on Thu, 17 May 2001 16:41:55 -0400)
Subject: Re: [cgf AT redhat DOT com: fhandler redesign]
References:  <20010517164155 DOT A25918 AT redhat DOT com>


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.