Mail Archives: cygwin-developers/2001/05/17/17:13:49
On Thu, May 17, 2001 at 04:41:55PM -0400, Christopher Faylor wrote:
> 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?
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.
- Raw text -