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]


On Thu, May 17, 2001 at 04:41:55PM -0400, Christopher Faylor wrote:
> 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?

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@cygwin.com
Red Hat, Inc.


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