X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-0.7 required=5.0 tests=AWL,BAYES_20,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org X-ASG-Debug-ID: 1285349857-50cd316a0001-w5GHUG X-Barracuda-Envelope-From: daniel AT fgm DOT com X-Barracuda-Apparent-Source-IP: 216.2.55.102 X-ASG-Whitelist: Client Message-ID: <4C9CE1E0.9040503@fgm.com> Date: Fri, 24 Sep 2010 13:37:36 -0400 From: Daniel Barclay User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.13) Gecko/20100914 SeaMonkey/2.0.8 MIME-Version: 1.0 To: Subject: Re: [bulk] - R: /dev/ttys* under cygwin problem References: <8CCC8F85C5F2784387A32FAD835FB4E602F21573F3 AT server03> <358785 DOT 53873 DOT qm AT web25505 DOT mail DOT ukl DOT yahoo DOT com> <8CCC8F85C5F2784387A32FAD835FB4E602F21573F7 AT server03> <0105D5C1E0353146B1B222348B0411A2094D31E89D AT NIHMLBX02 DOT nih DOT gov> <4C9A3CFA DOT 9090507 AT fgm DOT com> <4C9A4207 DOT 9080405 AT cygwin DOT com> <4C9A6EDD DOT 3040406 AT fgm DOT com> <4C9A7185 DOT 2060804 AT redhat DOT com> X-ASG-Orig-Subj: Re: [bulk] - R: /dev/ttys* under cygwin problem In-Reply-To: <4C9A7185.2060804@redhat.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: UNKNOWN[216.2.55.102] X-Barracuda-Start-Time: 1285349857 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://spam.fgm.com:8000/cgi-mod/mark.cgi X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Eric Blake wrote: > On 09/22/2010 03:02 PM, Daniel Barclay wrote: ... >> Again, why does Cygwin's (virtual) file system _not_ include those >> devices (when listing /dev)? (Why doesn't it do it more like Linux's >> /proc, etc., which gives a consistent view and which tells you what's >> available without your having to look elsewhere?) > > ...Also, unlike Linux, > where the kernel knows what devices are present, a cygwin implementation > would have to make a lot of syscalls querying whether each potential > device is available. Oh--so Cygwin would have to query Windows for the current set of devices (which can change over time (right?)) each time the /dev directory was listed (since it doesn't maintain the net device list itself as a kernel would)?)? > One other drawback - ... part of the implementation battle is > figuring out how to merge an existing directory containing user-added > symlinks or device names, in parallel with the virtual devices supported > by the virtual FS magic compiled into cygwin. Okay, yeah, I see how that could be tricky. Wait a minute--doesn't Cygwin have to do that anyway? If the user adds a symlink or device with the same name as that of a virtual device provided by Cygwin, and then refers to that pathname (/dev/something), haven't the Cygwin designers already had to decide what happens (whether the user gets the virtual device or, say, gets the target of the symlink)? If so, does listing the /dev directory really add some additional consideration? > >> Actually, is your last sentence above actually true? Looking at the >> device-creation script you pointed me to, I wonder: How do you (e.g., >> a script) determine which devices of a given type exist (e.g., sda1, >> sda2, sda3, ...)? (Do you have to try to open each possible device and >> check whether there's an error?) > > The script creates every known name, whether or not it actually exists > as a device at the current moment, which is in itself a bit misleading. > But it has to, because of devices which can be added and removed on the > fly, whereas the script creating the placeholder files is only run once. Yes, I got that part. What I was wondering was what would be the recommended way to determine which devices really existed. Would it be trying to open the device and checking for some "no such device" error? Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple