This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
Re: [cgf@redhat.com: fhandler redesign]
----- Original Message -----
From: "DJ Delorie" <dj@delorie.com>
To: <cygwin-developers@cygwin.com>
Sent: Friday, May 18, 2001 7:01 AM
Subject: Re: [cgf@redhat.com: fhandler redesign]
>
> There's actually four layers we should have:
>
> 1. The physical device/file. Two programs could be writing to
> different parts or instances of the device simultaneously. I think
> NT takes care of this for us, but virtual devices we create we'd
> need to think about this. I can't think of examples, though, so we
> can probably leave it up to the #2 layer to figure out how/where to
> deal with this, rather than have it as an explicit layer.
FIFO's come to mind. The clipboard is potentially in this case as well.
> 2. The "file". This is where the file pointer and other state (baud
> rate, foreground color, whatnot) are kept, for example.
>
> 3. The "file descriptor". This is the int (and whatever state is
> behind it) that open() returns. There are a few things that are
> descriptor-specific, like blocking or opened/closed.
>
> 4. The filesystem. While independent of the other three, we should
> consider how this fits into the system so that we can do things
> like mounting EXT3 volumes, or NFS, or faking /dev, /proc, and
> /proc/registry.
I'd like to suggest we implement ext3/nfs and other filesystems via real
win32 IFS handlers. It's a bit more effort, but we'll get the win32
process cleanup, and allow non-cygwin process's to access the fs.
(Imagine the complaints otherwise: I mounted my linux partition, but
when I use ActiveState Perl It cannot access the files....)
Rob