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]


----- 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


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