Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , 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 23:07:01 +0200 From: Corinna Vinschen To: cygwin-developers AT cygwin DOT com Subject: Re: [cgf AT redhat DOT com: fhandler redesign] Message-ID: <20010517230701.Z31266@cygbert.vinschen.de> Reply-To: cygdev Mail-Followup-To: cygwin-developers AT cygwin DOT com References: <20010517164155 DOT A25918 AT redhat DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010517164155.A25918@redhat.com>; from cgf@redhat.com on Thu, May 17, 2001 at 04:41:55PM -0400 On Thu, May 17, 2001 at 04:41:55PM -0400, Christopher Faylor wrote: > Any thoughts? > > cgf > > ----- Forwarded message from Christopher Faylor ----- > > From: Christopher Faylor > To: Corinna Vinschen > 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? Actually that's similar. I didn't reflect on having a single device structure but having a more flexible fhandler structure which additionally allows new file systems like /proc. You're right, we would need a device driven system, nevertheless. I think this will fit better with extensions like /dev/dsp from Andy Younger as well. I think a structure like the following could basically work: class base_file_handling (just internal like currently fhandler_base) int open(); int read(); int ioctl(); | +--------------------------------------+ | | class dev_class class fs_class int major; int major; (== disk, tape) (== FAT,NTFS,ext2) int open(the device); int open(a file on fs); int read(); int read(); int ioctl(); int ioctl(); | int opendir(); +-------------------------------+ int readdir(); | int mkdir(); | | | +--------------------------+ | | class dev | class fs | int major; | int major; | int minor; | int minor; | class dev_class *dev_worker; ---+ class fs_class *fs_worker -+ char *real_windows_dev; char *real_windows_path; (== "\\.\C:") (== "C:\cygwin") char *cygwin_name; char *posix_path; (== "/dev/hdc") (== "/") | | +-------------------------------+ | | | class file_handler | | int device_or_file_on_fs; | | union { | | dev *device; ----------+ | fs *fs; ------------------+ }; char *windows_path; char *cygwin_path; Note that this is an object oriented viewpoint. It doesn't necessarily mean that it has to be implemented as classes. class base_file_handling has exactly one instance for calling from the dev/fs-classes just for convenience. class dev_class has exactly one instance per device class, one for tapes, one for disks, one for sound, etc. class fs_class has exactly one instance per fs class, one for FAT/NTFS, one for /registry, one for /proc, etc. class file_handler has one instance for each open file descriptor. To allow loadable device and/or filesystem drivers, the methods in the classes dev_class and fs_class should be pointer to functions. Moreover, we would need a sort of automagical loading mechanism but this could be discussed later. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developer mailto:cygwin AT cygwin DOT com Red Hat, Inc.