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 16:41:55 -0400
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com
Subject: [cgf AT redhat DOT com: fhandler redesign]
Message-ID: <20010517164155.A25918@redhat.com>
Mail-Followup-To: cygwin-developers AT cygwin DOT com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.11i

Any thoughts?

cgf

----- Forwarded message from Christopher Faylor <cgf AT redhat DOT com> -----

From: Christopher Faylor <cgf AT redhat DOT com>
To: Corinna Vinschen <vinschen AT redhat DOT com>
Subject: fhandler redesign
Date: Sun, 1 Apr 2001 22:58:24 -0400

I would like to start thinking about an fhandler redesign.  The current
method is, IMO, too bulky and not layered enough.

One problem is that there is no real "device" layer so many things are
copied around between fds that should only exist at the device layer.

One example of this is your recent save/restore screen changes.  There
should only be one save screen buffer and it should only exist at the
device layer.  Since we don't have a real device layer, we have to
save the screen buffer in an opened fd.

This is only the most recent example of this.  We're basically lucky
that most people don't do very strange things with devices like opening
them twice and expecting consistent behavior between the two opened
fds.

I was thinking that each device that cygwin supports could have a
structure like:

struct dev
{
  DWORD version;
  DWORD major, minor;
  HANDLE io_handle;
  int _read(char *buf, size_t size);
  int _write(char *buf, size_t size);
  int _ioctl(char *buf, size_t size);
  /* probably other stuff which can be drawn from linux and the
     current fhandler method */
}

...this is basically a fhandler structure but we'd only have one of
these per device and local storage for the device would exist here.

These devices could exist in a table hashed by major and minor number.

A 'fd' would basically be a pointer to one of these entities (for devices
like the console or a tty) or into an instance of one of these for files.

I'd like to have devices actually exist in the file system (e.g.,
/dev/tty), like linux but I don't know what kind of overhead this would
cause whenever you wanted to open "/dev/tty".  Maybe it would be
negligible.

If we vowed that this was a "C" structure and that we'd always add stuff
to the end, then we could use this to help implement your idea of DLL
loadable devices.

Was this similar to what you were thinking of doing a while ago?

cgf

----- End forwarded message -----