This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
Re: Symlinks under /proc
- From: Christopher Faylor <me at cgf dot cx>
- To: cygwin-developers at cygwin dot com
- Date: Tue, 1 Feb 2005 14:30:26 -0500
- Subject: Re: Symlinks under /proc
- References: <Pine.GSO.4.61.0501311218420.28344@slinky.cs.nyu.edu> <20050131173157.GH31117@cygbert.vinschen.de> <Pine.GSO.4.61.0501311240520.28344@slinky.cs.nyu.edu> <20050131200457.GL31117@cygbert.vinschen.de> <20050131201158.GN22449@trixie.casa.cgf.cx> <20050131202308.GO31117@cygbert.vinschen.de> <20050131203025.GP31117@cygbert.vinschen.de> <20050131204832.GP22449@trixie.casa.cgf.cx> <20050201174022.GA6447@trixie.casa.cgf.cx> <Pine.GSO.4.61.0502011404210.29792@slinky.cs.nyu.edu>
- Reply-to: cygwin-developers at cygwin dot com
On Tue, Feb 01, 2005 at 02:07:28PM -0500, Igor Pechtchanski wrote:
>On Tue, 1 Feb 2005, Christopher Faylor wrote:
>
>> On Mon, Jan 31, 2005 at 03:48:32PM -0500, Christopher Faylor wrote:
>> >On Mon, Jan 31, 2005 at 09:30:25PM +0100, Corinna Vinschen wrote:
>> >>On Jan 31 21:23, Corinna Vinschen wrote:
>> >>> On Jan 31 15:11, Christopher Faylor wrote:
>> >>>>On Mon, Jan 31, 2005 at 09:04:57PM +0100, Corinna Vinschen wrote: Have
>> >>>>we reached the point yet where we can just get rid of special /dev
>> >>>>handling entirely? Maybe we could just add /dev population to
>> >>>>setup.exe or even have cygwin1.dll itself run a program if it detects
>> >>>>an unpopulated /dev, sort of like how udev is handled in linux now.
>> >>>>
>> >>>>My only reservation with doing things this way is that we'd be making
>> >>>>cygwin perform a disk lookup every time someone wanted to get to open
>> >>>>/dev/tty.
>> >>>
>> >>>I would not like to change that yet. So far, the DLL is still
>> >>>basically self-sufficient. If you require on-disk devices, you can't
>> >>>use the DLL anymore without having a minimal installation process. I
>> >>>can see the point where I'm getting convinced that exactly that is a
>> >>>good idea, but right now...
>> >>
>> >>Actually, couldn't we just keep /dev/console, /dev/tty* and /dev/null
>> >>handled internally? Everything else seems rather non-critical.
>> >
>> >You don't even have to do that. AFAICT, there is no reason for the DLL
>> >to have to parse "/dev/tty*" or "/dev/null" when it could just be
>> >relying on using major and minor device numbers.
>> >
>> >I just quickly hacked cygwin to stop parsing /dev entirely and it seems
>> >to work ok, for the most part. The one puzzler is that while it deals
>> >ok with /dev/tty, it does not handle /dev/null correctly, even after a
>> >/dev/null has been created.
>>
>> With the latest checkins, it seems to be possible to remove the /dev
>> parsing entirely and rely on an on-disk populated /dev.
>>
>> Igor, could you repost your script for populating /dev?
>>
>> I don't remember how intelligent it was but I suspect that it doesn't
>> actually query the system to figure out what devices are available,
>> right?
>
>No, it doesn't -- it just has a hard-coded list. *Is* there a way to
>query the devices available?
I'm sure there is -- via some windows api or other.
>It would be good to test it first, though -- does the CVS HEAD still treat
>/dev as a virtual directory?
Yes. You can turn this off with the (temporary) patch below.
cgf
Index: devices.cc
===================================================================
RCS file: /cvs/uberbaum/winsup/cygwin/devices.cc,v
retrieving revision 1.14
diff -u -p -r1.14 devices.cc
--- devices.cc 1 Feb 2005 16:49:11 -0000 1.14
+++ devices.cc 1 Feb 2005 19:26:45 -0000
@@ -14801,6 +14801,8 @@ return NULL;
void
device::parse (const char *s)
{
+ *this = *fs_dev;
+ return;
size_t len = strlen (s);
const device *dev = KR_find_keyword (s, len);