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]

[cgf@redhat.com: fhandler redesign]


Any thoughts?

cgf

----- Forwarded message from Christopher Faylor <cgf@redhat.com> -----

From: Christopher Faylor <cgf@redhat.com>
To: Corinna Vinschen <vinschen@redhat.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 -----


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