delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-developers/1998/09/16/12:21:22

From: cgf AT cygnus DOT com (Christopher Faylor)
Subject: Re: New winsup snapshot 9/14/98
16 Sep 1998 12:21:22 -0700 :
Message-ID: <19980916145910.A13558.cygnus.cygwin32.developers@cygnus.com>
References: <19980914141243 DOT 37248 AT cygnus DOT com>
Mime-Version: 1.0
To: Corinna Vinschen <corinna DOT vinschen AT cityweb DOT de>,
cygwin32-developers AT cygnus DOT com

On Wed, Sep 16, 1998 at 08:37:53PM +0200, Corinna Vinschen wrote:
>Christopher Faylor wrote:
>
>> On Wed, Sep 16, 1998 at 02:42:07PM +0200, Corinna Vinschen wrote:
>> >I think, the following way would be better:
>> >1. Method mount_info::conv_to_win32_path()
>> >   - Call win32_device_name() with special third parameter.
>> >
>> >2. Function get_device_number():
>> >    - Third parameter, to decide, from whom it's called.
>> >    - If called by 'conv_win32_path()': Returns device names
>> >      only for non mass storage devices (e.g. tty).
>> >    - else returns device number, but uses WinNT path, to
>> >      generate wellformed major and minor numbers.
>> >
>> >Other opinions?
>> >If not, I would reimplement this in the above manner.
>>
>> I'll consider such a change, but wouldn't it be a lot less work to
>> just modify:
>>
>>     hinfo::build_fhandler (int fd, const char *name, HANDLE handle)
>>
>> in the condition where get_device_number returns FH_BAD?
>
>Unfortunately, this wouldn't be enough, because to figure out the
>windows path, hinfo::build_fhandler() has to call a
>
>    path_conv winpath(name);
>
>which then calls mount_info::conv_to_win32_path(). This would
>give an incorrect result again! (But I don_t know, if I have
>something not realized).

At this point it is only the device numbers that should matter.  It
shouldn't matter what the device is called.  The win32 name doesn't
really apply to anything except, I believe, ttys.

>Meanwhile I have integrate this change and all my other changes
>into the winsup980914. I send it as attachment to this mail.
>
>> Eventually, I'd like to see a scheme in cygwin where the /dev directory
>> actually exists and is populated with devices on your system, just like
>> in UNIX.  Then you can call your tape /dev/foobar and it won't matter.
>>
>
>I have reflected about a UNIX-like device mapping, also. I would prefer
>a solution like the following:
>    - cygwin has an fixed internal (but documented!) mapping between
>      (all, if possible) Windows devices and major/minor numbers.
>    - A new cygwin specific mknod(1)-command lets one do e.g. the
>      following:
>
>            mknod /dev/st0 c 17 0
>
>    which results in a new registry entry e.g.
>            \\HKEY_CURRENT_USER\Software\Cygnus Solutions\
>            CYGWIN.DLL setup\b15.0\devs\...
>    with device entries.
>Advantages:
>    - The mapping between device names and devices is variable but
>      definite, like in UNIX.
>    - cygwin has a simple method, to connect a path to the correct
>      'device driver', in other words: the correct fhandler class.
>    - The mount table need not contain device entries.
>    - More possibilities, than today, I think.
>Drawbacks:
>    - Speed???
>    - Complexity???
>
>Discussion?

The registry is always an option but most people are afraid of it.
That's why I was thinking of using the standard UNIX way of producing
"special" files in /dev.  I *think* that most gnu-win32 users who
are familiar with UNIX would be familiar with that concept.

With the registry, possibly we'd could support /dev as a "directory that
lives in the registry".  Hmm, that might be a nice generalization for
other stuff, too.

I'll try to take a look at your changes ASAP.  We're all in release
mode here, so things are kind of hectic, but it would be nice to get
your changes into B20.

If you don't hear from me in a few days please feel free to contact me
again to find out what progress, if any, has been made with integrating
your changes.

-- 
cgf AT cygnus DOT com
http://www.cygnus.com/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019