From owner-devfs@oss.sgi.com Tue May 1 18:35:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f421Z4G07404 for devfs-outgoing; Tue, 1 May 2001 18:35:04 -0700 Received: from mail11.jump.net (mail11.jump.net [206.196.91.11]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f421Z3F07400 for ; Tue, 1 May 2001 18:35:03 -0700 Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26]) by mail11.jump.net (8.10.2/) with ESMTP id f421Z1526085 for ; Tue, 1 May 2001 20:35:01 -0500 (CDT) Message-ID: <3AEF6499.F84AFBBB@sgi.com> Date: Tue, 01 May 2001 20:36:25 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686) X-Accept-Language: en MIME-Version: 1.0 To: devfs@oss.sgi.com Subject: swapon -a errors w/ devfs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-devfs@oss.sgi.com Precedence: bulk Here's a new one... In Red Hat's rc.sysinit, they actually issue the swapon command twice - first as "swapon -a -e" and then as "swapon -a" (not quite sure why they do this) When devfs is enabled, the second "swapon" generates an error saying that the swap device is busy. The swapon man pages say that "swapon -a" will silently skip swap devices that are already enabled, but this is not the case w/ devfs enabled. My guess is a bug in swapon, that it's getting confused by the symlink to the device (fstab has /dev/hda5 as swap, for example). Any ideas? -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-devfs@oss.sgi.com Tue May 1 18:57:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f421vq708147 for devfs-outgoing; Tue, 1 May 2001 18:57:52 -0700 Received: from gec.gecpalau.com (gec.gecpalau.com [206.49.60.67]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f421uHF08126 for ; Tue, 1 May 2001 18:56:44 -0700 Received: from gecpalau.com (rieacs.gecpalau.com [206.49.60.69]) by gec.gecpalau.com (8.11.2/8.11.2) with ESMTP id f421sF129029; Wed, 2 May 2001 10:54:15 +0900 Message-ID: <3AEF68BD.D8368188@gecpalau.com> Date: Wed, 02 May 2001 10:54:05 +0900 From: Glenn Shannon X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.4.4-GECKERN i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: devfs@oss.sgi.com Subject: Re: swapon -a errors w/ devfs References: <3AEF6499.F84AFBBB@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-devfs@oss.sgi.com Precedence: bulk Eric Sandeen wrote: > Here's a new one... > > In Red Hat's rc.sysinit, they actually issue the swapon command twice - > first as "swapon -a -e" and then as "swapon -a" (not quite sure why > they do this) > > When devfs is enabled, the second "swapon" generates an error saying > that the swap device is busy. > > The swapon man pages say that "swapon -a" will silently skip swap > devices that are already enabled, but this is not the case w/ devfs > enabled. > > My guess is a bug in swapon, that it's getting confused by the symlink > to the device (fstab has /dev/hda5 as swap, for example). > > Any ideas? > > -Eric > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. I run RedHat with DevFS, and I don't see the two swapon entries you are talking about...perhaps it is a different version than the one I use (6.2 with updates). However, I used to have a problem with swapon saying that my swap partitions were busy until I re-wrote my fstab (after backing it up of course) to point to the actual devfs names of the partitions. Hope this helps. Glenn From owner-devfs@oss.sgi.com Tue May 1 19:11:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f422BBY08585 for devfs-outgoing; Tue, 1 May 2001 19:11:11 -0700 Received: from mail11.jump.net (mail11.jump.net [206.196.91.11]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f422B8F08582 for ; Tue, 1 May 2001 19:11:08 -0700 Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26]) by mail11.jump.net (8.10.2/) with ESMTP id f422A5503872; Tue, 1 May 2001 21:10:05 -0500 (CDT) Message-ID: <3AEF6CD2.93BC5542@sgi.com> Date: Tue, 01 May 2001 21:11:30 -0500 From: Eric Sandeen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Glenn Shannon CC: devfs@oss.sgi.com Subject: Re: swapon -a errors w/ devfs References: <3AEF6499.F84AFBBB@sgi.com> <3AEF68BD.D8368188@gecpalau.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-devfs@oss.sgi.com Precedence: bulk Glenn Shannon wrote: > I run RedHat with DevFS, and I don't see the two swapon entries you are > talking about...perhaps it is a different version than the one I use (6.2 > with updates). Yep, this is a shiny 7.1 install w/ devfs. > However, I used to have a problem with swapon saying that my swap > partitions were busy until I re-wrote my fstab (after backing it up of > course) to point to the actual devfs names of the partitions. Ok, I thought that might solve it... but it's another thing to work around. I guess maybe I'll dig into swapon to see why it has trouble with symlinks... -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-devfs@oss.sgi.com Wed May 2 07:39:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f42EdY907070 for devfs-outgoing; Wed, 2 May 2001 07:39:34 -0700 Received: from mail.labsysgrp.com (phnx1-blk2-hfc-0251-d1db10f1.rdc1.az.coxatwork.com [209.219.16.241] (may be forged)) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42EdWF07067 for ; Wed, 2 May 2001 07:39:32 -0700 Received: from jeeves.kpf.internal ([192.168.170.1]) by mail.labsysgrp.com with esmtp (Exim 3.22 #2) id 14uxmM-0001p4-00; Wed, 02 May 2001 07:38:59 -0700 Received: from [192.168.170.101] (helo=Kevin) by jeeves.kpf.internal with smtp (Exim 3.22 #3) id 14uxm8-0005ri-00; Wed, 02 May 2001 07:38:44 -0700 Message-ID: <003301c0d316$0fd480e0$65aaa8c0@Kevin> From: "Kevin P. Fleming" To: "Eric Sandeen" , "Glenn Shannon" Cc: References: <3AEF6499.F84AFBBB@sgi.com> <3AEF68BD.D8368188@gecpalau.com> <3AEF6CD2.93BC5542@sgi.com> Subject: Re: swapon -a errors w/ devfs Date: Wed, 2 May 2001 07:42:07 -0700 Organization: LSG, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-devfs@oss.sgi.com Precedence: bulk I've noticed the same thing, with the identical configuration you have. The reason that the init scripts run swapon twice is in case you are using any swap _files_, they need to be turned on after all the filesystems have been mounted. You can either disable the second "swapon", or do as you say (which I was going to do as well) and figure out why swapon can't tell that the partition is already enabled. ----- Original Message ----- From: "Eric Sandeen" To: "Glenn Shannon" Cc: Sent: Tuesday, May 01, 2001 7:11 PM Subject: Re: swapon -a errors w/ devfs > Glenn Shannon wrote: > > > I run RedHat with DevFS, and I don't see the two swapon entries you are > > talking about...perhaps it is a different version than the one I use (6.2 > > with updates). > > Yep, this is a shiny 7.1 install w/ devfs. > > > However, I used to have a problem with swapon saying that my swap > > partitions were busy until I re-wrote my fstab (after backing it up of > > course) to point to the actual devfs names of the partitions. > > Ok, I thought that might solve it... but it's another thing to work > around. I guess maybe I'll dig into swapon to see why it has trouble > with symlinks... > > -Eric > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. > > > From owner-devfs@oss.sgi.com Wed May 2 08:06:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f42F6EX08634 for devfs-outgoing; Wed, 2 May 2001 08:06:14 -0700 Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42F68F08621 for ; Wed, 2 May 2001 08:06:08 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id f42F5j625222; Wed, 2 May 2001 09:05:45 -0600 Date: Wed, 2 May 2001 09:05:45 -0600 Message-Id: <200105021505.f42F5j625222@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: "Kevin P. Fleming" Cc: "Eric Sandeen" , "Glenn Shannon" , Subject: Re: swapon -a errors w/ devfs In-Reply-To: <003301c0d316$0fd480e0$65aaa8c0@Kevin> References: <3AEF6499.F84AFBBB@sgi.com> <3AEF68BD.D8368188@gecpalau.com> <3AEF6CD2.93BC5542@sgi.com> <003301c0d316$0fd480e0$65aaa8c0@Kevin> Sender: owner-devfs@oss.sgi.com Precedence: bulk Kevin P. Fleming writes: > I've noticed the same thing, with the identical configuration you > have. The reason that the init scripts run swapon twice is in case > you are using any swap _files_, they need to be turned on after all > the filesystems have been mounted. You can either disable the second > "swapon", or do as you say (which I was going to do as well) and > figure out why swapon can't tell that the partition is already > enabled. Oh! I just had a thought on this: perhaps swapon(8) is broken the same way as mount, and translates the symlink before calling swapon(2) (which in turn adds the entry to /proc/swaps). However, as part of it's scanning phase, it does a string comparison on the entries in /etc/fstab and /proc/swaps, *without symlink translation*. To test this, edit your /etc/fstab to use the full path name of the swap device (the /dev/ide/... or /dev/scsi/... name). If my theory is correct, you won't get the double swapping problem. Someone should send Andries a patch to remove the symlink translation code from mount(8) and swapon(8). It was always bogus. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Wed May 2 09:04:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f42G4OW11751 for devfs-outgoing; Wed, 2 May 2001 09:04:24 -0700 Received: from mail11.svr.pol.co.uk (mail11.svr.pol.co.uk [195.92.193.23]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42G4MF11746 for ; Wed, 2 May 2001 09:04:23 -0700 Received: from modem-11.coris-wrasse.dialup.pol.co.uk ([62.136.253.11]) by mail11.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14uz6z-0006bN-00 for devfs@oss.sgi.com; Wed, 02 May 2001 17:04:21 +0100 Date: Wed, 2 May 2001 17:07:17 +0100 (BST) From: Will Newton X-X-Sender: To: Subject: Re: swapon -a errors w/ devfs In-Reply-To: <3AEF6499.F84AFBBB@sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-devfs@oss.sgi.com Precedence: bulk On Tue, 1 May 2001, Eric Sandeen wrote: > Here's a new one... In the initscripts package changelog there is "take advantage of new swapon behaviour" or something a few revisions ago. It's been around for about a month in Rawhide. > When devfs is enabled, the second "swapon" generates an error saying > that the swap device is busy. Yep, me too. Not really investigated as it seems totally harmless but I wish RedHat would test with devfs once in a while... From owner-devfs@oss.sgi.com Wed May 2 09:11:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f42GB4f12099 for devfs-outgoing; Wed, 2 May 2001 09:11:04 -0700 Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42GB1F12096 for ; Wed, 2 May 2001 09:11:02 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id f42GAci26956; Wed, 2 May 2001 10:10:38 -0600 Date: Wed, 2 May 2001 10:10:38 -0600 Message-Id: <200105021610.f42GAci26956@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Will Newton Cc: Subject: Re: swapon -a errors w/ devfs In-Reply-To: References: <3AEF6499.F84AFBBB@sgi.com> Sender: owner-devfs@oss.sgi.com Precedence: bulk Will Newton writes: > On Tue, 1 May 2001, Eric Sandeen wrote: > > > Here's a new one... > > In the initscripts package changelog there is "take advantage of new > swapon behaviour" or something a few revisions ago. It's been around for > about a month in Rawhide. > > > When devfs is enabled, the second "swapon" generates an error saying > > that the swap device is busy. > > Yep, me too. Not really investigated as it seems totally harmless > but I wish RedHat would test with devfs once in a while... That's where "customer feedback" comes in. Send a message to their complaints/feedback line. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Wed May 2 13:10:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f42KAmW15843 for devfs-outgoing; Wed, 2 May 2001 13:10:48 -0700 Received: from iaeste-catalunya.upc.es (iaeste-catalunya.upc.es [147.83.55.111]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f42KAkF15831 for ; Wed, 2 May 2001 13:10:46 -0700 Received: (qmail 2405 invoked by uid 3); 2 May 2001 20:00:35 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 2 May 2001 20:00:35 -0000 Date: Wed, 2 May 2001 22:00:35 +0200 (CEST) From: Joan Picanyol i Puig To: devfs@oss.sgi.com Subject: devfs & openssh Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-devfs@oss.sgi.com Precedence: bulk Hi, I'm trying to go 'all the way' with devfs, and (so far) I've found two problems: I removed my compatibility entries, and openssh-2.5.1 complains that I don't have a controlling tty and cannot read my passphrase. Is the only solution to stick with old compatibility entries? I'd like to be able to automount /cdrom /cdrw and /floppy (all of which are modularized). Anyone could give me a hint on how to start trying it? Thanks From owner-devfs@oss.sgi.com Wed May 2 14:51:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f42Lp3Q12534 for devfs-outgoing; Wed, 2 May 2001 14:51:03 -0700 Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42Lp1F12531 for ; Wed, 2 May 2001 14:51:01 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id f42Lojw30479; Wed, 2 May 2001 15:50:45 -0600 Date: Wed, 2 May 2001 15:50:45 -0600 Message-Id: <200105022150.f42Lojw30479@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Joan Picanyol i Puig Cc: devfs@oss.sgi.com Subject: Re: devfs & openssh In-Reply-To: References: Sender: owner-devfs@oss.sgi.com Precedence: bulk Joan Picanyol i. Puig writes: > I'm trying to go 'all the way' with devfs, and (so far) I've found > two problems: > > I removed my compatibility entries, and openssh-2.5.1 complains that > I don't have a controlling tty and cannot read my passphrase. Is the > only solution to stick with old compatibility entries? I assume you're running glibc? In that case, talk to the glibc maintainers. It sounds like their ttyname(3) implementation doesn't scan /dev/pty for terminals. > I'd like to be able to automount /cdrom /cdrw and /floppy (all of > which are modularized). Anyone could give me a hint on how to start > trying it? You need an automounter entry, of course. And make sure your driver modules are loaded. If you are using module autoloading, you will need to enable support for that in your /etc/devfsd.conf file. You may also need to tune your /etc/modules.conf file (see the comments in /etc/modules.devfs for hints). Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Thu May 3 17:20:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f440KKX21941 for devfs-outgoing; Thu, 3 May 2001 17:20:20 -0700 Received: from iaeste-catalunya.upc.es (iaeste-catalunya.upc.es [147.83.55.111]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f440KIF21936 for ; Thu, 3 May 2001 17:20:18 -0700 Received: (qmail 6093 invoked by uid 3); 4 May 2001 00:10:21 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 4 May 2001 00:10:21 -0000 Date: Fri, 4 May 2001 02:10:21 +0200 (CEST) From: Joan Picanyol i Puig To: Richard Gooch cc: devfs@oss.sgi.com Subject: Re: devfs & autoloading In-Reply-To: <200105022150.f42Lojw30479@vindaloo.ras.ucalgary.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-devfs@oss.sgi.com Precedence: bulk Hi again, I definitely think I'm getting closer now On Wed, 2 May 2001, Richard Gooch wrote: > I assume you're running glibc? In that case, talk to the glibc > maintainers. It sounds like their ttyname(3) implementation doesn't > scan /dev/pty for terminals. I'm running glibc-2.1.3 and you mention a 'similar fix', could you point to the patch for it please (I'd just like to get rid of MKOLDCOMPAT...)? Well, my question wasn't precise enough (as a matter of fact nor correct I forgot to do this before), here's what I've done with the configuration files attached: 1 scsi hd & 1 ide hd already working root:/root # ls /dev/discs/ -l total 0 lr-xr-xr-x 1 root root 30 Jan 1 1970 disc0 -> ../ide/host0/bus0/target0/lun0 lr-xr-xr-x 1 root root 31 Jan 1 1970 disc1 -> ../scsi/host0/bus0/target6/lun0 These work fine (thankfully), the problem comes with module autoloading: root:/root # cdrecord -scanbus Cdrecord 1.9 (i686-pc-linux-gnu) Copyright (C) 1995-2000 Jörg Schilling cdrecord: No such file or directory. Cannot open SCSI driver. cdrecord: For possible targets try 'cdrecord -scanbus'. Make sure you are root. Running root:/root # exec 2>&1; devfsd /dev/ -t 3 -fg yields no more output afterwards, however sr_mod does not get loaded... root:/root # modprobe sr_mod Detected scsi CD-ROM sr0 at scsi0, channel 0, id 2, lun 0 Detected scsi CD-ROM sr1 at scsi1, channel 0, id 0, lun 0 sr0: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.12 sr1: scsi3-mmc drive: 4x/32x cd/rw xa/form2 cdda tray From owner-devfs@oss.sgi.com Thu May 3 17:28:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f440SFo22535 for devfs-outgoing; Thu, 3 May 2001 17:28:15 -0700 Received: from iaeste-catalunya.upc.es (iaeste-catalunya.upc.es [147.83.55.111]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f440SDF22524 for ; Thu, 3 May 2001 17:28:13 -0700 Received: (qmail 6147 invoked by uid 3); 4 May 2001 00:18:13 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 4 May 2001 00:18:13 -0000 Date: Fri, 4 May 2001 02:18:13 +0200 (CEST) From: Joan Picanyol i Puig To: devfs@oss.sgi.com Subject: Re: devfs & autloading In-Reply-To: <200105022150.f42Lojw30479@vindaloo.ras.ucalgary.ca> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1402171191-440203526-988935493=:6097" Sender: owner-devfs@oss.sgi.com Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1402171191-440203526-988935493=:6097 Content-Type: TEXT/PLAIN; charset=US-ASCII Sorry I forgot this bit: after running... root:/root # modprobe sr_mod Detected scsi CD-ROM sr0 at scsi0, channel 0, id 2, lun 0 Detected scsi CD-ROM sr1 at scsi1, channel 0, id 0, lun 0 sr0: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.12 sr1: scsi3-mmc drive: 4x/32x cd/rw xa/form2 cdda tray I efectively see... Looking for "scsi/host0/bus0/target2/lun0/cd" (0) made symlink: "sr/c0b0t2u0" for dev: 11,0 Looking for "scsi/host1/bus0/target0/lun0/cd" (0) made symlink: "sr/c1b0t0u0" for dev: 11,1 in my logging console. I'd like devfsd to do it by himself... The attached are the config files (just in case) --1402171191-440203526-988935493=:6097 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="modules.conf" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="modules.conf" I2FsaWFzIGNoYXItbWFqb3ItMTA4ICAgIHBwcF9nZW5lcmljDQojYWxpYXMg L2Rldi9wcHAgICAgICAgICAgcHBwX2dlbmVyaWMNCg0KIyBBTFNBIHBvcnRp b24NCmFsaWFzIGNoYXItbWFqb3ItMTE2IHNuZA0KYWxpYXMgc25kLWNhcmQt MCBzbmQtY2FyZC1vcGwzc2EyDQphbGlhcyBzb3VuZC1zZXJ2aWNlLTAtMCBz bmQtbWl4ZXItb3NzDQphbGlhcyBzb3VuZC1zZXJ2aWNlLTAtMSBzbmQtc2Vx LW9zcw0KYWxpYXMgc291bmQtc2VydmljZS0wLTMgc25kLXBjbS1vc3MNCmFs aWFzIHNvdW5kLXNlcnZpY2UtMC0xMiBzbmQtcGNtLW9zcw0KDQoNCiMgIyBP U1MvRnJlZSBwb3J0aW9uDQphbGlhcyBjaGFyLW1ham9yLTE0IHNvdW5kY29y ZQ0KYWxpYXMgc291bmQtc2xvdC0wIHNuZC1jYXJkLTANCmFsaWFzIHNvdW5k LXNlcnZpY2UtMS0wIHNuZC1taXhlci1vc3MNCmFsaWFzIHNvdW5kLXNlcnZp Y2UtMS0zIHNuZC1wY20tb3NzDQphbGlhcyBzb3VuZC1zZXJ2aWNlLTEtMTIg c25kLXBjbS1vc3MNCg0KYWxpYXMgdHR5LWxkaXNjLTMgICAgICAgcHBwX2Fz eW5jDQphbGlhcyB0dHktbGRpc2MtMTQgICAgICBwcHBfc3luY3R0eQ0KI2Fs aWFzIHBwcC1jb21wcmVzcy0yMSAgIGJzZF9jb21wDQojYWxpYXMgcHBwLWNv bXByZXNzLTI0ICAgcHBwX2RlZmxhdGUNCiNhbGlhcyBwcHAtY29tcHJlc3Mt MjYgICBwcHBfZGVmbGF0ZQ0KI2FsaWFzIGNoYXItbWFqb3ItMTE2IAlzbmQN CiNhbGlhcyBjaGFyLW1ham9yLTE0IAlzb3VuZGNvcmUNCm9wdGlvbnMgaWRl LWNkIGlnbm9yZT1oZGMNCg0KcHJlLWluc3RhbGwgc2cgICAgIG1vZHByb2Jl IGlkZS1zY3NpICMgbG9hZCBpZGUtc2NzaSBiZWZvcmUgc2cNCnByZS1pbnN0 YWxsIHNyX21vZCBtb2Rwcm9iZSBpZGUtc2NzaSAjIGxvYWQgaWRlLXNjc2kg YmVmb3JlIHNyX21vZA0KcHJlLWluc3RhbGwgaWRlLXNjc2kgbW9kcHJvYmUg aWRlLWNkICMgbG9hZCBpZGUtY2QgICBiZWZvcmUgaWRlLXNjc2kNCg0KDQo= --1402171191-440203526-988935493=:6097 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="modules.devfs" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="modules.devfs" IyAvZXRjL21vZHVsZXMuZGV2ZnMNCiMgUmljaGFyZCBHb29jaCAgPHJnb29j aEBhdG5mLmNzaXJvLmF1PgkJMy1KVUwtMjAwMA0KIw0KIyBUSElTIElTIEFO IEFVVE9NQVRJQ0FMTFkgR0VORVJBVEVEIEZJTEUuIERPIE5PVCBFRElUISEh DQojIFRISVMgRklMRSBXSUxMIEJFIE9WRVJXUklUVEVOIEVBQ0ggVElNRSBZ T1UgSU5TVEFMTCBERVZGU0QhISENCiMgTW9kaWZ5IC9ldGMvbW9kdWxlcy5j b25mIGluc3RlYWQuDQojIFRoaXMgZmlsZSBjb21lcyB3aXRoIGRldmZzZC12 MS4zLjExIHdoaWNoIGlzIGF2YWlsYWJsZSBmcm9tOg0KIyBodHRwOi8vd3d3 LmF0bmYuY3Npcm8uYXUvfnJnb29jaC9saW51eC8NCiMgb3IgZGlyZWN0bHkg ZnJvbToNCiMgZnRwOi8vZnRwLmF0bmYuY3Npcm8uYXUvcHViL3Blb3BsZS9y Z29vY2gvbGludXgvZGFlbW9ucy9kZXZmc2QtdjEuMy4xMS50YXIuZ3oNCg0K IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIw0KIyAgIFNhbXBs ZSBjb25maWd1cmF0aW9ucyB0aGF0IHlvdSBtYXkgd2FudCB0byBwbGFjZSBp biAvZXRjL21vZHVsZXMuY29uZg0KIw0KI2FsaWFzCQkvZGV2L3NvdW5kCQlz Yg0KI2FsaWFzCQkvZGV2L3Y0bAkJYnR0dg0KI2FsaWFzCQkvZGV2L21pc2Mv d2F0Y2hkb2cJcGN3ZA0KI2FsaWFzCQlnZW4tbWQJCQlyYWlkMA0KI2FsaWFz CQkvZGV2L2pveXN0aWNrcwkJam95c3RpY2sNCiNwcm9iZWFsbAlzY3NpLWhv c3RzCQlzeW01M2M4eHgNCg0KIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIw0KIyAgICAgICAgICAgICAgICAgICBHZW5lcmljIHNlY3Rpb246 IGRvIG5vdCBjaGFuZ2Ugb3IgY29weQ0KIw0KIyBBbGwgSEREcw0KcHJvYmVh bGwgIC9kZXYvZGlzY3MJCXNjc2ktaG9zdHMgc2RfbW9kIGlkZS1wcm9iZS1t b2QgaWRlLWRpc2sgDQoNCiMgQWxsIENELVJPTXMNCnByb2JlYWxsICAvZGV2 L2Nkcm9tcwkJc2NzaS1ob3N0cyBzcl9tb2QgaWRlLXByb2JlLW1vZCBpZGUt Y2QNCg0KIyBBbGwgdGFwZXMNCiNwcm9iZWFsbCAgL2Rldi90YXBlcwkJc2Nz aS1ob3N0cyBzdCBpZGUtcHJvYmUtbW9kIGlkZS10YXBlDQoNCiMgQWxsIFND U0kgZGV2aWNlcw0KcHJvYmVhbGwgIC9kZXYvc2NzaQkJc2NzaS1ob3N0cyBz ZF9tb2Qgc3JfbW9kIHN0IHNnDQoNCiMgQWxsIElERSBkZXZpY2VzDQpwcm9i ZWFsbCAgL2Rldi9pZGUJCWlkZS1wcm9iZS1tb2QgaWRlLWRpc2sgaWRlLXNj c2kgaWRlLWZsb3BweQ0KDQojIFNDU0kgSEREcw0KcHJvYmVhbGwgIC9kZXYv c2QJCXNjc2ktaG9zdHMgc2RfbW9kDQphbGlhcyAgICAgL2Rldi9zZCoJCS9k ZXYvc2QNCg0KIyBTQ1NJIENELVJPTXMNCnByb2JlYWxsICAvZGV2L3NyCQlz Y3NpLWhvc3RzIHNyX21vZA0KYWxpYXMgICAgIC9kZXYvc3IqCQkvZGV2L3Ny DQoNCiMgU0NTSSB0YXBlcw0KI3Byb2JlYWxsICAvZGV2L3N0CQlzY3NpLWhv c3RzIHN0DQojYWxpYXMgICAgIC9kZXYvc3QqCQkvZGV2L3N0DQojYWxpYXMg ICAgIC9kZXYvbnN0KgkJL2Rldi9zdA0KDQojIFNDU0kgZ2VuZXJpYw0KcHJv YmVhbGwgIC9kZXYvc2cJCXNjc2ktaG9zdHMgc2cNCmFsaWFzICAgICAvZGV2 L3NnKgkJL2Rldi9zZw0KDQojIEZsb3BwaWVzDQphbGlhcyAgICAgL2Rldi9m bG9wcHkJCWZsb3BweQ0KYWxpYXMgICAgIC9kZXYvZmQqCQlmbG9wcHkNCg0K IyBSQU1ESVNDcw0KI2FsaWFzICAgICAvZGV2L3JkCQlyZA0KI2FsaWFzICAg ICAvZGV2L3JhbSoJCXJkDQoNCiMgTG9vcCBkZXZpY2VzDQphbGlhcyAgICAg L2Rldi9sb29wKgkJbG9vcA0KDQojIE1ldGEgZGV2aWNlcw0KI2FsaWFzICAg ICAvZGV2L21kKgkJZ2VuLW1kDQoNCiMgUGFyYWxsZWwgcG9ydCBwcmludGVy cw0KI2FsaWFzICAgICAvZGV2L3ByaW50ZXJzKglscA0KI2FsaWFzICAgICAv ZGV2L2xwKgkJL2Rldi9wcmludGVycw0KDQojIFNvdW5kY2FyZA0KYWxpYXMg ICAgIC9kZXYvYXVkaW8JCS9kZXYvc291bmQNCmFsaWFzICAgICAvZGV2L21p eGVyCQkvZGV2L3NvdW5kDQphbGlhcyAgICAgL2Rldi9kc3AJCS9kZXYvc291 bmQNCmFsaWFzICAgICAvZGV2L2RzcFcJCS9kZXYvc291bmQNCmFsaWFzICAg ICAvZGV2L21pZGkJCS9kZXYvc291bmQNCg0KIyBKb3lzdGlja3MNCiNhbGlh cyAgICAgL2Rldi9qcyoJCS9kZXYvam95c3RpY2tzDQoNCiMgU2VyaWFsIHBv cnRzDQphbGlhcyAgICAgL2Rldi90dHMqCQlzZXJpYWwNCmFsaWFzICAgICAv ZGV2L3R0eVMqCQkvZGV2L3R0cw0KYWxpYXMgICAgIC9kZXYvY3VhKgkJL2Rl di90dHMNCg0KIyBNaXNjZWxsYW5lb3VzIGRldmljZXMNCiNhbGlhcyAgICAg L2Rldi9taXNjL2F0aWJtCWF0aXhsbW91c2UNCiNhbGlhcyAgICAgL2Rldi9t aXNjL2lucG9ydGJtCW1zYnVzbW91c2UNCiNhbGlhcyAgICAgL2Rldi9taXNj L2xvZ2libQlidXNtb3VzZQ0KDQojIFBQUCBkZXZpY2VzDQojYWxpYXMgICAg IC9kZXYvcHBwKgkJcHBwX2dlbmVyaWMNCg0KIyBWaWRlbyBjYXB0dXJlIGRl dmljZXMNCiNhbGlhcyAgICAgL2Rldi92aWRlbyoJCS9kZXYvdjRsDQojYWxp YXMgICAgIC9kZXYvdmJpKgkJL2Rldi92NGwNCg0KIyBQdWxsIGluIHRoZSBj b25maWd1cmF0aW9uIGZpbGUuIERvIHRoaXMgbGFzdCBiZWNhdXNlIG1vZHBy b2JlKDgpIHByb2Nlc3NlcyBpbg0KIyBwZXJeSF5IXkhyZXZlcnNlIG9yZGVy IGFuZCB0aGUgc3lzYWRtaW4gbWF5IHdhbnQgdG8gb3Zlci1yaWRlIHdoYXQg aXMgaW4gdGhlDQojIGdlbmVyaWMgZmlsZQ0KDQo= --1402171191-440203526-988935493=:6097 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="devfsd.conf" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="devfsd.conf" IyBTYW1wbGUgL2V0Yy9kZXZmc2QuY29uZiBjb25maWd1cmF0aW9uIGZpbGUu DQojIFJpY2hhcmQgR29vY2ggIDxyZ29vY2hAYXRuZi5jc2lyby5hdT4JCTMt SlVMLTIwMDANCiMNCiMgRW5hYmxlIGZ1bGwgY29tcGF0aWJpbGl0eSBtb2Rl IGZvciBvbGQgZGV2aWNlIG5hbWVzLiBZb3UgbWF5IGNvbW1lbnQgdGhlc2UN CiMgb3V0IGlmIHlvdSBkb24ndCB1c2UgdGhlIG9sZCBkZXZpY2UgbmFtZXMu IE1ha2Ugc3VyZSB5b3Uga25vdyB3aGF0IHlvdSdyZQ0KIyBkb2luZyENCiNS RUdJU1RFUgkuKglNS09MRENPTVBBVA0KI1VOUkVHSVNURVIJLioJUk1PTERD T01QQVQNCg0KIyBZb3UgbWF5IGNvbW1lbnQgb3V0IHRoZSBhYm92ZSBhbmQg dW5jb21tZW50IHRoZSBmb2xsb3dpbmcgaWYgeW91J3ZlDQojIGNvbmZpZ3Vy ZWQgeW91ciBzeXN0ZW0gdG8gdXNlIHRoZSBvcmlnaW5hbCAibmV3IiBkZXZm cyBuYW1lcyBvciB0aGUgcmVhbGx5DQojIG5ldyBuYW1lcw0KUkVHSVNURVIJ dmMvLioJCU1LT0xEQ09NUEFUDQpVTlJFR0lTVEVSCXZjLy4qCQlSTU9MRENP TVBBVA0KUkVHSVNURVIJcHR5Ly4qCQlNS09MRENPTVBBVA0KVU5SRUdJU1RF UglwdHkvLioJCVJNT0xEQ09NUEFUDQpSRUdJU1RFUgltaXNjCQlNS09MRENP TVBBVA0KVU5SRUdJU1RFUgltaXNjCQlSTU9MRENPTVBBVA0KDQojIFlvdSBt YXkgY29tbWVudCB0aGVzZSBvdXQgaWYgeW91IGRvbid0IHVzZSB0aGUgb3Jp Z2luYWwgIm5ldyIgbmFtZXMNClJFR0lTVEVSCS4qCQlNS05FV0NPTVBBVA0K VU5SRUdJU1RFUgkuKgkJUk1ORVdDT01QQVQNCg0KIyBFbmFibGUgbW9kdWxl IGF1dG9sb2FkaW5nLiBZb3UgbWF5IGNvbW1lbnQgdGhpcyBvdXQgaWYgeW91 IGRvbid0IHVzZQ0KIyBhdXRvbG9hZGluZw0KTE9PS1VQCQkuKgkJTU9ETE9B RA0KDQojQUxTQSBkcml2ZXJzDQpMT09LVVAgc25kICBNT0RMT0FEIHNuZA0K UkVHSVNURVIgc291bmQvLiogUEVSTUlTU0lPTlMgcm9vdC5hdWRpbyA2NjAN ClJFR0lTVEVSIHNuZC8uKiBQRVJNSVNTSU9OUyByb290LmF1ZGlvIDY2MA0K DQojIFVuY29tbWVudCB0aGlzIGlmIHlvdSB3YW50IHBlcm1pc3Npb25zIHRv IGJlIHNhdmVkIGFuZCByZXN0b3JlZA0KI1JFR0lTVEVSCS4qCQlDT1BZCS9k ZXYtc3RhdGUvJGRldm5hbWUgJGRldnBhdGgNCiNDSEFOR0UJCS4qCQlDT1BZ CSRkZXZwYXRoIC9kZXYtc3RhdGUvJGRldm5hbWUNCiNDUkVBVEUJCS4qCQlD T1BZCSRkZXZwYXRoIC9kZXYtc3RhdGUvJGRldm5hbWUNCg== --1402171191-440203526-988935493=:6097-- From owner-devfs@oss.sgi.com Thu May 3 23:15:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f446FN429668 for devfs-outgoing; Thu, 3 May 2001 23:15:23 -0700 Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f446FMF29665 for ; Thu, 3 May 2001 23:15:22 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id f446FEo04729; Fri, 4 May 2001 00:15:14 -0600 Date: Fri, 4 May 2001 00:15:14 -0600 Message-Id: <200105040615.f446FEo04729@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Joan Picanyol i Puig Cc: devfs@oss.sgi.com Subject: Re: devfs & autoloading In-Reply-To: References: <200105022150.f42Lojw30479@vindaloo.ras.ucalgary.ca> Sender: owner-devfs@oss.sgi.com Precedence: bulk Joan Picanyol i. Puig writes: > Hi again, I definitely think I'm getting closer now > > On Wed, 2 May 2001, Richard Gooch wrote: > > > I assume you're running glibc? In that case, talk to the glibc > > maintainers. It sounds like their ttyname(3) implementation doesn't > > scan /dev/pty for terminals. > I'm running glibc-2.1.3 and you mention a 'similar fix', could you > point to the patch for it please (I'd just like to get rid of > MKOLDCOMPAT...)? The patch I referred to in the FAQ is only about ttyname(3) dealing correctly with symbolic links. It does not have anything to do with scanning /dev/pty. That would require a separate patch. Someone would need to write that. Alternatively, try to get a version of your application that uses Unix98 ptys instead. > Well, my question wasn't precise enough (as a matter of fact nor correct I > forgot to do this before), here's what I've done with the configuration files > attached: > > 1 scsi hd & 1 ide hd already working > root:/root # ls /dev/discs/ -l > total 0 > lr-xr-xr-x 1 root root 30 Jan 1 1970 disc0 -> > ../ide/host0/bus0/target0/lun0 > lr-xr-xr-x 1 root root 31 Jan 1 1970 disc1 -> > ../scsi/host0/bus0/target6/lun0 > > These work fine (thankfully), the problem comes with module autoloading: > > root:/root # cdrecord -scanbus > Cdrecord 1.9 (i686-pc-linux-gnu) Copyright (C) 1995-2000 Jörg Schilling > cdrecord: No such file or directory. Cannot open SCSI driver. > cdrecord: For possible targets try 'cdrecord -scanbus'. Make sure you are root. I don't know what problem you were having. I don't keep records of bug reports with insufficient information (my mailbox isn't big enough). So I need bug reports with a description of the problem and symptoms, and complete debugging information. Followup messages need to keep sufficient context so I can look at the message in isolation, and have all the information I need. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Sun May 6 12:17:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f46JHa110357 for devfs-outgoing; Sun, 6 May 2001 12:17:36 -0700 Received: from smtp.hccnet.nl (smtp.hccnet.nl [62.251.0.13]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f46JHYF10354 for ; Sun, 6 May 2001 12:17:34 -0700 Received: from oemcomputer by smtp.hccnet.nl via uds22-33.dial.hccnet.nl [62.251.33.22] with SMTP for id VAA16527 (8.8.5/1.13); Sun, 6 May 2001 21:17:31 +0200 (MET DST) Message-ID: <006501c0d662$eeda5900$0a00a8c0@oemcomputer> Reply-To: "jako fritz" From: "jako fritz" To: Subject: help on hdparm Date: Sun, 6 May 2001 21:29:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-devfs@oss.sgi.com Precedence: bulk i´m not sure if this is to list to ask it but i´ll try anyway. hdparm can´t set the setdma flag HDIO_SET_DMA and give the error permission denied. it´s the cause of devfs becaus on exactly the same system but with normal nodes it works just fine. Ok hdparm prolly is not adapted to work with devfs. but has anyone encountered the problem and is there a fix? thanx jako fritz From owner-devfs@oss.sgi.com Sun May 6 12:21:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f46JLCb10622 for devfs-outgoing; Sun, 6 May 2001 12:21:12 -0700 Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f46JLCF10619 for ; Sun, 6 May 2001 12:21:12 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id f46JLCI22191; Sun, 6 May 2001 13:21:12 -0600 Date: Sun, 6 May 2001 13:21:12 -0600 Message-Id: <200105061921.f46JLCI22191@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: "jako fritz" Cc: Subject: Re: help on hdparm In-Reply-To: <006501c0d662$eeda5900$0a00a8c0@oemcomputer> References: <006501c0d662$eeda5900$0a00a8c0@oemcomputer> Sender: owner-devfs@oss.sgi.com Precedence: bulk jako fritz writes: > i´m not sure if this is to list to ask it but i´ll try anyway. > hdparm can´t set the setdma flag HDIO_SET_DMA and give the error permission > denied. it´s the cause of devfs becaus on exactly the same system but with > normal nodes it works just fine. Ok hdparm prolly is not adapted to work > with devfs. but has anyone encountered the problem and is there a fix? I use hdparm all the time on my machines. I have devfs running on all my machines (obviously!). I don't use the HDIO_SET_DMA flag, but I do use it to control the spin-down time as well as determine the power status. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Sun May 6 12:56:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f46JufU11628 for devfs-outgoing; Sun, 6 May 2001 12:56:41 -0700 Received: from mail8.nc.rr.com (fe8.southeast.rr.com [24.93.67.55]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f46JueF11625 for ; Sun, 6 May 2001 12:56:40 -0700 Received: from socrates ([24.162.238.214]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.537.53); Sun, 6 May 2001 15:53:03 -0400 From: jeffj@ro.com Date: Sun, 06 May 2001 15:54:41 -0500 To: "jako fritz" In-Reply-To: <006501c0d662$eeda5900$0a00a8c0@oemcomputer> Cc: Subject: Re: help on hdparm X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.75a b75 Message-ID: <0864e0353190651FE8@mail8.nc.rr.com> Sender: owner-devfs@oss.sgi.com Precedence: bulk "jako fritz" said the following on the auspicious date of 01-05-06: >i m not sure if this is to list to ask it but i ll try anyway. hdparm >can t set the setdma flag HDIO_SET_DMA and give the error permission >denied. it s the cause of devfs becaus on exactly the same system but >with normal nodes it works just fine. Ok hdparm prolly is not adapted to >work with devfs. but has anyone encountered the problem and is there a >fix? It sounds like you tried using hdparm on the devfs system while not logged in as root. I have tried to set the DMA stuff using hdparm on a system with devfs and it gave no error, although it did crash the whole system. I have no reason to believe devfs had anything to do with the crash though. -------------------------------------------------- Windows95 -- An entomologist's dream Jeff Jackowski http://ro.com/~jeffj/ OS/2 WPS (Desktop) Tips, remote i-net dialup "Luncheon meats make the sawdust in your stomach explode." -- Crow T. Robot From owner-devfs@oss.sgi.com Sun May 6 16:31:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f46NVvt16325 for devfs-outgoing; Sun, 6 May 2001 16:31:57 -0700 Received: from gec.gecpalau.com (gec.gecpalau.com [206.49.60.67]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f46NVeF16320 for ; Sun, 6 May 2001 16:31:44 -0700 Received: from gecpalau.com (rieacs.gecpalau.com [206.49.60.69]) by gec.gecpalau.com (8.11.2/8.11.2) with ESMTP id f46NTA129061; Mon, 7 May 2001 08:29:10 +0900 Message-ID: <3AF5DE48.3DF21242@gecpalau.com> Date: Mon, 07 May 2001 08:29:12 +0900 From: Glenn Shannon X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.4.3-GECKERN i686) X-Accept-Language: en MIME-Version: 1.0 To: jeffj@ro.com CC: jako fritz , devfs@oss.sgi.com Subject: Re: help on hdparm References: <0864e0353190651FE8@mail8.nc.rr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-devfs@oss.sgi.com Precedence: bulk I, for one, have DevFS running along with hdparm and have all the settings fully tweaked. No problems here.. Glenn jeffj@ro.com wrote: > "jako fritz" said the following on the auspicious date of 01-05-06: > > >i m not sure if this is to list to ask it but i ll try anyway. hdparm > >can t set the setdma flag HDIO_SET_DMA and give the error permission > >denied. it s the cause of devfs becaus on exactly the same system but > >with normal nodes it works just fine. Ok hdparm prolly is not adapted to > >work with devfs. but has anyone encountered the problem and is there a > >fix? > > It sounds like you tried using hdparm on the devfs system while not logged in as root. I have tried to set the DMA stuff using hdparm on a system with devfs and it gave no error, although it did crash the whole system. I have no reason to believe devfs had anything to do with the crash though. > > -------------------------------------------------- > Windows95 -- An entomologist's dream > > Jeff Jackowski http://ro.com/~jeffj/ > OS/2 WPS (Desktop) Tips, remote i-net dialup > "Luncheon meats make the sawdust in your stomach > explode." -- Crow T. Robot From owner-devfs@oss.sgi.com Sun May 6 22:30:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f475U4R22975 for devfs-outgoing; Sun, 6 May 2001 22:30:04 -0700 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f475U3F22972 for ; Sun, 6 May 2001 22:30:03 -0700 Received: from war.Aus.Sun.COM ([129.158.10.191]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA27906 for ; Sun, 6 May 2001 22:30:01 -0700 (PDT) Received: from aus.sun.com (dhcp-syd04-12-9 [129.158.12.9]) by war.Aus.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA19302 for ; Mon, 7 May 2001 15:30:00 +1000 (EST) Message-ID: <3AF63319.BF7933D4@aus.sun.com> Date: Mon, 07 May 2001 15:31:05 +1000 From: Craig Armour Organization: Sun Microsystems X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.4 i686) X-Accept-Language: en MIME-Version: 1.0 To: devfs@oss.sgi.com Subject: /dev-state /dev and path_to_inst Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-devfs@oss.sgi.com Precedence: bulk Hi, for the reason of "this is a really good thing to have", my laptop is completely devfs'd I've been running it devfs'd now for a few months and have a few changes I'd like to see/impliment but won't bother if they would fall on deaf ears problem: * /dev-state is a cludgy way of keep file permsions consistent * my laptop has 2 cdroms which are replaceable with a floppy drive ( internal ). devfsd will number the drives in the order they are probed each time. This becomes a hassle when you go to mount /dev/cdroms/cdrom1 you might say that I would be biased in my solution to the above, but has the idea of a path_to_inst been explored? a possible layout could be for example ### FUll Device Path ################# Mode ############ device type /dev/ide/host0/bus0/target0/lun0/disc , 400 , hd /dev/scsi/host0/bus0/target0/lun0/cd , 400 , cdrom etc... each time the system boots with a new device, if the device isn't in the path_to_inst, it gets appended. /dev tree can then be created based on the path_to_inst and not the probe order for each boot. In this case, the cdrom listed will always be listed as cdrom0 as it is the first cdrom in the path_to_inst, even if an ide cdrom is added later. I believe that is a much better solution then the current /dev-state method. I realise I could probably do something similar through devfsd.conf etc... but I believe this should be a core devfs thing. If no-one is interested and/or willing to test such things, then I may not go to much further than "it's just an idea". But if there is some interest, I would be willing to put the time in to produce some code to do the above. The devfsd code seems very easy to read and I don't think it would be too hard to impliment such changes ... it's just an idea though Cheers Craig -- Craig Armour Craig.Armour@aus.sun.com Enterprise Systems Administrator Phone: +61 2 9844 7292 Installation Consulting Services 828 Pacific Highway Sun Microsytems Australia Gordon NSW 2072 From owner-devfs@oss.sgi.com Fri May 11 13:34:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4BKYm508022 for devfs-outgoing; Fri, 11 May 2001 13:34:48 -0700 Received: from tgos.org (europa.your-site.com [140.186.45.2]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4BKYkF08019 for ; Fri, 11 May 2001 13:34:46 -0700 Received: from port3 ([213.23.60.43]) by tgos.org ; Fri, 11 May 2001 16:34:45 -0400 Date: Fri, 11 May 2001 22:34:46 +0200 From: TGOS X-Mailer: The Bat! (v1.45) Personal Organization: TGOS.org X-Priority: 3 (Normal) Message-ID: <3518930212.20010511223446@tgos.org> To: devfs@oss.sgi.com Subject: DEVFSD and modules - does it really work? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-devfs@oss.sgi.com Precedence: bulk Hello everyone, I only subscribed to that mailing list, because I'm a very curious person and I always have to know everything. ^_- Once I read about DEVFS, I simply had to try it. I installed DEVFSD, recompiled the Kernel (v 2.4.2) and everything worked fine. Except one problem: My HDs are /dev/hgd and /dev/hdf (connected to my second IDE controller). Both had been there (thanks to DEVFSD), as well as under their new name. But my CDROM wasn't there anymore. It usually should be /dev/hda, but neither that, nor the new device names for the first IDE controller existed. I recompiled the kernel and found out that the CDROM support was set to "module". After I compiled it into the Kernel, the device was there (/dev/hda) and I could use it. But since I don't use the CDROM pretty often, I usually compile CDROM support and the ISO9660 support as modules. Here's my question: I thought if I compile the CDROM support as module and later on load that module, the DEVFS will add a new device and thanks to DEVFSD it will also exist as /dev/hda But it wasn't there. Is there any way to get it there or is the only chance compiling CDROM support into the Kernel? -- Best regards, TGOS From owner-devfs@oss.sgi.com Fri May 11 14:51:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4BLpNo24467 for devfs-outgoing; Fri, 11 May 2001 14:51:23 -0700 Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4BLpLF24464 for ; Fri, 11 May 2001 14:51:22 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id f4BLp7a13310; Fri, 11 May 2001 15:51:07 -0600 Date: Fri, 11 May 2001 15:51:07 -0600 Message-Id: <200105112151.f4BLp7a13310@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: TGOS Cc: devfs@oss.sgi.com Subject: Re: DEVFSD and modules - does it really work? In-Reply-To: <3518930212.20010511223446@tgos.org> References: <3518930212.20010511223446@tgos.org> Sender: owner-devfs@oss.sgi.com Precedence: bulk tgos@tgos.org writes: > Hello everyone, > > I only subscribed to that mailing list, because I'm a very curious person and I > always have to know everything. ^_- > > Once I read about DEVFS, I simply had to try it. > I installed DEVFSD, recompiled the Kernel (v 2.4.2) and everything worked fine. > > Except one problem: > My HDs are /dev/hgd and /dev/hdf (connected to my second IDE controller). > Both had been there (thanks to DEVFSD), as well as under their new name. > > But my CDROM wasn't there anymore. It usually should be /dev/hda, but neither > that, nor the new device names for the first IDE controller existed. > > I recompiled the kernel and found out that the CDROM support was set to > "module". After I compiled it into the Kernel, the device was there (/dev/hda) > and I could use it. > > But since I don't use the CDROM pretty often, I usually compile CDROM support > and the ISO9660 support as modules. > > > Here's my question: > I thought if I compile the CDROM support as module and later on load > that module, the DEVFS will add a new device and thanks to DEVFSD it > will also exist as /dev/hda > But it wasn't there. > > Is there any way to get it there or is the only chance compiling > CDROM support into the Kernel? I have all my IDE drivers as modules, and my IDE CD-ROM shows up just fine under /dev/ide. The modules I have loaded are: isofs 19600 0 (unused) ide-cd 27264 0 cdrom 28416 0 [ide-cd] ide-probe-mod 9344 0 ide-mod 64480 0 [ide-cd ide-probe-mod] with the bottom one loaded first. As a sanity check, look at your kernel logs and see if you get a message like: hdb: ATAPI 48X CD-ROM drive, 128kB Cache, DMA This is supposed to come from the ide-cd module, when it detects your CD-ROM. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Fri May 11 18:33:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4C1Xn427829 for devfs-outgoing; Fri, 11 May 2001 18:33:49 -0700 Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4C1XlF27826 for ; Fri, 11 May 2001 18:33:47 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id f4C1X7K16680; Fri, 11 May 2001 19:33:07 -0600 Date: Fri, 11 May 2001 19:33:07 -0600 Message-Id: <200105120133.f4C1X7K16680@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Craig Armour Cc: devfs@oss.sgi.com Subject: Re: /dev-state /dev and path_to_inst In-Reply-To: <3AF63319.BF7933D4@aus.sun.com> References: <3AF63319.BF7933D4@aus.sun.com> Sender: owner-devfs@oss.sgi.com Precedence: bulk Craig Armour writes: > I've been running it devfs'd now for a few months and have a few changes > I'd like to see/impliment but won't bother if they would fall on deaf > ears > > problem: > * /dev-state is a cludgy way of keep file permsions consistent Actually, it's really neat and preserves existing Unix semantics for those who want it. > * my laptop has 2 cdroms which are replaceable with a floppy drive ( > internal ). devfsd will number the drives in the order they are > probed each time. This becomes a hassle when you go to mount > /dev/cdroms/cdrom1 /dev/cdroms is where all CD-ROMs are placed. If you want persistent device names, then don't use /dev/cdroms. > you might say that I would be biased in my solution to the above, but > has the idea of a path_to_inst been explored? > > a possible layout could be for example > > ### FUll Device Path ################# Mode ############ device type > /dev/ide/host0/bus0/target0/lun0/disc , 400 , hd > /dev/scsi/host0/bus0/target0/lun0/cd , 400 , cdrom > > etc... > > each time the system boots with a new device, if the device isn't in > the path_to_inst, it gets appended. /dev tree can then be created > based on the path_to_inst and not the probe order for each boot. In > this case, the cdrom listed will always be listed as cdrom0 as it is > the first cdrom in the path_to_inst, even if an ide cdrom is added > later. Nope, this is a horrible idea. If you want to point at the SCSI CD-ROM, then use the name under /dev/scsi. These automatically growing databases of "convenient" names are a bad idea. They are fragile and develop cruft over time. > I believe that is a much better solution then the current /dev-state > method. I disagree, most strongly. > I realise I could probably do something similar through devfsd.conf > etc... but I believe this should be a core devfs thing. If no-one > is interested and/or willing to test such things, then I may not go > to much further than "it's just an idea". But if there is some > interest, I would be willing to put the time in to produce some code > to do the above. The devfsd code seems very easy to read and I > don't think it would be too hard to impliment such changes A "core devfs thing" is a kernel hack. There is absolutely no way in hell that some kind of file-based database will ever be managed by the kernel. That kind of code belongs in user-space. And if it's in user-space, then devfsd is the logical place to put it. However, I don't like the idea of such a database, so I'm not going to implement such a hack for devfsd either. You're welcome to do it yourself (even though I think the idea is flawed), but I hope you don't. I think it's entirely the wrong approach. I would prefer to implement solutions that solve real problems cleanly. I've had the growing-database argument with people from another old Unix vendor, and I think that "solution" reflects an outmoded way of looking at things. Some "problems" should be solved by user re-education, not by gross hacks. I realise that as a vendor, it's hard to say "no" when users scream for something (especially if they wave lots of money at you). However, in the Linux community we can and do say "no, do it this way instead". Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Sat May 12 21:51:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4D4pwu16934 for devfs-outgoing; Sat, 12 May 2001 21:51:58 -0700 Received: from mail.labsysgrp.com (phnx1-blk2-hfc-0251-d1db10f1.rdc1.az.coxatwork.com [209.219.16.241]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4D4puF16931 for ; Sat, 12 May 2001 21:51:56 -0700 Received: from jeeves.kpf.internal ([192.168.170.1]) by mail.labsysgrp.com with esmtp (Exim 3.22 #2) id 14ynr7-0002pY-00 for devfs@oss.sgi.com; Sat, 12 May 2001 21:51:46 -0700 Received: from [192.168.170.101] (helo=Kevin) by jeeves.kpf.internal with smtp (Exim 3.22 #3) id 14ynqr-0004iU-00 for devfs@oss.sgi.com; Sat, 12 May 2001 21:51:29 -0700 Message-ID: <002001c0db68$ec727660$65aaa8c0@Kevin> From: "Kevin P. Fleming" Cc: References: <3518930212.20010511223446@tgos.org> <200105112151.f4BLp7a13310@vindaloo.ras.ucalgary.ca> Subject: Re: DEVFSD and modules - does it really work? Date: Sat, 12 May 2001 21:55:25 -0700 Organization: LSG, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-devfs@oss.sgi.com Precedence: bulk This has got me to thinking about something I thought about when I first put devfs/devfsd on my machine; using the "standard" way of doing things, if you compile CDROM support as a module, then you won't have _any_ /dev entries until after you have loaded that/those modules. If you later unload them, the /dev entries stay around and will cause the modules to be reloaded if you access them. This is good. The problem is that the entries don't exist until after you have loaded the modules the first time, which kind of defeats the purpose of having the CDROM support as a module in the first place. The only workaround right now is to set up your /etc/devfsd.conf file to force them to be loaded, but this relies on you knowing where your CD-ROM drives are located on your IDE busses, and thus compromises some of the elegance of using devfs in the first place. Has any thought ever been given to allowing each module to load, identify the devices it can support that are currently attached to the machine, register the appropriate devfs entries, then unload itself? There are some obvious limits to this (it won't work for hot-plugged devices, for one), and of course I could accomplish the same thing by manually loading/unloading said modules in one of my init scripts, but again, this defeats the elegance of devfs. If this just "worked", as the user expected, meaning that if your machine has one or mode IDE CD-ROM drives attached, they would appear under /dev/cdroms regardless of whether CD-ROM support was modular or compiled in, this would make devfs much easier for users to deal with. I realize, of course, that this would be quite a significant change to the driver modules, and may not be possible at all, but I throw it out for consideration regardless :-) ----- Original Message ----- From: "Richard Gooch" To: "TGOS" Cc: Sent: Friday, May 11, 2001 2:51 PM Subject: Re: DEVFSD and modules - does it really work? > tgos@tgos.org writes: > > Hello everyone, > > > > I only subscribed to that mailing list, because I'm a very curious person and I > > always have to know everything. ^_- > > > > Once I read about DEVFS, I simply had to try it. > > I installed DEVFSD, recompiled the Kernel (v 2.4.2) and everything worked fine. > > > > Except one problem: > > My HDs are /dev/hgd and /dev/hdf (connected to my second IDE controller). > > Both had been there (thanks to DEVFSD), as well as under their new name. > > > > But my CDROM wasn't there anymore. It usually should be /dev/hda, but neither > > that, nor the new device names for the first IDE controller existed. > > > > I recompiled the kernel and found out that the CDROM support was set to > > "module". After I compiled it into the Kernel, the device was there (/dev/hda) > > and I could use it. > > > > But since I don't use the CDROM pretty often, I usually compile CDROM support > > and the ISO9660 support as modules. > > > > > > Here's my question: > > I thought if I compile the CDROM support as module and later on load > > that module, the DEVFS will add a new device and thanks to DEVFSD it > > will also exist as /dev/hda > > But it wasn't there. > > > > Is there any way to get it there or is the only chance compiling > > CDROM support into the Kernel? > > I have all my IDE drivers as modules, and my IDE CD-ROM shows up just > fine under /dev/ide. The modules I have loaded are: > isofs 19600 0 (unused) > ide-cd 27264 0 > cdrom 28416 0 [ide-cd] > ide-probe-mod 9344 0 > ide-mod 64480 0 [ide-cd ide-probe-mod] > > with the bottom one loaded first. > > As a sanity check, look at your kernel logs and see if you get a > message like: > hdb: ATAPI 48X CD-ROM drive, 128kB Cache, DMA > > This is supposed to come from the ide-cd module, when it detects your > CD-ROM. > > Regards, > > Richard.... > Permanent: rgooch@atnf.csiro.au > Current: rgooch@ras.ucalgary.ca > > > From owner-devfs@oss.sgi.com Sun May 13 16:43:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4DNhEU31736 for devfs-outgoing; Sun, 13 May 2001 16:43:14 -0700 Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4DNhDF31733 for ; Sun, 13 May 2001 16:43:13 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id f4DNgoT06202; Sun, 13 May 2001 17:42:50 -0600 Date: Sun, 13 May 2001 17:42:50 -0600 Message-Id: <200105132342.f4DNgoT06202@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: "Kevin P. Fleming" Cc: Subject: Re: DEVFSD and modules - does it really work? In-Reply-To: <002001c0db68$ec727660$65aaa8c0@Kevin> References: <3518930212.20010511223446@tgos.org> <200105112151.f4BLp7a13310@vindaloo.ras.ucalgary.ca> <002001c0db68$ec727660$65aaa8c0@Kevin> Sender: owner-devfs@oss.sgi.com Precedence: bulk Kevin P. Fleming writes: > This has got me to thinking about something I thought about when I > first put devfs/devfsd on my machine; using the "standard" way of > doing things, if you compile CDROM support as a module, then you > won't have _any_ /dev entries until after you have loaded that/those > modules. If you later unload them, the /dev entries stay around and > will cause the modules to be reloaded if you access them. This is > good. Actually, if you unload the modules, the devfs entries should disappear. If not, that's a bug. A bug I haven't seen before. > The problem is that the entries don't exist until after you have > loaded the modules the first time, which kind of defeats the purpose > of having the CDROM support as a module in the first place. The only > workaround right now is to set up your /etc/devfsd.conf file to > force them to be loaded, but this relies on you knowing where your > CD-ROM drives are located on your IDE busses, and thus compromises > some of the elegance of using devfs in the first place. You don't need to know where the CD-ROMs are placed. That's why accessing via /dev/cdroms is preferred. The /etc/modules.devfs file provides generic configuration so that the appropriate drivers are loaded. > Has any thought ever been given to allowing each module to load, > identify the devices it can support that are currently attached to > the machine, register the appropriate devfs entries, then unload > itself? There are some obvious limits to this (it won't work for > hot-plugged devices, for one), and of course I could accomplish the > same thing by manually loading/unloading said modules in one of my > init scripts, but again, this defeats the elegance of devfs. If this > just "worked", as the user expected, meaning that if your machine > has one or mode IDE CD-ROM drives attached, they would appear under > /dev/cdroms regardless of whether CD-ROM support was modular or > compiled in, this would make devfs much easier for users to deal > with. There has been talk about adding an info section to modules that modutils can parse, which would contain device name regular expressions. That could then be passed to devfsd. But that's a more complex solution. Just use /dev/cdroms instead. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Mon May 14 11:43:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4EIh5f19260 for devfs-outgoing; Mon, 14 May 2001 11:43:05 -0700 Received: from myrealbox.com (mail.myrealbox.com [192.108.102.201]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EIguF19253 for ; Mon, 14 May 2001 11:43:01 -0700 Received: from vtp.myrealbox.com [148.221.119.20] by myrealbox.com with Novonyx SMTP Server $Revision: 2.75.1.6 $; Mon, 14 May 2001 12:31:53 -0600 (MDT) Message-Id: <5.1.0.14.2.20010514133640.009d1480@pop.myrealbox.com> X-Sender: ollidec@pop.myrealbox.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 14 May 2001 13:40:18 -0600 To: devfs@oss.sgi.com From: Ernesto CEDILLO-ARIAS Subject: Chroot question Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-devfs@oss.sgi.com Precedence: bulk Hello Richard How is Devfs behaving towards chroot jailed environments? I haven't tried to install one, as a matter of fact I am still using old-fashion device file system for an apache server. The problem is I must create another /dev entry within a separate directory and I don't know how to relate it to devfs . What is, so, the current state of things? Thanks From owner-devfs@oss.sgi.com Mon May 14 18:06:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4F16Mi28644 for devfs-outgoing; Mon, 14 May 2001 18:06:22 -0700 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4F16KF28641 for ; Mon, 14 May 2001 18:06:21 -0700 Received: from war.Aus.Sun.COM ([129.158.80.191]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA26212; Mon, 14 May 2001 18:06:16 -0700 (PDT) Received: from aus.sun.com (dhcp-syd04-12-9 [129.158.12.9]) by war.Aus.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA14488; Tue, 15 May 2001 11:06:14 +1000 (EST) Message-ID: <3B00814A.5580ECA9@aus.sun.com> Date: Tue, 15 May 2001 11:07:22 +1000 From: Craig Armour Organization: Sun Microsystems X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.4 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ernesto CEDILLO-ARIAS CC: devfs@oss.sgi.com Subject: Re: Chroot question References: <5.1.0.14.2.20010514133640.009d1480@pop.myrealbox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-devfs@oss.sgi.com Precedence: bulk > How is Devfs behaving towards chroot jailed environments? > I haven't tried to install one, as a matter of fact I am still using > old-fashion device file system for an apache server. > The problem is I must create another /dev entry within a separate directory > and I don't know how to relate it to devfs . > What is, so, the current state of things? > > Thanks try the following mount -t devfs devfs /chroot/dev this is in addition to your standard /dev tree and seems to work quite fine. I can not see any reason why it would not. Effectively ( but not quite ), /dev and /chroot/dev become carbon copies. I mounted /tmp/dev in this fashion and could successfully eject my cdrom useing both device trees. it would be interesting if two process' tried to access the same device through a different tree at the same time though. Could this be a problem that may need to be addressed? You will have to play with devfsd.conf if you want different things to happen within /chroot/dev and /dev. Is it possible to have devices appear in /dev and not /chroot/dev? etc... Cheers Craig Opinions here are my own and do not reflect those of my employer, Sun Microsystems. -- Craig Armour Craig.Armour@aus.sun.com Enterprise Systems Administrator Phone: +61 2 9844 7292 Installation Consulting Services 828 Pacific Highway Sun Microsytems Australia Gordon NSW 2072 From owner-devfs@oss.sgi.com Mon May 14 18:34:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4F1YUS29446 for devfs-outgoing; Mon, 14 May 2001 18:34:30 -0700 Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4F1YTF29443 for ; Mon, 14 May 2001 18:34:29 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id f4F1XdE20227; Mon, 14 May 2001 19:33:39 -0600 Date: Mon, 14 May 2001 19:33:39 -0600 Message-Id: <200105150133.f4F1XdE20227@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Craig Armour Cc: Ernesto CEDILLO-ARIAS , devfs@oss.sgi.com Subject: Re: Chroot question In-Reply-To: <3B00814A.5580ECA9@aus.sun.com> References: <5.1.0.14.2.20010514133640.009d1480@pop.myrealbox.com> <3B00814A.5580ECA9@aus.sun.com> Sender: owner-devfs@oss.sgi.com Precedence: bulk Craig Armour writes: > > How is Devfs behaving towards chroot jailed environments? > > I haven't tried to install one, as a matter of fact I am still using > > old-fashion device file system for an apache server. > > The problem is I must create another /dev entry within a separate directory > > and I don't know how to relate it to devfs . > > What is, so, the current state of things? > > > > Thanks > > try the following > > mount -t devfs devfs /chroot/dev That will give you a whole devfs tree. Binding individual entries is better if you want a restricted chroot gaol. For example, just bind /dev/null and /dev/zero. > this is in addition to your standard /dev tree and seems to work > quite fine. I can not see any reason why it would not. Effectively > ( but not quite ), /dev and /chroot/dev become carbon copies. I > mounted /tmp/dev in this fashion and could successfully eject my > cdrom useing both device trees. it would be interesting if two > process' tried to access the same device through a different tree at > the same time though. Could this be a problem that may need to be > addressed? No more so than if you access the same device via the same path from two processes. > You will have to play with devfsd.conf if you want different things to > happen within /chroot/dev and /dev. Is it possible to have devices > appear in /dev and not /chroot/dev? etc... Yes, by selectively binding stuff in /dev to /chroot/dev. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Tue May 15 09:48:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4FGmqQ15901 for devfs-outgoing; Tue, 15 May 2001 09:48:52 -0700 Received: from tungsten.btinternet.com (tungsten.btinternet.com [194.73.73.81]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FGmpF15898 for ; Tue, 15 May 2001 09:48:51 -0700 Received: from [213.122.2.135] (helo=localhost) by tungsten.btinternet.com with esmtp (Exim 3.03 #83) id 14zi08-0003Ls-00 for devfs@oss.sgi.com; Tue, 15 May 2001 17:48:49 +0100 Received: by localhost (Postfix, from userid 500) id 57070C37F; Tue, 15 May 2001 17:48:47 +0100 (BST) To: devfs@oss.sgi.com Subject: Running cdrecord with devfs From: Chris Martin Date: 15 May 2001 17:48:47 +0100 In-Reply-To: <5.1.0.14.2.20010514133640.009d1480@pop.myrealbox.com> (Ernesto CEDILLO-ARIAS's message of "Mon, 14 May 2001 13:40:18 -0600") Message-ID: Lines: 47 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-devfs@oss.sgi.com Precedence: bulk I am running ROCK Linux 1.3.11. I have compiled 2.4.4 with the SCSI generic stuff to run cdrecord. I have the following lines in /etc/devfsd.conf LOOKUP .* MODLOAD CREATE /dev/scsi/host0/bus0/target0/lun0/cd CFUNCTION GLOBAL symlink sg0 cd these lines (among others) in /etc/modules.conf (a scattergun approach, I'm afraid) alias scsi_hostadapter ide-scsi alias cdrom ide-scsi alias sga ide-scsi probeall scsi-hosts ide-scsi and the standard /etc/modules.devfs (3-JUL-2000) On booting, lsmod shows no modules loaded. On entering l /dev/scsi the info from loading the ide-scsi module is shown with Detected scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0 and /dev/scsi/host0/bus0/target0/lun0/cd /dev/scsi/host0/bus0/target0/lun0/generic are both created but no sg0. /dev/cdrom is a symbolic link to /dev/cdroms/cdrom0 and /dev/cdroms/cdrom0 is a symbolic link to ../scsi/host0/bus0/target0/lun0/cd Running cdrecord -scanbus fails as it can't find /dev/sg0 (or sg1...sg31, sga..sgz) However, manually putting in the symlink would be OK if I wasn't using a CR-ROM for testing... Can you tell me what I am missing about CREATE? From owner-devfs@oss.sgi.com Thu May 17 21:37:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4I4bpg05501 for devfs-outgoing; Thu, 17 May 2001 21:37:51 -0700 Received: from mail.labsysgrp.com (phnx1-blk2-hfc-0251-d1db10f1.rdc1.az.coxatwork.com [209.219.16.241]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4I4bmF05498 for ; Thu, 17 May 2001 21:37:48 -0700 Received: from jeeves.kpf.internal ([192.168.170.1]) by mail.labsysgrp.com with esmtp (Exim 3.22 #2) id 150c16-0001YE-00 for devfs@oss.sgi.com; Thu, 17 May 2001 21:37:33 -0700 Received: from [192.168.170.109] (helo=Kevin) by jeeves.kpf.internal with smtp (Exim 3.22 #3) id 150ZL9-0000OT-00 for devfs@oss.sgi.com; Thu, 17 May 2001 18:46:03 -0700 Message-ID: <000c01c0df3c$e7fccc70$6daaa8c0@Kevin> From: "Kevin P. Fleming" To: Subject: devfs kernel patch for block devices Date: Thu, 17 May 2001 18:50:24 -0700 Organization: LSG, Inc. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0009_01C0DF02.3B94CCB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-devfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C0DF02.3B94CCB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Attached is a small kernel patch (against 2.4.4) to fix some problems I found with devfs and some block device drivers. The problems were: - When the partition table on a device was re-read (either through an ioctl or other means), and previously existing partitions were no longer present, the /dev entries for those partitions did not disappear - For those devices supporting removable media, when the media was ejected, the /dev entries for the partitions (and the whole disc) on that media did not disappear - For those devices where a driver module could be unloaded without unloading the "major" module (only ide-disk and ide-floppy), the /dev entries managed by that "sub-driver" did not disappear if the module was unloaded These problems were nearly all caused by the way the new common partition manager works; I created a new function that the drivers can call to explicitly remove any information related to the previous partitions when appropriate. ------=_NextPart_000_0009_01C0DF02.3B94CCB0 Content-Type: application/octet-stream; name="devfs-patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="devfs-patch" diff -rbwU3 linux-2.4/drivers/acorn/block/mfmhd.c = linux-new/drivers/acorn/block/mfmhd.c=0A= --- linux-2.4/drivers/acorn/block/mfmhd.c Fri Oct 27 13:35:47 2000=0A= +++ linux-new/drivers/acorn/block/mfmhd.c Thu May 17 18:27:33 2001=0A= @@ -1499,6 +1499,7 @@=0A= =0A= /* Divide by 2, since sectors are 2 times smaller than usual ;-) */=0A= =0A= + ungrok_partitions(&mfm_gendisk, target);=0A= grok_partitions(&mfm_gendisk, target, 1<<6, mfm_info[target].heads *=0A= mfm_info[target].cylinders * mfm_info[target].sectors / 2);=0A= =0A= diff -rbwU3 linux-2.4/drivers/block/DAC960.c = linux-new/drivers/block/DAC960.c=0A= --- linux-2.4/drivers/block/DAC960.c Tue May 8 10:09:00 2001=0A= +++ linux-new/drivers/block/DAC960.c Thu May 17 18:08:45 2001=0A= @@ -5157,6 +5157,8 @@=0A= */=0A= set_blocksize(Device, BLOCK_SIZE);=0A= }=0A= + ungrok_partitions(&Controller->GenericDiskInfo,=0A= + LogicalDriveNumber);=0A= if (Controller->FirmwareType =3D=3D DAC960_V1_Controller)=0A= grok_partitions(&Controller->GenericDiskInfo,=0A= LogicalDriveNumber,=0A= diff -rbwU3 linux-2.4/drivers/block/acsi.c linux-new/drivers/block/acsi.c=0A= --- linux-2.4/drivers/block/acsi.c Tue May 8 10:09:00 2001=0A= +++ linux-new/drivers/block/acsi.c Thu May 17 18:33:07 2001=0A= @@ -1912,6 +1912,7 @@=0A= ENABLE_IRQ();=0A= stdma_release();=0A= =0A= + ungrok_partitions(gdev, device);=0A= grok_partitions(gdev, device, (aip->type=3D=3DHARDDISK)?1<<4:1, = aip->size);=0A= =0A= DEVICE_BUSY =3D 0;=0A= diff -rbwU3 linux-2.4/drivers/block/cciss.c = linux-new/drivers/block/cciss.c=0A= --- linux-2.4/drivers/block/cciss.c Tue May 8 10:09:32 2001=0A= +++ linux-new/drivers/block/cciss.c Thu May 17 18:28:38 2001=0A= @@ -705,6 +705,7 @@=0A= blksize_size[MAJOR_NR+ctlr][minor] =3D 1024;=0A= }=0A= /* setup partitions per disk */=0A= + ungrok_partitions(gdev, target);=0A= grok_partitions(gdev, target, MAX_PART, =0A= hba[ctlr]->drv[target].nr_blocks);=0A= hba[ctlr]->drv[target].usage_count--;=0A= diff -rbwU3 linux-2.4/drivers/block/cpqarray.c = linux-new/drivers/block/cpqarray.c=0A= --- linux-2.4/drivers/block/cpqarray.c Tue May 8 10:09:00 2001=0A= +++ linux-new/drivers/block/cpqarray.c Thu May 17 18:33:48 2001=0A= @@ -1588,6 +1588,7 @@=0A= blksize_size[MAJOR_NR+ctlr][minor] =3D 1024;=0A= }=0A= =0A= + ungrok_partitions(gdev, target);=0A= /* 16 minors per disk... */=0A= grok_partitions(gdev, target, 16, hba[ctlr]->drv[target].nr_blks);=0A= hba[ctlr]->drv[target].usage_count--;=0A= diff -rbwU3 linux-2.4/drivers/block/paride/pd.c = linux-new/drivers/block/paride/pd.c=0A= --- linux-2.4/drivers/block/paride/pd.c Tue May 8 10:09:00 2001=0A= +++ linux-new/drivers/block/paride/pd.c Thu May 17 18:26:11 2001=0A= @@ -510,7 +510,10 @@=0A= =0A= switch (cmd) {=0A= case CDROMEJECT:=0A= - if (PD.access =3D=3D 1) pd_eject(unit);=0A= + if (PD.access =3D=3D 1) {=0A= + ungrok_partitions(&pd_gendisk,unit);=0A= + pd_eject(unit);=0A= + }=0A= return 0;=0A= case HDIO_GETGEO:=0A= if (!geo) return -EINVAL;=0A= @@ -618,8 +621,10 @@=0A= pd_hd[minor].nr_sects =3D 0;=0A= }=0A= =0A= - if (pd_identify(unit))=0A= + if (pd_identify(unit)) {=0A= + ungrok_partitions(&pd_gendisk,unit);=0A= grok_partitions(&pd_gendisk,unit,1<req_queue =3D &i2ob_queues[c->unit]->req_queue;=0A= =0A= + ungrok_partitions(&i2ob_gendisk, unit>>4);=0A= grok_partitions(&i2ob_gendisk, unit>>4, 1<<4, (long)(size>>9));=0A= =0A= /*=0A= diff -rbwU3 linux-2.4/drivers/ide/hd.c linux-new/drivers/ide/hd.c=0A= --- linux-2.4/drivers/ide/hd.c Tue May 8 10:09:02 2001=0A= +++ linux-new/drivers/ide/hd.c Thu May 17 17:29:37 2001=0A= @@ -907,6 +907,7 @@=0A= MAYBE_REINIT;=0A= #endif=0A= =0A= + ungrok_partitions(gdev, target);=0A= grok_partitions(gdev, target, 1<<6, CAPACITY);=0A= =0A= DEVICE_BUSY =3D 0;=0A= diff -rbwU3 linux-2.4/drivers/ide/ide-disk.c = linux-new/drivers/ide/ide-disk.c=0A= --- linux-2.4/drivers/ide/ide-disk.c Tue May 8 10:09:02 2001=0A= +++ linux-new/drivers/ide/ide-disk.c Thu May 17 17:17:24 2001=0A= @@ -494,6 +494,7 @@=0A= =0A= static void idedisk_revalidate (ide_drive_t *drive)=0A= {=0A= + ungrok_partitions(HWIF(drive)->gd, drive->select.b.unit);=0A= grok_partitions(HWIF(drive)->gd, drive->select.b.unit,=0A= 1<gd, drive->select.b.unit);=0A= return ide_unregister_subdriver(drive);=0A= }=0A= =0A= diff -rbwU3 linux-2.4/drivers/ide/ide-floppy.c = linux-new/drivers/ide/ide-floppy.c=0A= --- linux-2.4/drivers/ide/ide-floppy.c Tue May 8 10:09:02 2001=0A= +++ linux-new/drivers/ide/ide-floppy.c Thu May 17 17:15:54 2001=0A= @@ -1293,7 +1293,7 @@=0A= /*=0A= * Our special ide-floppy ioctl's.=0A= *=0A= - * Currently there aren't any ioctl's.=0A= + * Currently the only ioctl supported is to eject the cartridge, using = the CDROMEJECT ioctl.=0A= */=0A= static int idefloppy_ioctl (ide_drive_t *drive, struct inode *inode, = struct file *file,=0A= unsigned int cmd, unsigned long arg)=0A= @@ -1307,6 +1307,7 @@=0A= (void) idefloppy_queue_pc_tail (drive, &pc);=0A= idefloppy_create_start_stop_cmd (&pc, 2);=0A= (void) idefloppy_queue_pc_tail (drive, &pc);=0A= + ungrok_partitions(HWIF(drive)->gd, = drive->select.b.unit);=0A= return 0;=0A= }=0A= return -EIO;=0A= @@ -1380,6 +1381,7 @@=0A= */=0A= static void idefloppy_revalidate (ide_drive_t *drive)=0A= {=0A= + ungrok_partitions(HWIF(drive)->gd, drive->select.b.unit);=0A= grok_partitions(HWIF(drive)->gd, drive->select.b.unit,=0A= 1<driver_data;=0A= =0A= + ungrok_partitions(HWIF(drive)->gd, drive->select.b.unit);=0A= if (ide_unregister_subdriver (drive))=0A= return 1;=0A= drive->driver_data =3D NULL;=0A= diff -rbwU3 linux-2.4/drivers/mtd/nftl.c linux-new/drivers/mtd/nftl.c=0A= --- linux-2.4/drivers/mtd/nftl.c Tue May 8 10:09:02 2001=0A= +++ linux-new/drivers/mtd/nftl.c Thu May 17 18:35:33 2001=0A= @@ -209,6 +209,7 @@=0A= #if LINUX_VERSION_CODE < 0x20328=0A= resetup_one_dev(&nftl_gendisk, firstfree);=0A= #else=0A= + ungrok_partitions(&nftl_gendisk, firstfree);=0A= grok_partitions(&nftl_gendisk, firstfree, 1<<4, nftl->nr_sects);=0A= #endif=0A= }=0A= @@ -840,6 +841,7 @@=0A= #if LINUX_VERSION_CODE < 0x20328=0A= resetup_one_dev(&nftl_gendisk, MINOR(inode->i_rdev) / 16);=0A= #else=0A= + ungrok_partitions(&nftl_gendisk, MINOR(inode->i_rdev) / 16);=0A= grok_partitions(&nftl_gendisk, MINOR(inode->i_rdev) / 16,=0A= 1<<4, nftl->nr_sects);=0A= #endif=0A= diff -rbwU3 linux-2.4/drivers/scsi/sd.c linux-new/drivers/scsi/sd.c=0A= --- linux-2.4/drivers/scsi/sd.c Tue May 8 10:09:07 2001=0A= +++ linux-new/drivers/scsi/sd.c Thu May 17 18:36:02 2001=0A= @@ -1286,6 +1286,7 @@=0A= MAYBE_REINIT;=0A= #endif=0A= =0A= + ungrok_partitions(&SD_GENDISK(target), target % SCSI_DISKS_PER_MAJOR);=0A= grok_partitions(&SD_GENDISK(target), target % SCSI_DISKS_PER_MAJOR,=0A= 1<<4, CAPACITY);=0A= =0A= diff -rbwU3 linux-2.4/fs/partitions/check.c = linux-new/fs/partitions/check.c=0A= --- linux-2.4/fs/partitions/check.c Tue May 8 10:09:11 2001=0A= +++ linux-new/fs/partitions/check.c Thu May 17 17:11:20 2001=0A= @@ -307,7 +307,7 @@=0A= printk(" unknown partition table\n");=0A= setup_devfs:=0A= i =3D first_part_minor - 1;=0A= - devfs_register_partitions (hd, i, hd->sizes ? 0 : 1);=0A= + devfs_register_partitions (hd, i, 0);=0A= }=0A= =0A= #ifdef CONFIG_DEVFS_FS=0A= @@ -437,6 +437,13 @@=0A= dev->sizes[i] =3D dev->part[i].nr_sects >> (BLOCK_SIZE_BITS - 9);=0A= blk_size[dev->major] =3D dev->sizes;=0A= }=0A= +}=0A= +=0A= +void ungrok_partitions(struct gendisk *dev, int drive)=0A= +{=0A= + int first_minor =3D drive << dev->minor_shift;=0A= +=0A= + devfs_register_partitions(dev, first_minor, 1);=0A= }=0A= =0A= int __init partition_setup(void)=0A= diff -rbwU3 linux-2.4/include/linux/blkdev.h = linux-new/include/linux/blkdev.h=0A= --- linux-2.4/include/linux/blkdev.h Tue May 8 10:28:10 2001=0A= +++ linux-new/include/linux/blkdev.h Thu May 17 17:11:20 2001=0A= @@ -149,6 +149,7 @@=0A= extern struct sec_size * blk_sec[MAX_BLKDEV];=0A= extern struct blk_dev_struct blk_dev[MAX_BLKDEV];=0A= extern void grok_partitions(struct gendisk *dev, int drive, unsigned = minors, long size);=0A= +extern void ungrok_partitions(struct gendisk *dev, int drive);=0A= extern void register_disk(struct gendisk *dev, kdev_t first, unsigned = minors, struct block_device_operations *ops, long size);=0A= extern void generic_make_request(int rw, struct buffer_head * bh);=0A= extern request_queue_t *blk_get_queue(kdev_t dev);=0A= diff -rbwU3 linux-2.4/kernel/ksyms.c linux-new/kernel/ksyms.c=0A= --- linux-2.4/kernel/ksyms.c Tue May 8 10:09:42 2001=0A= +++ linux-new/kernel/ksyms.c Thu May 17 17:11:20 2001=0A= @@ -291,6 +291,7 @@=0A= EXPORT_SYMBOL(ioctl_by_bdev);=0A= EXPORT_SYMBOL(gendisk_head);=0A= EXPORT_SYMBOL(grok_partitions);=0A= +EXPORT_SYMBOL(ungrok_partitions);=0A= EXPORT_SYMBOL(register_disk);=0A= EXPORT_SYMBOL(tq_disk);=0A= EXPORT_SYMBOL(init_buffer);=0A= ------=_NextPart_000_0009_01C0DF02.3B94CCB0-- From owner-devfs@oss.sgi.com Thu May 17 21:44:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4I4iF805642 for devfs-outgoing; Thu, 17 May 2001 21:44:15 -0700 Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4I4iEF05639 for ; Thu, 17 May 2001 21:44:14 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id f4I4i1T29364; Thu, 17 May 2001 22:44:01 -0600 Date: Thu, 17 May 2001 22:44:01 -0600 Message-Id: <200105180444.f4I4i1T29364@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: "Kevin P. Fleming" Cc: Subject: Re: devfs kernel patch for block devices In-Reply-To: <000c01c0df3c$e7fccc70$6daaa8c0@Kevin> References: <000c01c0df3c$e7fccc70$6daaa8c0@Kevin> Sender: owner-devfs@oss.sgi.com Precedence: bulk Kevin P. Fleming writes: > This is a multi-part message in MIME format. > > ------=_NextPart_000_0009_01C0DF02.3B94CCB0 > Content-Type: text/plain; > charset="iso-8859-1" > Content-Transfer-Encoding: 7bit Please re-send this in plain text, not MIME. MIME does horrible things like convert legitimate ASCII characters into so-called "quoted printables". Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Sat May 19 08:42:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4JFgJb28811 for devfs-outgoing; Sat, 19 May 2001 08:42:19 -0700 Received: from dragon.flyn.org (pD9504C83.dip.t-dialin.net [217.80.76.131]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4JFgHF28808 for ; Sat, 19 May 2001 08:42:18 -0700 Received: by dragon.flyn.org (Postfix, from userid 500) id C46443A7D4; Tue, 15 May 2001 17:44:10 +0200 (CEST) Date: Tue, 15 May 2001 17:44:10 +0200 From: "W. Michael Petullo" To: devfs@oss.sgi.com Subject: devfsd and USB Message-ID: <20010515174410.A6103@dragon.flyn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: Linux dragon.flyn.org 2.4.5-pre2 Sender: owner-devfs@oss.sgi.com Precedence: bulk Greetings, Is there any plans to unify devfs and the usbdevfs? Devfs and devfsd seem to be positioned well to handle dynamic buses like USB. However, generic Linux 2.4 user-land USB access is currently performed using usbdevfs, (like devfs), usb_permd (like devfsd), and libusb. I've seen a lot of discussion about hot-swap devices and Linux lately, though none from the devfs camp. What plans exist for supporting things like USB with devfs? -- W. Michael Petullo :wq From owner-devfs@oss.sgi.com Sun May 20 21:10:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4L4AAv29094 for devfs-outgoing; Sun, 20 May 2001 21:10:10 -0700 Received: from mobilix.ras.ucalgary.ca (lssf069.lss.emc.com [168.159.63.69]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4L4A7F29091 for ; Sun, 20 May 2001 21:10:07 -0700 Received: (from rgooch@localhost) by mobilix.ras.ucalgary.ca (8.10.0/8.10.0) id f4KJS7b08210; Sun, 20 May 2001 15:28:07 -0400 Date: Sun, 20 May 2001 15:28:07 -0400 Message-Id: <200105201928.f4KJS7b08210@mobilix.ras.ucalgary.ca> From: Richard Gooch To: Will Newton Cc: Subject: Re: devfs warning messages In-Reply-To: References: Sender: owner-devfs@oss.sgi.com Precedence: bulk Will Newton writes: > > Can anyone help me understand what's going on here: > > devfs: devfs_register(): device already registered: "2" > devfs: devfs_register(): device already registered: "a2" > devfs: devfs_register(): device already registered: "3" > devfs: devfs_register(): device already registered: "a3" > > I get these messages on every boot. This is probably related to the virtual console capture driver: drivers/char/vc_screen.c Exactly when do these messages occur? Can someone please have a look at the VCC driver and see what might be wrong? Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Mon May 21 11:10:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4LIAuE17327 for devfs-outgoing; Mon, 21 May 2001 11:10:56 -0700 Received: from phenoxide.engr.valinux.com (nat-hdqt.valinux.com [198.186.202.17]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4LIAtF17324 for ; Mon, 21 May 2001 11:10:55 -0700 Received: (from jerdfelt@localhost) by phenoxide.engr.valinux.com (8.9.3/8.9.3) id LAA16703; Mon, 21 May 2001 11:10:44 -0700 Date: Mon, 21 May 2001 11:10:44 -0700 From: Johannes Erdfelt To: "W. Michael Petullo" Cc: devfs@oss.sgi.com Subject: Re: devfsd and USB Message-ID: <20010521111044.H906@valinux.com> References: <20010515174410.A6103@dragon.flyn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20010515174410.A6103@dragon.flyn.org>; from mike@flyn.org on Tue, May 15, 2001 at 05:44:10PM +0200 Sender: owner-devfs@oss.sgi.com Precedence: bulk On Tue, May 15, 2001, W. Michael Petullo wrote: > Is there any plans to unify devfs and the usbdevfs? Devfs and devfsd > seem to be positioned well to handle dynamic buses like USB. However, > generic Linux 2.4 user-land USB access is currently performed using > usbdevfs, (like devfs), usb_permd (like devfsd), and libusb. > > I've seen a lot of discussion about hot-swap devices and Linux lately, > though none from the devfs camp. What plans exist for supporting things > like USB with devfs? I wrote a patch to do just this, but it was rejected since we cannot depend on people using devfs. As a result, we had to reimplement much of it's functionality ourselves. JE From owner-devfs@oss.sgi.com Mon May 21 11:21:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4LIL1117525 for devfs-outgoing; Mon, 21 May 2001 11:21:01 -0700 Received: from mailgate.rz.uni-karlsruhe.de (mailgate.rz.uni-karlsruhe.de [129.13.64.97]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4LIL0F17522 for ; Mon, 21 May 2001 11:21:00 -0700 Received: from nce2.hadiko.de (hadince2.hadiko.uni-karlsruhe.de [172.20.32.2]) by mailgate.rz.uni-karlsruhe.de with esmtp (Exim 3.16 #1) id 151uIX-0003dm-00; Mon, 21 May 2001 20:20:53 +0200 Received: from panorama.hadiko.de (hadii309.hadiko.uni-karlsruhe.de [172.20.44.69]) by nce2.hadiko.de (8.9.3/8.9.3) with SMTP id UAA17051 for ; Mon, 21 May 2001 20:20:59 +0200 (MET DST) Received: (qmail 7978 invoked from network); 21 May 2001 18:20:51 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 21 May 2001 18:20:51 -0000 To: devfs@oss.sgi.com Subject: Re: devfsd and USB From: Robert Siemer In-Reply-To: <20010521111044.H906@valinux.com> References: <20010515174410.A6103@dragon.flyn.org> <20010521111044.H906@valinux.com> X-Mailer: Mew version 1.94b25 on Emacs 20.5 / Mule 4.0 (HANANOEN) Reply-To: Robert Siemer Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010521202050M.siemer@panorama.hadiko.de> Date: Mon, 21 May 2001 20:20:50 +0200 X-Dispatcher: imput version 990425(IM115) Lines: 23 Sender: owner-devfs@oss.sgi.com Precedence: bulk From: Johannes Erdfelt > On Tue, May 15, 2001, W. Michael Petullo wrote: > > Is there any plans to unify devfs and the usbdevfs? Devfs and devfsd > > seem to be positioned well to handle dynamic buses like USB. However, > > generic Linux 2.4 user-land USB access is currently performed using > > usbdevfs, (like devfs), usb_permd (like devfsd), and libusb. > > > > I've seen a lot of discussion about hot-swap devices and Linux lately, > > though none from the devfs camp. What plans exist for supporting things > > like USB with devfs? > > I wrote a patch to do just this, but it was rejected since we cannot depend > on people using devfs. Why not? > As a result, we had to reimplement much of it's functionality ourselves. Bye, Robert From owner-devfs@oss.sgi.com Mon May 21 11:34:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4LIY3417821 for devfs-outgoing; Mon, 21 May 2001 11:34:03 -0700 Received: from phenoxide.engr.valinux.com (nat-hdqt.valinux.com [198.186.202.17]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4LIY2F17818 for ; Mon, 21 May 2001 11:34:02 -0700 Received: (from jerdfelt@localhost) by phenoxide.engr.valinux.com (8.9.3/8.9.3) id LAA16741; Mon, 21 May 2001 11:33:28 -0700 Date: Mon, 21 May 2001 11:33:28 -0700 From: Johannes Erdfelt To: Robert Siemer Cc: devfs@oss.sgi.com Subject: Re: devfsd and USB Message-ID: <20010521113328.J906@valinux.com> References: <20010515174410.A6103@dragon.flyn.org> <20010521111044.H906@valinux.com> <20010521202050M.siemer@panorama.hadiko.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20010521202050M.siemer@panorama.hadiko.de>; from Robert.Siemer@gmx.de on Mon, May 21, 2001 at 08:20:50PM +0200 Sender: owner-devfs@oss.sgi.com Precedence: bulk On Mon, May 21, 2001, Robert Siemer wrote: > From: Johannes Erdfelt > > On Tue, May 15, 2001, W. Michael Petullo wrote: > > > > Is there any plans to unify devfs and the usbdevfs? Devfs and devfsd > > > seem to be positioned well to handle dynamic buses like USB. However, > > > generic Linux 2.4 user-land USB access is currently performed using > > > usbdevfs, (like devfs), usb_permd (like devfsd), and libusb. > > > > > > I've seen a lot of discussion about hot-swap devices and Linux lately, > > > though none from the devfs camp. What plans exist for supporting things > > > like USB with devfs? > > > > I wrote a patch to do just this, but it was rejected since we cannot depend > > on people using devfs. > > Why not? Talk to Linus. JE From owner-devfs@oss.sgi.com Mon May 21 12:33:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4LJXcl18673 for devfs-outgoing; Mon, 21 May 2001 12:33:38 -0700 Received: from tgos.org (europa.your-site.com [140.186.45.2]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4LJXaF18670 for ; Mon, 21 May 2001 12:33:36 -0700 Received: from port3 ([213.23.60.145]) by tgos.org ; Mon, 21 May 2001 15:33:28 -0400 Date: Mon, 21 May 2001 21:33:42 +0200 From: TGOS X-Mailer: The Bat! (v1.45) Personal Organization: TGOS.org X-Priority: 3 (Normal) Message-ID: <404017089.20010521213342@tgos.org> To: Johannes Erdfelt CC: devfs@oss.sgi.com Subject: Re[2]: devfsd and USB In-reply-To: <20010521113328.J906@valinux.com> References: <20010515174410.A6103@dragon.flyn.org> <20010521111044.H906@valinux.com> <20010521202050M.siemer@panorama.hadiko.de> <20010521113328.J906@valinux.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-devfs@oss.sgi.com Precedence: bulk Hello Johannes, Monday, May 21, 2001, 8:33:28 PM, you wrote: JE> On Mon, May 21, 2001, Robert Siemer wrote: >> From: Johannes Erdfelt >>> On Tue, May 15, 2001, W. Michael Petullo wrote: >> >>>> Is there any plans to unify devfs and the usbdevfs? Devfs and devfsd >>>> seem to be positioned well to handle dynamic buses like USB. However, >>>> generic Linux 2.4 user-land USB access is currently performed using >>>> usbdevfs, (like devfs), usb_permd (like devfsd), and libusb. >>>> >>>> I've seen a lot of discussion about hot-swap devices and Linux lately, >>>> though none from the devfs camp. What plans exist for supporting things >>>> like USB with devfs? >>> >>> I wrote a patch to do just this, but it was rejected since we cannot depend >>> on people using devfs. >> >> Why not? JE> Talk to Linus. Are there any plans to make DevFS a permanent part Linux? Don't get me wrong, it is already a permanent part of the Kernel sources, but it's still optional. My question is, are there any plans to make it mandatory? Right now USBDevFS *is* mandatory if you want to use USB devices, so why shouldn't there be any plans to make DevFS mandatory as well. Once DevFS is mandatory, it should be no problem to unite it with the other FS mentioned above. Further most application developer would start to develop applications in such a way, that they don't depend on DevFSD anymore. I personally see only advantages when the classical /dev system is finally replaced. -- Best regards, TGOS From owner-devfs@oss.sgi.com Mon May 21 19:49:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4M2nw527384 for devfs-outgoing; Mon, 21 May 2001 19:49:58 -0700 Received: from mobilix.ras.ucalgary.ca (lpce015.lss.emc.com [168.159.62.15]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4M2npF27381 for ; Mon, 21 May 2001 19:49:51 -0700 Received: (from rgooch@localhost) by mobilix.ras.ucalgary.ca (8.10.0/8.10.0) id f4M1ChZ00404; Mon, 21 May 2001 21:12:43 -0400 Date: Mon, 21 May 2001 21:12:43 -0400 Message-Id: <200105220112.f4M1ChZ00404@mobilix.ras.ucalgary.ca> From: Richard Gooch To: mclinden@informed.net Cc: devfs@oss.sgi.com Subject: Re: Linux From Scratch In-Reply-To: References: Sender: owner-devfs@oss.sgi.com Precedence: bulk mclinden@informed.net writes: > > Has anyone successfully configured a system to use devfs under LFS. I'm > running: > > Linux 2.4.1, > Glibc 2.1.3, > GCC 2.95.2, > Modutils 2.4.2, > Shadow 20000902, > and Net-Kit 0.17. > > depmod, modinfo and insmod give me segmentation fault when I am running > with devfs (and devfsd). > > telnetd gives getpeername: Socket operation on non-socket. Doesn't sound like a devfs related problem. > I've read the FAQ, configured the system accordingly, and can boot into > single user mode but I cannot bring up most daemons and it seems that a > great many of the /dev entries that this kernel and software require are > not created by devfsd. Sorry for not getting back to you sooner. Make sure you've configured devfsd to create compatibility entries. If there are still missing entries, then provide me a list of the name the kernel *does* give (if there is one) and what the missing name is. The problem may be an omission in devfsd, or it might be a driver that doesn't create entries in devfs. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Mon May 21 20:07:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4M37Xe27643 for devfs-outgoing; Mon, 21 May 2001 20:07:33 -0700 Received: from smtp.eecs.umich.edu (smtp.eecs.umich.edu [141.213.4.44]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4M37WF27640 for ; Mon, 21 May 2001 20:07:32 -0700 Received: from eecs.umich.edu (mcns31.docsis86.singa.pore.net [202.156.86.31]) (authenticated) by smtp.eecs.umich.edu (8.11.2/8.11.2) with ESMTP id f4M37G929658; Mon, 21 May 2001 23:07:16 -0400 Message-ID: <3B09D90E.4030009@eecs.umich.edu> Date: Tue, 22 May 2001 11:12:14 +0800 From: Chris Hamilton User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.3 i686; en-US; rv:0.9) Gecko/20010505 X-Accept-Language: en MIME-Version: 1.0 To: Richard Gooch CC: mclinden@informed.net, devfs@oss.sgi.com Subject: Re: Linux From Scratch References: <200105220112.f4M1ChZ00404@mobilix.ras.ucalgary.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-devfs@oss.sgi.com Precedence: bulk Rock Linux is based on LFS and uses devfs. You may want to look through our patches that we applied for these packages. See www.rocklinux.org/sources/ and browse through pkg-config for specific patches. -Chris Hamilton Richard Gooch wrote: >mclinden@informed.net writes: > >>Has anyone successfully configured a system to use devfs under LFS. I'm >>running: >> >>Linux 2.4.1, >>Glibc 2.1.3, >>GCC 2.95.2, >>Modutils 2.4.2, >>Shadow 20000902, >>and Net-Kit 0.17. >> >>depmod, modinfo and insmod give me segmentation fault when I am running >>with devfs (and devfsd). >> >>telnetd gives getpeername: Socket operation on non-socket. >> > >Doesn't sound like a devfs related problem. > >>I've read the FAQ, configured the system accordingly, and can boot into >>single user mode but I cannot bring up most daemons and it seems that a >>great many of the /dev entries that this kernel and software require are >>not created by devfsd. >> > >Sorry for not getting back to you sooner. Make sure you've configured >devfsd to create compatibility entries. If there are still missing >entries, then provide me a list of the name the kernel *does* give (if >there is one) and what the missing name is. > >The problem may be an omission in devfsd, or it might be a driver that >doesn't create entries in devfs. > > Regards, > > Richard.... >Permanent: rgooch@atnf.csiro.au >Current: rgooch@ras.ucalgary.ca > From owner-devfs@oss.sgi.com Wed May 23 18:39:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4O1dn630198 for devfs-outgoing; Wed, 23 May 2001 18:39:49 -0700 Received: from bigbox.glsonline.com (adsl-63-202-104-136.dsl.lsan03.pacbell.net [63.202.104.136]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4O1dlF30195 for ; Wed, 23 May 2001 18:39:48 -0700 Received: (from gellis@localhost) by bigbox.glsonline.com (8.9.3/linuxconf) id SAA05366; Wed, 23 May 2001 18:39:31 -0700 X-Authentication-Warning: bigbox.glsonline.com: gellis set sender to gellis@glsonline.com using -f Subject: RPM packages for devfsd 1.3.11 From: Gregory Ellis To: devfs@oss.sgi.com Cc: gellis@glsonline.com, rgooch@atnf.csiro.au Content-Type: multipart/alternative; boundary="=-oSMp8m8Ma5kaz236ALRd" X-Mailer: Evolution/0.10 (Preview Release) Date: 23 May 2001 18:39:31 -0700 Message-Id: <990668371.4489.0.camel@bigbox.glsonline.com> Mime-Version: 1.0 Sender: owner-devfs@oss.sgi.com Precedence: bulk --=-oSMp8m8Ma5kaz236ALRd Content-Type: text/plain Hello, I wasn't sure if anyone had already done this so I went ahead to save myself (and possibly others) some time while dust from the 2.4 kernel settles... I've created rpm packages for the devfsd daemon. These were created on a RedHat 6.2, AMD K6-2 3D 450 system w/ all updates(RedHat/Ximian/Eazel, though I don't think those will really matter.) on the 2.4.3 kernel. I'm running RPM version 4.0.2. Please note that the spec file was thrown together very quickly and is by no means robust. In fact, you'll see FIXME tags in a couple of places which should be updated by anyone that has the correct information. When compiling on your system beware: The package's original GNUmakefile has *not* been modified so the compliation process will *over-write* your existing devfsd-related files. Please save these files if you've made any changes: /etc/devfsd.conf /etc/modules.devfs /sbin/devfsd /usr/man/man8/devfsd.8 rpm will do nothing with any build options like $RPM_BUILD_ROOT. If anyone feels so inclined as to update the makefile to handle this type of stuff, please feel free. For a straight binary installation, it *should not* over-write the existing /etc config files. *Don't forget to follow the instructions* in http://www.atnf.csiro.au/~rgooch/linux/docs/devfs.html, which I've also included in the binary package. It installs to: /usr/doc/devfsd-1.3.11/devfs.html The packages can be had at: http://www.glsonline.com/linux/redhat-6.2/SRPMS/devfsd-1.3.11-1.src.rpm http://www.glsonline.com/linux/redhat-6.2/RPMS/i386/devfsd-1.3.11-1.i386.rpm Also, I'm currently *NOT* a member of any devfs mailing list so please send any responses to the address below. I agree with devfs's attempts to resolve some of the long time device-naming issues in Linux and here's a small contribution towards that goal. Good luck, Greg -- Gregory Ellis gellis@glsonline.com GLS Consultants, Inc. http://www.glsonline.com Phone/Vmail/Pager: (323) 344-9458 --=-oSMp8m8Ma5kaz236ALRd Content-Type: text/html; charset=utf-8 Gregory Ellis' Signature File Hello,
I wasn't sure if anyone had already done this so I went ahead to save myself (and possibly
others) some time while dust from the 2.4 kernel settles...

I've created rpm packages for the devfsd daemon.  These were created on a RedHat 6.2,
AMD K6-2 3D 450 system w/ all updates(RedHat/Ximian/Eazel, though I don't think those
will really matter.) on the 2.4.3 kernel.  I'm running RPM version 4.0.2.

Please note that the spec file was thrown together very quickly and is by no means robust.
In fact, you'll see FIXME tags in a couple of places which should be updated by anyone
that has the correct information.

When compiling on your system beware:  The package's original GNUmakefile has *not*
been modified so the compliation process will *over-write* your existing devfsd-related files.
Please save these files if you've made any changes:

/etc/devfsd.conf
/etc/modules.devfs
/sbin/devfsd
/usr/man/man8/devfsd.8
rpm will do nothing with any build options like $RPM_BUILD_ROOT.   If anyone feels so inclined
as to update the makefile to handle this type of stuff, please feel free.


For a straight binary installation, it *should not* over-write the existing /etc config files.

*Don't forget to follow the instructions* in http://www.atnf.csiro.au/~rgooch/linux/docs/devfs.html,
which I've also included in the binary package.  It installs to:  /usr/doc/devfsd-1.3.11/devfs.html

The packages can be had at:

http://www.glsonline.com/linux/redhat-6.2/SRPMS/devfsd-1.3.11-1.src.rpm
http://www.glsonline.com/linux/redhat-6.2/RPMS/i386/devfsd-1.3.11-1.i386.rpm


Also, I'm currently *NOT* a member of any devfs mailing list so please send any responses
to the address below.

I agree with devfs's attempts to resolve some of the long time device-naming issues in Linux
and here's a small contribution towards that goal.


Good luck,

Greg
--

Gregory Ellis                                        gellis@glsonline.com
GLS Consultants, Inc.                            http://www.glsonline.com
Phone/Vmail/Pager:                                         (323) 344-9458 --=-oSMp8m8Ma5kaz236ALRd-- From owner-devfs@oss.sgi.com Wed May 23 20:30:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4O3UEc02729 for devfs-outgoing; Wed, 23 May 2001 20:30:14 -0700 Received: from dorothy.denveronline.net (dorothy.denveronline.net [206.168.141.2]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4O3UCF02726 for ; Wed, 23 May 2001 20:30:13 -0700 Received: from ecollege.com (good-ideas.org [66.37.133.15]) by dorothy.denveronline.net (8.9.3/8.9.3) with ESMTP id VAA01300 for ; Wed, 23 May 2001 21:30:10 -0600 (MDT) Message-ID: <3B0C7DEE.F6CCE4A1@ecollege.com> Date: Wed, 23 May 2001 21:20:14 -0600 From: Lewis Brown X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i586) X-Accept-Language: en MIME-Version: 1.0 To: devfs Subject: help: /dev/.devfs file Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-devfs@oss.sgi.com Precedence: bulk I've just installed RH7.1, which comes with devfs in the kernel (2.4.2-2). Yet I cannot run the daemon, nor mount the fs due to the lack of the /dev/.devfs file, which is nowhere to be found. Having read the docs several times, I still haven't discovered how to properly create this file (special character device file - but no major/minor numbers). Any help would be much appreciated. lb From owner-devfs@oss.sgi.com Wed May 23 21:19:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4O4J0e04109 for devfs-outgoing; Wed, 23 May 2001 21:19:00 -0700 Received: from mobilix.ras.ucalgary.ca (lpce023.lss.emc.com [168.159.62.23]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4O4IuF04104 for ; Wed, 23 May 2001 21:18:57 -0700 Received: (from rgooch@localhost) by mobilix.ras.ucalgary.ca (8.10.0/8.10.0) id f4O4Iv201470; Thu, 24 May 2001 00:18:57 -0400 Date: Thu, 24 May 2001 00:18:57 -0400 Message-Id: <200105240418.f4O4Iv201470@mobilix.ras.ucalgary.ca> From: Richard Gooch To: Lewis Brown Cc: devfs Subject: Re: help: /dev/.devfs file In-Reply-To: <3B0C7DEE.F6CCE4A1@ecollege.com> References: <3B0C7DEE.F6CCE4A1@ecollege.com> Sender: owner-devfs@oss.sgi.com Precedence: bulk Lewis Brown writes: > I've just installed RH7.1, which comes with devfs in the kernel > (2.4.2-2). Yet I cannot run the daemon, nor mount the fs due to the > lack of the /dev/.devfs file, which is nowhere to be found. Having read > the docs several times, I still haven't discovered how to properly > create this file (special character device file - but no major/minor > numbers). Pass "devfs=mount" on the kernel command line. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Thu May 24 22:13:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4P5Dlh17796 for devfs-outgoing; Thu, 24 May 2001 22:13:47 -0700 Received: from mobilix.ras.ucalgary.ca (lpce020.lss.emc.com [168.159.62.20]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4P5DjF17793 for ; Thu, 24 May 2001 22:13:45 -0700 Received: (from rgooch@localhost) by mobilix.atnf.CSIRO.AU (8.10.0/8.10.0) id f4OMXDw00336; Thu, 24 May 2001 18:33:13 -0400 Date: Thu, 24 May 2001 18:33:13 -0400 Message-Id: <200105242233.f4OMXDw00336@mobilix.atnf.CSIRO.AU> From: Richard Gooch To: Gregory Ellis Cc: devfs@oss.sgi.com Subject: Re: RPM packages for devfsd 1.3.11 In-Reply-To: <990668371.4489.0.camel@bigbox.glsonline.com> References: <990668371.4489.0.camel@bigbox.glsonline.com> Sender: owner-devfs@oss.sgi.com Precedence: bulk Gregory Ellis writes: > I wasn't sure if anyone had already done this so I went ahead to > save myself (and possibly > others) some time while dust from the 2.4 kernel settles... Someone else has done this, I just haven't had time to look over it and apply it. So, thanks for the effort, but sorry, someone else got in first :-) Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Mon May 28 21:51:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4T4pin13830 for devfs-outgoing; Mon, 28 May 2001 21:51:44 -0700 Received: from energy.pdb.sbs.de (energy.pdb.sbs.de [192.109.2.19]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4T4pgd13827 for ; Mon, 28 May 2001 21:51:43 -0700 Received: from trulli.pdb.fsc.net ([172.25.96.20]) by energy.pdb.sbs.de (8.9.3/8.9.3) with ESMTP id PAA08419; Mon, 28 May 2001 15:46:34 +0200 Received: from biker.pdb.fsc.net (biker.pdb.fsc.net [172.25.187.106]) by trulli.pdb.fsc.net (8.9.3/8.9.3) with ESMTP id PAA28049; Mon, 28 May 2001 15:46:33 +0200 Received: from localhost (martin@localhost) by biker.pdb.fsc.net (8.11.0/8.11.0) with ESMTP id f4SDjce20497; Mon, 28 May 2001 15:45:38 +0200 Date: Mon, 28 May 2001 15:45:38 +0200 (CEST) From: Martin Wilck To: devfs mailing list cc: "Leonard N. Zubkoff" Subject: devfs & DAC960 ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-devfs@oss.sgi.com Precedence: bulk Hello, I have observed that when using devfs in connection with the DAC960 driver for Mylex RAID, several things are going wrong: - The Mylex partitions appear as /dev/rd/discX/partY, where they should appear as /dev/rd/controllerX/discY/partZ. (or whatever mnemonic one would use for "controller"). - devfsd generates no compatibility entries of the "old" DAC960 style /dev/rd/cXdYpZ. - Instead, /dev/rd is reserved for RAM disks in devfs. I had a short e-mail exchange with Leonard Zubkoff, the DAC960 maintainer, about this issue, and he said it was unresolved between Richard and him. Are there any plans to resolve this problem in the near future? In particular, is it necessary to use /dev/rd for RAM disks rather than e.g. /dev/ramdisk ? Best regards, Martin -- Martin Wilck FSC EP PS DS1, Paderborn Tel. +49 5251 8 15113 From owner-devfs@oss.sgi.com Tue May 29 08:13:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4TFDTK03259 for devfs-outgoing; Tue, 29 May 2001 08:13:29 -0700 Received: from mobilix.ras.ucalgary.ca (empE-port7.net.McMaster.CA [130.113.193.62]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4TFDMd03248 for ; Tue, 29 May 2001 08:13:22 -0700 Received: (from rgooch@localhost) by mobilix.ras.ucalgary.ca (8.10.0/8.10.0) id f4TEmYH00390; Tue, 29 May 2001 10:48:34 -0400 Date: Tue, 29 May 2001 10:48:34 -0400 Message-Id: <200105291448.f4TEmYH00390@mobilix.ras.ucalgary.ca> From: Richard Gooch To: Martin Wilck Cc: devfs mailing list , "Leonard N. Zubkoff" Subject: Re: devfs & DAC960 ? In-Reply-To: References: Sender: owner-devfs@oss.sgi.com Precedence: bulk Martin Wilck writes: > > Hello, > > I have observed that when using devfs in connection with the > DAC960 driver for Mylex RAID, several things are going wrong: > > - The Mylex partitions appear as /dev/rd/discX/partY, where > they should appear as /dev/rd/controllerX/discY/partZ. > (or whatever mnemonic one would use for "controller"). > > - devfsd generates no compatibility entries of the "old" DAC960 style > /dev/rd/cXdYpZ. > > - Instead, /dev/rd is reserved for RAM disks in devfs. > > I had a short e-mail exchange with Leonard Zubkoff, the DAC960 > maintainer, about this issue, and he said it was unresolved between > Richard and him. We've been talking about it. It just takes time because I'm so busy (and I'm sure Leonard isn't idle either:-). Right now I'm on a multi-conference trip, so don't have time to deal with it properly. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Tue May 29 18:03:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4U13Kj17453 for devfs-outgoing; Tue, 29 May 2001 18:03:20 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4U12rh17442 for ; Tue, 29 May 2001 18:02:53 -0700 Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id DAA1034317 for ; Wed, 30 May 2001 03:02:47 +0200 (CEST) mail_from (tduffy@engr.sgi.com) Received: from dbear.engr.sgi.com (dbear.engr.sgi.com [163.154.18.85]) by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id SAA46823; Tue, 29 May 2001 18:00:57 -0700 (PDT) Date: Tue, 29 May 2001 17:59:37 -0700 (PDT) From: Tom Duffy To: Martin Wilck cc: devfs mailing list , "Leonard N. Zubkoff" Subject: Re: devfs & DAC960 ? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1700571886-393226193-991184377=:300" Sender: owner-devfs@oss.sgi.com Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---1700571886-393226193-991184377=:300 Content-Type: TEXT/PLAIN; charset=US-ASCII here is a patch that was done a while ago for 2.2.16 that made DAC960 a little smarter about devfs. not sure how it will apply today, but the basic idea is there :) -tduffy On Mon, 28 May 2001, Martin Wilck wrote: > > Hello, > > I have observed that when using devfs in connection with the > DAC960 driver for Mylex RAID, several things are going wrong: > > - The Mylex partitions appear as /dev/rd/discX/partY, where > they should appear as /dev/rd/controllerX/discY/partZ. > (or whatever mnemonic one would use for "controller"). > > - devfsd generates no compatibility entries of the "old" DAC960 style > /dev/rd/cXdYpZ. > > - Instead, /dev/rd is reserved for RAM disks in devfs. > > I had a short e-mail exchange with Leonard Zubkoff, the DAC960 > maintainer, about this issue, and he said it was unresolved between > Richard and him. > > Are there any plans to resolve this problem in the near future? > In particular, is it necessary to use /dev/rd for RAM disks rather than > e.g. /dev/ramdisk ? > > Best regards, > Martin > > ---1700571886-393226193-991184377=:300 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="linux-2.2.16-DAC960-devfs-fixup.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: patch Content-Disposition: attachment; filename="linux-2.2.16-DAC960-devfs-fixup.patch" ZGlmZiAtTnVyIGxpbnV4LW9sZERBQzk2MC9kcml2ZXJzL2Jsb2NrL0RBQzk2 MC5jIGxpbnV4LURBQzk2MC9kcml2ZXJzL2Jsb2NrL0RBQzk2MC5jDQotLS0g bGludXgtb2xkREFDOTYwL2RyaXZlcnMvYmxvY2svREFDOTYwLmMJRnJpIFNl cCAxNSAxMDoxODowMSAyMDAwDQorKysgbGludXgtREFDOTYwL2RyaXZlcnMv YmxvY2svREFDOTYwLmMJRnJpIFNlcCAxNSAwODowMTo0NiAyMDAwDQpAQCAt NTMsNiArNTMsNyBAQA0KIHN0YXRpYyBpbnQNCiAgIERBQzk2MF9Db250cm9s bGVyQ291bnQgPQkJCTA7DQogDQorI2luY2x1ZGUgPGxpbnV4L2RldmZzX2Zz X2tlcm5lbC5oPg0KIA0KIC8qDQogICBEQUM5NjBfQWN0aXZlQ29udHJvbGxl ckNvdW50IGlzIHRoZSBudW1iZXIgb2YgYWN0aXZlIERBQzk2MCBDb250cm9s bGVycw0KQEAgLTE2MjgsNyArMTYyOSw3IEBADQogICAgIHsNCiAgICAgICBE QUM5NjBfVjFfTG9naWNhbERyaXZlSW5mb3JtYXRpb25fVCAqTG9naWNhbERy aXZlSW5mb3JtYXRpb24gPQ0KIAkmQ29udHJvbGxlci0+VjEuTG9naWNhbERy aXZlSW5mb3JtYXRpb25bTG9naWNhbERyaXZlTnVtYmVyXTsNCi0gICAgICBE QUM5NjBfSW5mbygiICAgIC9kZXYvcmQvYyVkZCVkOiBSQUlELSVkLCAlcywg JWQgYmxvY2tzLCAlc1xuIiwNCisgICAgICBEQUM5NjBfSW5mbygiICAgIC9k ZXYvZGFjOTYwL2hvc3QlZC9kaXNjJWQvZGlzYzogUkFJRC0lZCwgJXMsICVk IGJsb2NrcywgJXNcbiIsDQogCQkgIENvbnRyb2xsZXIsIENvbnRyb2xsZXIt PkNvbnRyb2xsZXJOdW1iZXIsIExvZ2ljYWxEcml2ZU51bWJlciwNCiAJCSAg TG9naWNhbERyaXZlSW5mb3JtYXRpb24tPlJBSURMZXZlbCwNCiAJCSAgKExv Z2ljYWxEcml2ZUluZm9ybWF0aW9uLT5Mb2dpY2FsRHJpdmVTdGF0ZQ0KQEAg LTE3NjEsNyArMTc2Miw3IEBADQogCQkgICAgICAgQ29udHJvbGxlciwgTG9n aWNhbERldmljZUluZm8tPkRyaXZlR2VvbWV0cnkpOw0KIAkgIGJyZWFrOw0K IAl9DQotICAgICAgREFDOTYwX0luZm8oIiAgICAvZGV2L3JkL2MlZGQlZDog UkFJRC0lZCwgJXMsICVkIGJsb2Nrc1xuIiwNCisgICAgICBEQUM5NjBfSW5m bygiICAgIC9kZXYvZGFjOTYwL2hvc3QlZC9kaXNjJWQvZGlzYzogUkFJRC0l ZCwgJXMsICVkIGJsb2Nrc1xuIiwNCiAJCSAgQ29udHJvbGxlciwgQ29udHJv bGxlci0+Q29udHJvbGxlck51bWJlciwgTG9naWNhbERyaXZlTnVtYmVyLA0K IAkJICBMb2dpY2FsRGV2aWNlSW5mby0+UkFJRExldmVsLA0KIAkJICAoTG9n aWNhbERldmljZUluZm8tPkxvZ2ljYWxEZXZpY2VTdGF0ZQ0KQEAgLTE4MzMs MTUgKzE4MzQsMjMgQEANCiAgIGludCBNYWpvck51bWJlciA9IERBQzk2MF9N QUpPUiArIENvbnRyb2xsZXItPkNvbnRyb2xsZXJOdW1iZXI7DQogICBHZW5l cmljRGlza0luZm9fVCAqR2VuZXJpY0Rpc2tJbmZvOw0KICAgaW50IE1pbm9y TnVtYmVyOw0KKyAgZGV2ZnNfaGFuZGxlX3QgZGV2ZnNfaGFuZGxlOw0KKyAg c3RhdGljIGNoYXIgTWFqb3JOYW1lWzE2XTsNCiAgIC8qDQogICAgIFJlZ2lz dGVyIHRoZSBCbG9jayBEZXZpY2UgTWFqb3IgTnVtYmVyIGZvciB0aGlzIERB Qzk2MCBDb250cm9sbGVyLg0KICAgKi8NCi0gIGlmIChyZWdpc3Rlcl9ibGtk ZXYoTWFqb3JOdW1iZXIsICJyZCIsICZEQUM5NjBfRmlsZU9wZXJhdGlvbnMp IDwgMCkNCisgIHNwcmludGYoTWFqb3JOYW1lLCAiZGFjOTYwL2hvc3QlZCIs IENvbnRyb2xsZXItPkNvbnRyb2xsZXJOdW1iZXIpOw0KKyAgZGV2ZnNfbWtf ZGlyIChOVUxMLCAiZGFjOTYwIiwgMCwgTlVMTCk7DQorICBkZXZmc19oYW5k bGUgPSBkZXZmc19ta19kaXIgKE5VTEwsIE1ham9yTmFtZSwgMCwgTlVMTCk7 DQorDQorICBpZiAoZGV2ZnNfcmVnaXN0ZXJfYmxrZGV2KE1ham9yTnVtYmVy LCBNYWpvck5hbWUsDQorCQkJICAgICZEQUM5NjBfRmlsZU9wZXJhdGlvbnMp IDwgMCkNCiAgICAgew0KICAgICAgIERBQzk2MF9FcnJvcigiVU5BQkxFIFRP IEFDUVVJUkUgTUFKT1IgTlVNQkVSICVkIC0gREVUQUNISU5HXG4iLA0KIAkJ ICAgQ29udHJvbGxlciwgTWFqb3JOdW1iZXIpOw0KICAgICAgIHJldHVybiBm YWxzZTsNCiAgICAgfQ0KKw0KICAgLyoNCiAgICAgSW5pdGlhbGl6ZSB0aGUg SS9PIFJlcXVlc3QgRnVuY3Rpb24uDQogICAqLw0KQEAgLTE4NzIsNyArMTg4 MSw3IEBADQogICAgIENvbXBsZXRlIGluaXRpYWxpemF0aW9uIG9mIHRoZSBH ZW5lcmljIERpc2sgSW5mb3JtYXRpb24gc3RydWN0dXJlLg0KICAgKi8NCiAg IENvbnRyb2xsZXItPkdlbmVyaWNEaXNrSW5mby5tYWpvciA9IE1ham9yTnVt YmVyOw0KLSAgQ29udHJvbGxlci0+R2VuZXJpY0Rpc2tJbmZvLm1ham9yX25h bWUgPSAicmQiOw0KKyAgQ29udHJvbGxlci0+R2VuZXJpY0Rpc2tJbmZvLm1h am9yX25hbWUgPSBNYWpvck5hbWU7DQogICBDb250cm9sbGVyLT5HZW5lcmlj RGlza0luZm8ubWlub3Jfc2hpZnQgPSBEQUM5NjBfTWF4UGFydGl0aW9uc0Jp dHM7DQogICBDb250cm9sbGVyLT5HZW5lcmljRGlza0luZm8ubWF4X3AgPSBE QUM5NjBfTWF4UGFydGl0aW9uczsNCiAgIENvbnRyb2xsZXItPkdlbmVyaWNE aXNrSW5mby5tYXhfbnIgPSBEQUM5NjBfTWF4TG9naWNhbERyaXZlczsNCkBA IC0xOTA2LDEwICsxOTE1LDE2IEBADQogc3RhdGljIHZvaWQgREFDOTYwX1Vu cmVnaXN0ZXJCbG9ja0RldmljZShEQUM5NjBfQ29udHJvbGxlcl9UICpDb250 cm9sbGVyKQ0KIHsNCiAgIGludCBNYWpvck51bWJlciA9IERBQzk2MF9NQUpP UiArIENvbnRyb2xsZXItPkNvbnRyb2xsZXJOdW1iZXI7DQorICBkZXZmc19o YW5kbGVfdCBkZXZmc19oYW5kbGU7DQorICBjaGFyIE1ham9yTmFtZVsxNl07 DQorDQogICAvKg0KICAgICBVbnJlZ2lzdGVyIHRoZSBCbG9jayBEZXZpY2Ug TWFqb3IgTnVtYmVyIGZvciB0aGlzIERBQzk2MCBDb250cm9sbGVyLg0KICAg Ki8NCi0gIHVucmVnaXN0ZXJfYmxrZGV2KE1ham9yTnVtYmVyLCAicmQiKTsN CisgIHNwcmludGYoTWFqb3JOYW1lLCAiZGFjOTYwL2hvc3QlZCIsIENvbnRy b2xsZXItPkNvbnRyb2xsZXJOdW1iZXIpOw0KKyAgZGV2ZnNfaGFuZGxlID0g ZGV2ZnNfZmluZF9oYW5kbGUgKE5VTEwsIE1ham9yTmFtZSwgMCwgMCwgMCwg IERFVkZTX1NQRUNJQUxfQkxLLCAwKTsNCisgIGRldmZzX3VucmVnaXN0ZXJf YmxrZGV2KE1ham9yTnVtYmVyLCBNYWpvck5hbWUpOw0KKyAgZGV2ZnNfdW5y ZWdpc3RlcihkZXZmc19oYW5kbGUpOw0KICAgLyoNCiAgICAgUmVtb3ZlIHRo ZSBJL08gUmVxdWVzdCBGdW5jdGlvbi4NCiAgICovDQpAQCAtMjk4NywxMiAr MzAwMiwxMiBAQA0KIAkJICAgQ29udHJvbGxlciwgQ29tbWFuZC0+VjEuQ29t bWFuZFN0YXR1cywgQ29tbWFuZE5hbWUpOw0KICAgICAgIGJyZWFrOw0KICAg ICB9DQotICBEQUM5NjBfRXJyb3IoIiAgL2Rldi9yZC9jJWRkJWQ6ICAgYWJz b2x1dGUgYmxvY2tzICVkLi4lZFxuIiwNCisgIERBQzk2MF9FcnJvcigiICAv ZGV2L2RhYzk2MC9ob3N0JWQvZGlzYyVkL2Rpc2M6ICAgYWJzb2x1dGUgYmxv Y2tzICVkLi4lZFxuIiwNCiAJICAgICAgIENvbnRyb2xsZXIsIENvbnRyb2xs ZXItPkNvbnRyb2xsZXJOdW1iZXIsDQogCSAgICAgICBDb21tYW5kLT5Mb2dp Y2FsRHJpdmVOdW1iZXIsIENvbW1hbmQtPkJsb2NrTnVtYmVyLA0KIAkgICAg ICAgQ29tbWFuZC0+QmxvY2tOdW1iZXIgKyBDb21tYW5kLT5CbG9ja0NvdW50 IC0gMSk7DQogICBpZiAoREFDOTYwX1BhcnRpdGlvbk51bWJlcihDb21tYW5k LT5CdWZmZXJIZWFkZXItPmJfcmRldikgPiAwKQ0KLSAgICBEQUM5NjBfRXJy b3IoIiAgL2Rldi9yZC9jJWRkJWRwJWQ6IHJlbGF0aXZlIGJsb2NrcyAlZC4u JWRcbiIsDQorICAgIERBQzk2MF9FcnJvcigiICAvZGV2L2RhYzk2MC9ob3N0 JWQvZGlzYyVkL2Rpc2NwJWQ6IHJlbGF0aXZlIGJsb2NrcyAlZC4uJWRcbiIs DQogCQkgQ29udHJvbGxlciwgQ29udHJvbGxlci0+Q29udHJvbGxlck51bWJl ciwNCiAJCSBDb21tYW5kLT5Mb2dpY2FsRHJpdmVOdW1iZXIsDQogCQkgREFD OTYwX1BhcnRpdGlvbk51bWJlcihDb21tYW5kLT5CdWZmZXJIZWFkZXItPmJf cmRldiksDQpAQCAtMzE3NSw3ICszMTkwLDcgQEANCiAJICAgICAgaW50IExv Z2ljYWxEcml2ZU51bWJlciA9IENvbnRyb2xsZXItPkxvZ2ljYWxEcml2ZUNv dW50Ow0KIAkgICAgICB3aGlsZSAoTG9naWNhbERyaXZlTnVtYmVyIDwgTmV3 RW5xdWlyeS0+TnVtYmVyT2ZMb2dpY2FsRHJpdmVzKQ0KIAkJew0KLQkJICBE QUM5NjBfQ3JpdGljYWwoIkxvZ2ljYWwgRHJpdmUgJWQgKC9kZXYvcmQvYyVk ZCVkKSAiDQorCQkgIERBQzk2MF9Dcml0aWNhbCgiTG9naWNhbCBEcml2ZSAl ZCAoL2Rldi9kYWM5NjAvaG9zdCVkL2Rpc2MlZC9kaXNjKSAiDQogCQkJCSAg Ik5vdyBFeGlzdHNcbiIsIENvbnRyb2xsZXIsDQogCQkJCSAgTG9naWNhbERy aXZlTnVtYmVyLA0KIAkJCQkgIENvbnRyb2xsZXItPkNvbnRyb2xsZXJOdW1i ZXIsDQpAQCAtMzQzMSw3ICszNDQ2LDcgQEANCiAJCSZDb250cm9sbGVyLT5W MS5OZXdMb2dpY2FsRHJpdmVJbmZvcm1hdGlvbltMb2dpY2FsRHJpdmVOdW1i ZXJdOw0KIAkgICAgICBpZiAoTmV3TG9naWNhbERyaXZlSW5mb3JtYXRpb24t PkxvZ2ljYWxEcml2ZVN0YXRlICE9DQogCQkgIE9sZExvZ2ljYWxEcml2ZUlu Zm9ybWF0aW9uLT5Mb2dpY2FsRHJpdmVTdGF0ZSkNCi0JCURBQzk2MF9Dcml0 aWNhbCgiTG9naWNhbCBEcml2ZSAlZCAoL2Rldi9yZC9jJWRkJWQpICINCisJ CURBQzk2MF9Dcml0aWNhbCgiTG9naWNhbCBEcml2ZSAlZCAoL2Rldi9kYWM5 NjAvaG9zdCVkL2Rpc2MlZC9kaXNjKSAiDQogCQkJCSJpcyBub3cgJXNcbiIs IENvbnRyb2xsZXIsDQogCQkJCUxvZ2ljYWxEcml2ZU51bWJlciwNCiAJCQkJ Q29udHJvbGxlci0+Q29udHJvbGxlck51bWJlciwNCkBAIC0zNDQ0LDcgKzM0 NTksNyBAQA0KIAkJCQkgICA/ICJDUklUSUNBTCIgOiAiT0ZGTElORSIpKTsN CiAJICAgICAgaWYgKE5ld0xvZ2ljYWxEcml2ZUluZm9ybWF0aW9uLT5Xcml0 ZUJhY2sgIT0NCiAJCSAgT2xkTG9naWNhbERyaXZlSW5mb3JtYXRpb24tPldy aXRlQmFjaykNCi0JCURBQzk2MF9Dcml0aWNhbCgiTG9naWNhbCBEcml2ZSAl ZCAoL2Rldi9yZC9jJWRkJWQpICINCisJCURBQzk2MF9Dcml0aWNhbCgiTG9n aWNhbCBEcml2ZSAlZCAoL2Rldi9kYWM5NjAvaG9zdCVkL2Rpc2MlZC9kaXNj KSAiDQogCQkJCSJpcyBub3cgJXNcbiIsIENvbnRyb2xsZXIsDQogCQkJCUxv Z2ljYWxEcml2ZU51bWJlciwNCiAJCQkJQ29udHJvbGxlci0+Q29udHJvbGxl ck51bWJlciwNCkBAIC0zNDcyLDcgKzM0ODcsNyBAQA0KIAkgICAgY2FzZSBE QUM5NjBfVjFfTm9ybWFsQ29tcGxldGlvbjoNCiAJICAgICAgQ29udHJvbGxl ci0+RXBoZW1lcmFsUHJvZ3Jlc3NNZXNzYWdlID0gdHJ1ZTsNCiAJICAgICAg REFDOTYwX1Byb2dyZXNzKCJSZWJ1aWxkIGluIFByb2dyZXNzOiAiDQotCQkJ ICAgICAgIkxvZ2ljYWwgRHJpdmUgJWQgKC9kZXYvcmQvYyVkZCVkKSAiDQor CQkJICAgICAgIkxvZ2ljYWwgRHJpdmUgJWQgKC9kZXYvZGFjOTYwL2hvc3Ql ZC9kaXNjJWQvZGlzYykgIg0KIAkJCSAgICAgICIlZCUlIGNvbXBsZXRlZFxu IiwNCiAJCQkgICAgICBDb250cm9sbGVyLCBMb2dpY2FsRHJpdmVOdW1iZXIs DQogCQkJICAgICAgQ29udHJvbGxlci0+Q29udHJvbGxlck51bWJlciwNCkBA IC0zNTI5LDcgKzM1NDQsNyBAQA0KIAkgICAgew0KIAkgICAgICBDb250cm9s bGVyLT5FcGhlbWVyYWxQcm9ncmVzc01lc3NhZ2UgPSB0cnVlOw0KIAkgICAg ICBEQUM5NjBfUHJvZ3Jlc3MoIkNvbnNpc3RlbmN5IENoZWNrIGluIFByb2dy ZXNzOiAiDQotCQkJICAgICAgIkxvZ2ljYWwgRHJpdmUgJWQgKC9kZXYvcmQv YyVkZCVkKSAiDQorCQkJICAgICAgIkxvZ2ljYWwgRHJpdmUgJWQgKC9kZXYv ZGFjOTYwL2hvc3QlZC9kaXNjJWQvZGlzYykgIg0KIAkJCSAgICAgICIlZCUl IGNvbXBsZXRlZFxuIiwNCiAJCQkgICAgICBDb250cm9sbGVyLCBMb2dpY2Fs RHJpdmVOdW1iZXIsDQogCQkJICAgICAgQ29udHJvbGxlci0+Q29udHJvbGxl ck51bWJlciwNCkBAIC0zNzg5LDEyICszODA0LDEyIEBADQogICAgIH0NCiAg IERBQzk2MF9FcnJvcigiRXJyb3IgQ29uZGl0aW9uICVzIG9uICVzOlxuIiwg Q29udHJvbGxlciwNCiAJICAgICAgIFNlbnNlRXJyb3JzW0NvbW1hbmQtPlYy LlJlcXVlc3RTZW5zZS5TZW5zZUtleV0sIENvbW1hbmROYW1lKTsNCi0gIERB Qzk2MF9FcnJvcigiICAvZGV2L3JkL2MlZGQlZDogICBhYnNvbHV0ZSBibG9j a3MgJWQuLiVkXG4iLA0KKyAgREFDOTYwX0Vycm9yKCIgIC9kZXYvZGFjOTYw L2hvc3QlZC9kaXNjJWQvZGlzYzogICBhYnNvbHV0ZSBibG9ja3MgJWQuLiVk XG4iLA0KIAkgICAgICAgQ29udHJvbGxlciwgQ29udHJvbGxlci0+Q29udHJv bGxlck51bWJlciwNCiAJICAgICAgIENvbW1hbmQtPkxvZ2ljYWxEcml2ZU51 bWJlciwgQ29tbWFuZC0+QmxvY2tOdW1iZXIsDQogCSAgICAgICBDb21tYW5k LT5CbG9ja051bWJlciArIENvbW1hbmQtPkJsb2NrQ291bnQgLSAxKTsNCiAg IGlmIChEQUM5NjBfUGFydGl0aW9uTnVtYmVyKENvbW1hbmQtPkJ1ZmZlckhl YWRlci0+Yl9yZGV2KSA+IDApDQotICAgIERBQzk2MF9FcnJvcigiICAvZGV2 L3JkL2MlZGQlZHAlZDogcmVsYXRpdmUgYmxvY2tzICVkLi4lZFxuIiwNCisg ICAgREFDOTYwX0Vycm9yKCIgIC9kZXYvZGFjOTYwL2hvc3QlZC9kaXNjJWQv ZGlzY3AlZDogcmVsYXRpdmUgYmxvY2tzICVkLi4lZFxuIiwNCiAJCSBDb250 cm9sbGVyLCBDb250cm9sbGVyLT5Db250cm9sbGVyTnVtYmVyLA0KIAkJIENv bW1hbmQtPkxvZ2ljYWxEcml2ZU51bWJlciwNCiAJCSBEQUM5NjBfUGFydGl0 aW9uTnVtYmVyKENvbW1hbmQtPkJ1ZmZlckhlYWRlci0+Yl9yZGV2KSwNCkBA IC0zOTQ5LDEyICszOTY0LDEyIEBADQogCQkgICAgICBFdmVudC0+Q2hhbm5l bCwgRXZlbnQtPlRhcmdldElELCBFdmVudE1lc3NhZ2UpOw0KICAgICAgIGJy ZWFrOw0KICAgICBjYXNlICdMJzoNCi0gICAgICBEQUM5NjBfQ3JpdGljYWwo IkxvZ2ljYWwgRHJpdmUgJWQgKC9kZXYvcmQvYyVkZCVkKSAlc1xuIiwgQ29u dHJvbGxlciwNCisgICAgICBEQUM5NjBfQ3JpdGljYWwoIkxvZ2ljYWwgRHJp dmUgJWQgKC9kZXYvZGFjOTYwL2hvc3QlZC9kaXNjJWQvZGlzYykgJXNcbiIs IENvbnRyb2xsZXIsDQogCQkgICAgICBFdmVudC0+TG9naWNhbFVuaXQsIENv bnRyb2xsZXItPkNvbnRyb2xsZXJOdW1iZXIsDQogCQkgICAgICBFdmVudC0+ TG9naWNhbFVuaXQsIEV2ZW50TWVzc2FnZSk7DQogICAgICAgYnJlYWs7DQog ICAgIGNhc2UgJ00nOg0KLSAgICAgIERBQzk2MF9Qcm9ncmVzcygiTG9naWNh bCBEcml2ZSAlZCAoL2Rldi9yZC9jJWRkJWQpICVzXG4iLCBDb250cm9sbGVy LA0KKyAgICAgIERBQzk2MF9Qcm9ncmVzcygiTG9naWNhbCBEcml2ZSAlZCAo L2Rldi9kYWM5NjAvaG9zdCVkL2Rpc2MlZC9kaXNjKSAlc1xuIiwgQ29udHJv bGxlciwNCiAJCSAgICAgIEV2ZW50LT5Mb2dpY2FsVW5pdCwgQ29udHJvbGxl ci0+Q29udHJvbGxlck51bWJlciwNCiAJCSAgICAgIEV2ZW50LT5Mb2dpY2Fs VW5pdCwgRXZlbnRNZXNzYWdlKTsNCiAgICAgICBicmVhazsNCkBAIC00MDE5 LDcgKzQwMzQsNyBAQA0KIAkJCQkgICAgIHVuc2lnbmVkIGxvbmcgTG9naWNh bERldmljZVNpemUpDQogew0KICAgQ29udHJvbGxlci0+RXBoZW1lcmFsUHJv Z3Jlc3NNZXNzYWdlID0gdHJ1ZTsNCi0gIERBQzk2MF9Qcm9ncmVzcygiJXMg aW4gUHJvZ3Jlc3M6IExvZ2ljYWwgRHJpdmUgJWQgKC9kZXYvcmQvYyVkZCVk KSAiDQorICBEQUM5NjBfUHJvZ3Jlc3MoIiVzIGluIFByb2dyZXNzOiBMb2dp Y2FsIERyaXZlICVkICgvZGV2L2RhYzk2MC9ob3N0JWQvZGlzYyVkL2Rpc2Mp ICINCiAJCSAgIiVkJSUgY29tcGxldGVkXG4iLCBDb250cm9sbGVyLA0KIAkJ ICBNZXNzYWdlU3RyaW5nLA0KIAkJICBMb2dpY2FsRGV2aWNlTnVtYmVyLA0K QEAgLTQzNTAsNyArNDM2NSw3IEBADQogCQlrbWFsbG9jKHNpemVvZihEQUM5 NjBfVjJfTG9naWNhbERldmljZUluZm9fVCksIEdGUF9BVE9NSUMpOw0KIAkg ICAgICBDb250cm9sbGVyLT5WMi5Mb2dpY2FsRGV2aWNlSW5mb3JtYXRpb25b TG9naWNhbERldmljZU51bWJlcl0gPQ0KIAkJTG9naWNhbERldmljZUluZm87 DQotCSAgICAgIERBQzk2MF9Dcml0aWNhbCgiTG9naWNhbCBEcml2ZSAlZCAo L2Rldi9yZC9jJWRkJWQpICINCisJICAgICAgREFDOTYwX0NyaXRpY2FsKCJM b2dpY2FsIERyaXZlICVkICgvZGV2L2RhYzk2MC9ob3N0JWQvZGlzYyVkL2Rp c2MpICINCiAJCQkgICAgICAiTm93IEV4aXN0cyVzXG4iLCBDb250cm9sbGVy LA0KIAkJCSAgICAgIExvZ2ljYWxEZXZpY2VOdW1iZXIsDQogCQkJICAgICAg Q29udHJvbGxlci0+Q29udHJvbGxlck51bWJlciwNCkBAIC00MzY3LDcgKzQz ODIsNyBAQA0KIAkJTmV3TG9naWNhbERldmljZUluZm8tPkNvbmZpZ3VyYWJs ZURldmljZVNpemVJbjUxMkJ5dGVCbG9ja3NPck1COw0KIAkgICAgICBpZiAo TmV3TG9naWNhbERldmljZUluZm8tPkxvZ2ljYWxEZXZpY2VTdGF0ZSAhPQ0K IAkJICBMb2dpY2FsRGV2aWNlSW5mby0+TG9naWNhbERldmljZVN0YXRlKQ0K LQkJREFDOTYwX0NyaXRpY2FsKCJMb2dpY2FsIERyaXZlICVkICgvZGV2L3Jk L2MlZGQlZCkgIg0KKwkJREFDOTYwX0NyaXRpY2FsKCJMb2dpY2FsIERyaXZl ICVkICgvZGV2L2RhYzk2MC9ob3N0JWQvZGlzYyVkL2Rpc2MpICINCiAJCQkJ ImlzIG5vdyAlc1xuIiwgQ29udHJvbGxlciwNCiAJCQkJTG9naWNhbERldmlj ZU51bWJlciwNCiAJCQkJQ29udHJvbGxlci0+Q29udHJvbGxlck51bWJlciwN CkBAIC00Mzg0LDcgKzQzOTksNyBAQA0KIAkJICAgTG9naWNhbERldmljZUlu Zm8tPkNvbW1hbmRzRmFpbGVkKSB8fA0KIAkJICAoTmV3TG9naWNhbERldmlj ZUluZm8tPkRlZmVycmVkV3JpdGVFcnJvcnMgIT0NCiAJCSAgIExvZ2ljYWxE ZXZpY2VJbmZvLT5EZWZlcnJlZFdyaXRlRXJyb3JzKSkNCi0JCURBQzk2MF9D cml0aWNhbCgiTG9naWNhbCBEcml2ZSAlZCAoL2Rldi9yZC9jJWRkJWQpIEVy cm9yczogIg0KKwkJREFDOTYwX0NyaXRpY2FsKCJMb2dpY2FsIERyaXZlICVk ICgvZGV2L2RhYzk2MC9ob3N0JWQvZGlzYyVkL2Rpc2MpIEVycm9yczogIg0K IAkJCQkiU29mdCA9ICVkLCBGYWlsZWQgPSAlZCwgRGVmZXJyZWQgV3JpdGUg PSAlZFxuIiwNCiAJCQkJQ29udHJvbGxlciwgTG9naWNhbERldmljZU51bWJl ciwNCiAJCQkJQ29udHJvbGxlci0+Q29udHJvbGxlck51bWJlciwNCkBAIC02 MDk5LDE0ICs2MTE0LDE0IEBADQogCXsNCiAJY2FzZSBEQUM5NjBfVjFfTm9y bWFsQ29tcGxldGlvbjoNCiAJICBEQUM5NjBfVXNlckNyaXRpY2FsKCJDb25z aXN0ZW5jeSBDaGVjayBvZiBMb2dpY2FsIERyaXZlICVkICINCi0JCQkgICAg ICAiKC9kZXYvcmQvYyVkZCVkKSBJbml0aWF0ZWRcbiIsDQorCQkJICAgICAg IigvZGV2L2RhYzk2MC9ob3N0JWQvZGlzYyVkL2Rpc2MpIEluaXRpYXRlZFxu IiwNCiAJCQkgICAgICBDb250cm9sbGVyLCBMb2dpY2FsRHJpdmVOdW1iZXIs DQogCQkJICAgICAgQ29udHJvbGxlci0+Q29udHJvbGxlck51bWJlciwNCiAJ CQkgICAgICBMb2dpY2FsRHJpdmVOdW1iZXIpOw0KIAkgIGJyZWFrOw0KIAlj YXNlIERBQzk2MF9WMV9EZXBlbmRlbnREaXNrSXNEZWFkOg0KIAkgIERBQzk2 MF9Vc2VyQ3JpdGljYWwoIkNvbnNpc3RlbmN5IENoZWNrIG9mIExvZ2ljYWwg RHJpdmUgJWQgIg0KLQkJCSAgICAgICIoL2Rldi9yZC9jJWRkJWQpIEZhaWxl ZCAtICINCisJCQkgICAgICAiKC9kZXYvZGFjOTYwL2hvc3QlZC9kaXNjJWQv ZGlzYykgRmFpbGVkIC0gIg0KIAkJCSAgICAgICJEZXBlbmRlbnQgUGh5c2lj YWwgRGV2aWNlIGlzIERFQURcbiIsDQogCQkJICAgICAgQ29udHJvbGxlciwg TG9naWNhbERyaXZlTnVtYmVyLA0KIAkJCSAgICAgIENvbnRyb2xsZXItPkNv bnRyb2xsZXJOdW1iZXIsDQpAQCAtNjExNCw3ICs2MTI5LDcgQEANCiAJICBi cmVhazsNCiAJY2FzZSBEQUM5NjBfVjFfSW52YWxpZE9yTm9ucmVkdW5kYW50 TG9naWNhbERyaXZlOg0KIAkgIERBQzk2MF9Vc2VyQ3JpdGljYWwoIkNvbnNp c3RlbmN5IENoZWNrIG9mIExvZ2ljYWwgRHJpdmUgJWQgIg0KLQkJCSAgICAg ICIoL2Rldi9yZC9jJWRkJWQpIEZhaWxlZCAtICINCisJCQkgICAgICAiKC9k ZXYvZGFjOTYwL2hvc3QlZC9kaXNjJWQvZGlzYykgRmFpbGVkIC0gIg0KIAkJ CSAgICAgICJJbnZhbGlkIG9yIE5vbnJlZHVuZGFudCBMb2dpY2FsIERyaXZl XG4iLA0KIAkJCSAgICAgIENvbnRyb2xsZXIsIExvZ2ljYWxEcml2ZU51bWJl ciwNCiAJCQkgICAgICBDb250cm9sbGVyLT5Db250cm9sbGVyTnVtYmVyLA0K QEAgLTYxMjIsNyArNjEzNyw3IEBADQogCSAgYnJlYWs7DQogCWNhc2UgREFD OTYwX1YxX1JlYnVpbGRPckNoZWNrQWxyZWFkeUluUHJvZ3Jlc3M6DQogCSAg REFDOTYwX1VzZXJDcml0aWNhbCgiQ29uc2lzdGVuY3kgQ2hlY2sgb2YgTG9n aWNhbCBEcml2ZSAlZCAiDQotCQkJICAgICAgIigvZGV2L3JkL2MlZGQlZCkg RmFpbGVkIC0gUmVidWlsZCBvciAiDQorCQkJICAgICAgIigvZGV2L2RhYzk2 MC9ob3N0JWQvZGlzYyVkL2Rpc2MpIEZhaWxlZCAtIFJlYnVpbGQgb3IgIg0K IAkJCSAgICAgICJDb25zaXN0ZW5jeSBDaGVjayBBbHJlYWR5IGluIFByb2dy ZXNzXG4iLA0KIAkJCSAgICAgIENvbnRyb2xsZXIsIExvZ2ljYWxEcml2ZU51 bWJlciwNCiAJCQkgICAgICBDb250cm9sbGVyLT5Db250cm9sbGVyTnVtYmVy LA0KQEAgLTYxMzAsNyArNjE0NSw3IEBADQogCSAgYnJlYWs7DQogCWRlZmF1 bHQ6DQogCSAgREFDOTYwX1VzZXJDcml0aWNhbCgiQ29uc2lzdGVuY3kgQ2hl Y2sgb2YgTG9naWNhbCBEcml2ZSAlZCAiDQotCQkJICAgICAgIigvZGV2L3Jk L2MlZGQlZCkgRmFpbGVkIC0gIg0KKwkJCSAgICAgICIoL2Rldi9kYWM5NjAv aG9zdCVkL2Rpc2MlZC9kaXNjKSBGYWlsZWQgLSAiDQogCQkJICAgICAgIlVu ZXhwZWN0ZWQgU3RhdHVzICUwNFhcbiIsDQogCQkJICAgICAgQ29udHJvbGxl ciwgTG9naWNhbERyaXZlTnVtYmVyLA0KIAkJCSAgICAgIENvbnRyb2xsZXIt PkNvbnRyb2xsZXJOdW1iZXIsDQpAQCAtNjM0OSw3ICs2MzY0LDcgQEANCiAg ICAgICBDb21tYW5kTWFpbGJveC0+Q29uc2lzdGVuY3lDaGVjay5Jbml0aWFs aXplZEFyZWFPbmx5ID0gZmFsc2U7DQogICAgICAgREFDOTYwX0V4ZWN1dGVD b21tYW5kKENvbW1hbmQpOw0KICAgICAgIERBQzk2MF9Vc2VyQ3JpdGljYWwo IkNvbnNpc3RlbmN5IENoZWNrIG9mIExvZ2ljYWwgRHJpdmUgJWQgIg0KLQkJ CSAgIigvZGV2L3JkL2MlZGQlZCkgJXNcbiIsDQorCQkJICAiKC9kZXYvZGFj OTYwL2hvc3QlZC9kaXNjJWQvZGlzYykgJXNcbiIsDQogCQkJICBDb250cm9s bGVyLCBMb2dpY2FsRHJpdmVOdW1iZXIsDQogCQkJICBDb250cm9sbGVyLT5D b250cm9sbGVyTnVtYmVyLA0KIAkJCSAgTG9naWNhbERyaXZlTnVtYmVyLA0K QEAgLTYzNjcsNyArNjM4Miw3IEBADQogCURBQzk2MF9WMl9Db25zaXN0ZW5j eUNoZWNrU3RvcDsNCiAgICAgICBEQUM5NjBfRXhlY3V0ZUNvbW1hbmQoQ29t bWFuZCk7DQogICAgICAgREFDOTYwX1VzZXJDcml0aWNhbCgiQ29uc2lzdGVu Y3kgQ2hlY2sgb2YgTG9naWNhbCBEcml2ZSAlZCAiDQotCQkJICAiKC9kZXYv cmQvYyVkZCVkKSAlc1xuIiwNCisJCQkgICIoL2Rldi9kYWM5NjAvaG9zdCVk L2Rpc2MlZC9kaXNjKSAlc1xuIiwNCiAJCQkgIENvbnRyb2xsZXIsIExvZ2lj YWxEcml2ZU51bWJlciwNCiAJCQkgIENvbnRyb2xsZXItPkNvbnRyb2xsZXJO dW1iZXIsDQogCQkJICBMb2dpY2FsRHJpdmVOdW1iZXIsDQpAQCAtNjM4Nyw3 ICs2NDAyLDcgQEANCiANCiANCiAvKg0KLSAgREFDOTYwX1Byb2NSZWFkU3Rh dHVzIGltcGxlbWVudHMgcmVhZGluZyAvcHJvYy9yZC9zdGF0dXMuDQorICBE QUM5NjBfUHJvY1JlYWRTdGF0dXMgaW1wbGVtZW50cyByZWFkaW5nIC9wcm9j L2RhYzk2MC9zdGF0dXMuDQogKi8NCiANCiBzdGF0aWMgaW50IERBQzk2MF9Q cm9jUmVhZFN0YXR1cyhjaGFyICpQYWdlLCBjaGFyICoqU3RhcnQsIG9mZl90 IE9mZnNldCwNCkBAIC02NDIxLDcgKzY0MzYsNyBAQA0KIA0KIA0KIC8qDQot ICBEQUM5NjBfUHJvY1JlYWRJbml0aWFsU3RhdHVzIGltcGxlbWVudHMgcmVh ZGluZyAvcHJvYy9yZC9jTi9pbml0aWFsX3N0YXR1cy4NCisgIERBQzk2MF9Q cm9jUmVhZEluaXRpYWxTdGF0dXMgaW1wbGVtZW50cyByZWFkaW5nIC9wcm9j L2RhYzk2MC9jTi9pbml0aWFsX3N0YXR1cy4NCiAqLw0KIA0KIHN0YXRpYyBp bnQgREFDOTYwX1Byb2NSZWFkSW5pdGlhbFN0YXR1cyhjaGFyICpQYWdlLCBj aGFyICoqU3RhcnQsIG9mZl90IE9mZnNldCwNCkBAIC02NDQyLDcgKzY0NTcs NyBAQA0KIA0KIA0KIC8qDQotICBEQUM5NjBfUHJvY1JlYWRDdXJyZW50U3Rh dHVzIGltcGxlbWVudHMgcmVhZGluZyAvcHJvYy9yZC9jTi9jdXJyZW50X3N0 YXR1cy4NCisgIERBQzk2MF9Qcm9jUmVhZEN1cnJlbnRTdGF0dXMgaW1wbGVt ZW50cyByZWFkaW5nIC9wcm9jL2RhYzk2MC9jTi9jdXJyZW50X3N0YXR1cy4N CiAqLw0KIA0KIHN0YXRpYyBpbnQgREFDOTYwX1Byb2NSZWFkQ3VycmVudFN0 YXR1cyhjaGFyICpQYWdlLCBjaGFyICoqU3RhcnQsIG9mZl90IE9mZnNldCwN CkBAIC02NDkwLDcgKzY1MDUsNyBAQA0KIA0KIA0KIC8qDQotICBEQUM5NjBf UHJvY1JlYWRVc2VyQ29tbWFuZCBpbXBsZW1lbnRzIHJlYWRpbmcgL3Byb2Mv cmQvY04vdXNlcl9jb21tYW5kLg0KKyAgREFDOTYwX1Byb2NSZWFkVXNlckNv bW1hbmQgaW1wbGVtZW50cyByZWFkaW5nIC9wcm9jL2RhYzk2MC9jTi91c2Vy X2NvbW1hbmQuDQogKi8NCiANCiBzdGF0aWMgaW50IERBQzk2MF9Qcm9jUmVh ZFVzZXJDb21tYW5kKGNoYXIgKlBhZ2UsIGNoYXIgKipTdGFydCwgb2ZmX3Qg T2Zmc2V0LA0KQEAgLTY1MTEsNyArNjUyNiw3IEBADQogDQogDQogLyoNCi0g IERBQzk2MF9Qcm9jV3JpdGVVc2VyQ29tbWFuZCBpbXBsZW1lbnRzIHdyaXRp bmcgL3Byb2MvcmQvY04vdXNlcl9jb21tYW5kLg0KKyAgREFDOTYwX1Byb2NX cml0ZVVzZXJDb21tYW5kIGltcGxlbWVudHMgd3JpdGluZyAvcHJvYy9kYWM5 NjAvY04vdXNlcl9jb21tYW5kLg0KICovDQogDQogc3RhdGljIGludCBEQUM5 NjBfUHJvY1dyaXRlVXNlckNvbW1hbmQoRmlsZV9UICpGaWxlLCBjb25zdCBj aGFyICpCdWZmZXIsDQpAQCAtNjUzNiw3ICs2NTUxLDcgQEANCiANCiANCiAv Kg0KLSAgREFDOTYwX0NyZWF0ZVByb2NFbnRyaWVzIGNyZWF0ZXMgdGhlIC9w cm9jL3JkLy4uLiBlbnRyaWVzIGZvciB0aGUgREFDOTYwDQorICBEQUM5NjBf Q3JlYXRlUHJvY0VudHJpZXMgY3JlYXRlcyB0aGUgL3Byb2MvZGFjOTYwLy4u LiBlbnRyaWVzIGZvciB0aGUgREFDOTYwDQogICBEcml2ZXIuDQogKi8NCiAN CkBAIC02NTQ0LDcgKzY1NTksNyBAQA0KIHsNCiAgIHN0YXRpYyBQUk9DX0Rp cmVjdG9yeUVudHJ5X1QgU3RhdHVzUHJvY0VudHJ5Ow0KICAgaW50IENvbnRy b2xsZXJOdW1iZXI7DQotICBEQUM5NjBfUHJvY0RpcmVjdG9yeUVudHJ5Lm5h bWUgPSAicmQiOw0KKyAgREFDOTYwX1Byb2NEaXJlY3RvcnlFbnRyeS5uYW1l ID0gImRhYzk2MCI7DQogICBEQUM5NjBfUHJvY0RpcmVjdG9yeUVudHJ5Lm5h bWVsZW4gPSBzdHJsZW4oREFDOTYwX1Byb2NEaXJlY3RvcnlFbnRyeS5uYW1l KTsNCiAgIERBQzk2MF9Qcm9jRGlyZWN0b3J5RW50cnkubW9kZSA9IFNfSUZE SVIgfCBTX0lSVUdPIHwgU19JWFVHTzsNCiAgIHByb2NfcmVnaXN0ZXIoJnBy b2Nfcm9vdCwgJkRBQzk2MF9Qcm9jRGlyZWN0b3J5RW50cnkpOw0KQEAgLTY1 NjEsNyArNjU3Niw3IEBADQogICAgICAgUFJPQ19EaXJlY3RvcnlFbnRyeV9U ICpDb250cm9sbGVyUHJvY0VudHJ5LCAqSW5pdGlhbFN0YXR1c1Byb2NFbnRy eTsNCiAgICAgICBQUk9DX0RpcmVjdG9yeUVudHJ5X1QgKkN1cnJlbnRTdGF0 dXNQcm9jRW50cnksICpVc2VyQ29tbWFuZFByb2NFbnRyeTsNCiAgICAgICBp ZiAoQ29udHJvbGxlciA9PSBOVUxMKSBjb250aW51ZTsNCi0gICAgICBzcHJp bnRmKENvbnRyb2xsZXItPkNvbnRyb2xsZXJOYW1lLCAiYyVkIiwgQ29udHJv bGxlci0+Q29udHJvbGxlck51bWJlcik7DQorICAgICAgc3ByaW50ZihDb250 cm9sbGVyLT5Db250cm9sbGVyTmFtZSwgImhvc3QlZCIsIENvbnRyb2xsZXIt PkNvbnRyb2xsZXJOdW1iZXIpOw0KICAgICAgIENvbnRyb2xsZXJQcm9jRW50 cnkgPSAmQ29udHJvbGxlci0+Q29udHJvbGxlclByb2NFbnRyeTsNCiAgICAg ICBDb250cm9sbGVyUHJvY0VudHJ5LT5uYW1lID0gQ29udHJvbGxlci0+Q29u dHJvbGxlck5hbWU7DQogICAgICAgQ29udHJvbGxlclByb2NFbnRyeS0+bmFt ZWxlbiA9IHN0cmxlbihDb250cm9sbGVyUHJvY0VudHJ5LT5uYW1lKTsNCkBA IC02NTk0LDcgKzY2MDksNyBAQA0KIA0KIA0KIC8qDQotICBEQUM5NjBfRGVz dHJveVByb2NFbnRyaWVzIGRlc3Ryb3lzIHRoZSAvcHJvYy9yZC8uLi4gZW50 cmllcyBmb3IgdGhlIERBQzk2MA0KKyAgREFDOTYwX0Rlc3Ryb3lQcm9jRW50 cmllcyBkZXN0cm95cyB0aGUgL3Byb2MvZGFjOTYwLy4uLiBlbnRyaWVzIGZv ciB0aGUgREFDOTYwDQogICBEcml2ZXIuDQogKi8NCiANCmRpZmYgLU51ciBs aW51eC1vbGREQUM5NjAvZHJpdmVycy9ibG9jay9nZW5oZC5jIGxpbnV4LURB Qzk2MC9kcml2ZXJzL2Jsb2NrL2dlbmhkLmMNCi0tLSBsaW51eC1vbGREQUM5 NjAvZHJpdmVycy9ibG9jay9nZW5oZC5jCUZyaSBTZXAgMTUgMTA6MTg6MDAg MjAwMA0KKysrIGxpbnV4LURBQzk2MC9kcml2ZXJzL2Jsb2NrL2dlbmhkLmMJ RnJpIFNlcCAxNSAwODowMDozMiAyMDAwDQpAQCAtODIsMTEgKzgyLDE4IEBA DQogICAgICAgICBpbnQgY3RsciA9IGhkLT5tYWpvciAtIG1ham9yX2Jhc2U7 DQogICAgICAgICBpbnQgZGlzayA9IG1pbm9yID4+IGhkLT5taW5vcl9zaGlm dDsNCiAgICAgICAgIGludCBwYXJ0ID0gbWlub3IgJiAoKCAxIDw8IGhkLT5t aW5vcl9zaGlmdCkgLSAxKTsNCi0gICAgICAgIGlmIChwYXJ0ID09IDApDQot ICAgICAgICAgICAgICAgIHNwcmludGYoYnVmLCAiJXMvYyVkZCVkIiwgaGQt Pm1ham9yX25hbWUsIGN0bHIsIGRpc2spOw0KLSAgICAgICAgZWxzZQ0KLSAg ICAgICAgICAgICAgICBzcHJpbnRmKGJ1ZiwgIiVzL2MlZGQlZHAlZCIsIGhk LT5tYWpvcl9uYW1lLCBjdGxyLCBkaXNrLA0KLSAgICAgICAgICAgICAgICAg ICAgICAgIHBhcnQpOw0KKyAgICAgICAgaWYgKHBhcnQgPT0gMCkgew0KKwkJ aWYgKG1ham9yX2Jhc2UgPT0gREFDOTYwX01BSk9SKQ0KKwkJICAgIHNwcmlu dGYoYnVmLCAiJXMvZGlzYyVkIiwgaGQtPm1ham9yX25hbWUsIGN0bHIsIGRp c2spOw0KKwkJZWxzZQ0KKwkJICAgIHNwcmludGYoYnVmLCAiJXMvYyVkZCVk IiwgaGQtPm1ham9yX25hbWUsIGN0bHIsIGRpc2spOw0KKwl9DQorICAgICAg ICBlbHNlIHsNCisJCWlmIChtYWpvcl9iYXNlID09IERBQzk2MF9NQUpPUikN CisJCSAgICBzcHJpbnRmKGJ1ZiwgIiVzL2Rpc2MlZCIsIGhkLT5tYWpvcl9u YW1lLCBjdGxyLCBkaXNrKTsNCisJCWVsc2UNCisJCSAgICBzcHJpbnRmKGJ1 ZiwgIiVzL2MlZGQlZHAlZCIsIGhkLT5tYWpvcl9uYW1lLCBjdGxyLCBkaXNr LCBwYXJ0KTsNCisJfQ0KICAgICAgICAgcmV0dXJuIGJ1ZjsNCiB9DQogDQpA QCAtMTU2Miw2ICsxNTY5LDcgQEANCiAJc3ByaW50ZiAoc3ltbGluaywgImRp c2MldSIsIGRpc2NfY291bnRlcisrKTsNCiAJZGV2ZnNfbWtfc3ltbGluayAo ZGV2ZnNfaGFuZGxlLCBzeW1saW5rLCAwLCBERVZGU19GTF9ERUZBVUxULA0K IAkJCSAgZGlybmFtZSArIHBvcywgMCwgJnNsYXZlLCBOVUxMKTsNCisNCiAJ ZGV2LT5wYXJ0W21pbm9yXS5kZSA9DQogCSAgICBkZXZmc19yZWdpc3RlciAo ZGlyLCAiZGlzYyIsIGRldmZzX2ZsYWdzLCBkZXYtPm1ham9yLCBtaW5vciwN CiAJCQkgICAgU19JRkJMSyB8IFNfSVJVU1IgfCBTX0lXVVNSLCBkZXYtPmZv cHMsIE5VTEwpOw0K ---1700571886-393226193-991184377=:300-- From owner-devfs@oss.sgi.com Tue May 29 18:10:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4U1Ack17751 for devfs-outgoing; Tue, 29 May 2001 18:10:38 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4U1AXh17748 for ; Tue, 29 May 2001 18:10:33 -0700 Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA18113 for ; Tue, 29 May 2001 18:10:33 -0700 (PDT) mail_from (tduffy@engr.sgi.com) Received: from dbear.engr.sgi.com (dbear.engr.sgi.com [163.154.18.85]) by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id SAA17222; Tue, 29 May 2001 18:09:16 -0700 (PDT) Date: Tue, 29 May 2001 18:07:56 -0700 (PDT) From: Tom Duffy To: Martin Wilck cc: devfs mailing list , "Leonard N. Zubkoff" Subject: Re: devfs & DAC960 ? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1700571886-217091059-991184876=:300" Sender: owner-devfs@oss.sgi.com Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---1700571886-217091059-991184876=:300 Content-Type: TEXT/PLAIN; charset=US-ASCII also, here is the changes to devfsd to get the compat names. -tduffy On Tue, 29 May 2001, Tom Duffy wrote: > here is a patch that was done a while ago for 2.2.16 that made DAC960 a > little smarter about devfs. not sure how it will apply today, but the > basic idea is there :) > > -tduffy ---1700571886-217091059-991184876=:300 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=a Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=a LS0tIC91c3IvdG1wL1RtcERpci4yMzg0NS0wL2NtZC9kZXZmc2QvbW9kdWxl cy5kZXZmc18xLjQJVHVlIE1heSAyOSAxODowNjo1NCAyMDAxDQorKysgL3Vz ci90bXAvVG1wRGlyLjIzODQ1LTAvY21kL2RldmZzZC9tb2R1bGVzLmRldmZz XzEuNQlUdWUgTWF5IDI5IDE4OjA2OjU0IDIwMDENCkBAIC0xMDIsNiArMTAy LDEwIEBADQogIyBUZWxsIGRldmZzIHRoYXQgL2Rldi9oZCogZGV2aWNlcyBh cmUgaWRlLg0KIGFsaWFzICAvZGV2L2hkKiAvZGV2L2lkZQ0KIA0KKyMgTXls ZXggREFDOTYwIFJBSUQgZGV2aWNlcw0KK3Byb2JlYWxsICAvZGV2L2RhYzk2 MCAgICAgICAgICAgREFDOTYwDQorYWxpYXMgICAgIC9kZXYvcmQvYyogICAg ICAgICAgICAvZGV2L2RhYzk2MA0KKw0KICMgUHVsbCBpbiB0aGUgY29uZmln dXJhdGlvbiBmaWxlLiBEbyB0aGlzIGxhc3QgYmVjYXVzZSBtb2Rwcm9iZSg4 KSBwcm9jZXNzZXMgaW4NCiAjIHBlcl5IXkheSHJldmVyc2Ugb3JkZXIgYW5k IHRoZSBzeXNhZG1pbiBtYXkgd2FudCB0byBvdmVyLXJpZGUgd2hhdCBpcyBp biB0aGUNCiAjIGdlbmVyaWMgZmlsZQ0KLS0tIC91c3IvdG1wL1RtcERpci4y Mzg2OC0wL2NtZC9kZXZmc2QvY29tcGF0X25hbWUuY18xLjIJVHVlIE1heSAy OSAxODowNzoxNyAyMDAxDQorKysgL3Vzci90bXAvVG1wRGlyLjIzODY4LTAv Y21kL2RldmZzZC9jb21wYXRfbmFtZS5jXzEuMwlUdWUgTWF5IDI5IDE4OjA3 OjE3IDIwMDENCkBAIC0yMTUsNiArMjE1LDI4IEBADQogCXNwcmludGYgKGJ1 ZmZlciwgIiVzanMlZCIsIHR5cGUsIGluZGV4KTsNCiAJY29tcGF0X25hbWUg PSBidWZmZXI7DQogICAgIH0NCisgICAgZWxzZSBpZiAoc3RybmNtcCAoZGV2 bmFtZSwgImRhYzk2MC8iLCA3KSA9PSAwKQ0KKyAgICB7DQorCS8qIERBQzk2 MCBSQUlEIERldmljZQ0KKwkgKiBUaGUgb2xkIG5hbWluZyBzY2hlbWUgaXMg L2Rldi9yZC9jWGRZcFoNCisJICogVGhlIG5ldyBuYW1pbmcgc2NoZW1lIGlz IC9kZXYvZGFjOTYwL2hvc3RYL2Rpc2NZL3BhcnRaDQorCSAqDQorCSAqIE1h am9yIG51bWJlcnMgcnVuIGZyb20gNDYgdGhyb3VnaCA1NTsgbWlub3IgbnVt YmVycyBydW4gZnJvbQ0KKwkgKiAwIHRocm91Z2ggMjU1LiBFYWNoIGRpc2Mg bWF5IGhhdmUgc2V2ZW4gcGFydHM7IGEgbWlub3IgbnVtYmVyDQorCSAqIHRo YXQgaXMgZGl2aXNpYmxlIGJ5IGVpZ2h0IHJlcHJlc2VudHMgdGhlIHdob2xl IGRpc2MuDQorCSAqLw0KKwkNCisJaWYgKChtaW5vciAlIDgpID09IDApDQor CXsNCisJICAgIC8qIFRoaXMgaXMgdGhlIHdob2xlIGRpc2MuICovDQorCSAg ICBzcHJpbnRmIChidWZmZXIsICJyZC9jJWRkJWQiLCBtYWpvciAtIDQ4LCBt aW5vciAvIDgpOw0KKwl9DQorCWVsc2UNCisJew0KKwkgICAgc3ByaW50ZiAo YnVmZmVyLCAicmQvYyVkZCVkcCVkIiwgbWFqb3IgLSA0OCwgbWlub3IgLyA4 LCBtaW5vciAlIDgpOw0KKwl9DQorCWNvbXBhdF9uYW1lID0gYnVmZmVyOw0K KyAgICB9DQogICAgIHJldHVybiAoY29tcGF0X25hbWUpOw0KIH0gICAvKiAg RW5kIEZ1bmN0aW9uIGdldF9vbGRfbmFtZSAgKi8NCiANCg== ---1700571886-217091059-991184876=:300-- From owner-devfs@oss.sgi.com Tue May 29 18:52:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4U1qpK18514 for devfs-outgoing; Tue, 29 May 2001 18:52:51 -0700 Received: from mail.rdc1.tn.home.com (imail@ha1.rdc1.tn.home.com [24.2.7.66]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4U1qmh18510 for ; Tue, 29 May 2001 18:52:48 -0700 Received: from CX376762B ([24.12.82.152]) by mail.rdc1.tn.home.com (InterMail vM.4.01.02.00 201-229-116) with SMTP id <20010530015242.OCUQ4073.mail.rdc1.tn.home.com@CX376762B> for ; Tue, 29 May 2001 18:52:42 -0700 Message-ID: <00f201c0e8aa$ef5fef20$98520c18@CX376762B> Reply-To: "Tom Browder" From: "Tom Browder" To: Subject: Devfs and LS-120 Date: Tue, 29 May 2001 20:50:42 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Sender: owner-devfs@oss.sgi.com Precedence: bulk OK, I have the XFS 1 Red Hat 7.1 going, removed ext2labels from my fstab file (still getting some weird messages but everything mounts and I can use all partitions), and just have one small problem, my LS-120 which is /dev/hdd. When I boot with a disk in it, the system recognizes it fine. But when I boot without a disk in, I can't figure out how to get the automounter to work. I have the following line in fstab: /dev/hdd /mnt/ls120 auto noauto,owner 0 0 Any help will be appreciated. Tom Browder From owner-devfs@oss.sgi.com Wed May 30 06:52:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4UDq2028880 for devfs-outgoing; Wed, 30 May 2001 06:52:02 -0700 Received: from mobilix.ras.ucalgary.ca (lpce023.lss.emc.com [168.159.62.23]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UDpvh28877 for ; Wed, 30 May 2001 06:51:57 -0700 Received: (from rgooch@localhost) by mobilix.ras.ucalgary.ca (8.10.0/8.10.0) id f4UDc7N00601; Wed, 30 May 2001 09:38:07 -0400 Date: Wed, 30 May 2001 09:38:07 -0400 Message-Id: <200105301338.f4UDc7N00601@mobilix.ras.ucalgary.ca> From: Richard Gooch To: linux-kernel@vger.kernel.org, devfs-announce-list@mobilix.ras.ucalgary.ca Subject: [PATCH] devfs v177 available Sender: owner-devfs@oss.sgi.com Precedence: bulk Hi, all. Version 177 of my devfs patch is now available from: http://www.atnf.csiro.au/~rgooch/linux/kernel-patches.html The devfs FAQ is also available here. Patch directly available from: ftp://ftp.??.kernel.org/pub/linux/kernel/people/rgooch/v2.4/devfs-patch-current.gz AND: ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/kernel-patches/v2.4/devfs-patch-current.gz This is against 2.4.5. Highlights of this release: - Updated README from master HTML file - Documentation cleanups - Ensure terminates string for root entry Thanks to Tim Jansen - Exported to modules - Make send events to devfsd - Cleaned up option processing in - Fixed bugs in handling symlinks: could leak or cause Oops - Cleaned up directory handling by separating fops Thanks to Alexander Viro Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Wed May 30 09:48:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4UGmam01197 for devfs-outgoing; Wed, 30 May 2001 09:48:36 -0700 Received: from mail.labsysgrp.com (phnx1-blk2-hfc-0251-d1db10f1.rdc1.az.coxatwork.com [209.219.16.241]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UGmVh01194 for ; Wed, 30 May 2001 09:48:31 -0700 Received: from jeeves.kpf.internal ([192.168.170.1]) by mail.labsysgrp.com with esmtp (Exim 3.22 #2) id 15518B-0008RX-00; Wed, 30 May 2001 01:15:04 -0700 Received: from [192.168.170.109] (helo=Kevin) by jeeves.kpf.internal with smtp (Exim 3.22 #3) id 1550h3-0003Zx-00; Wed, 30 May 2001 00:47:01 -0700 Message-ID: <001d01c0e8dd$7ec092a0$6daaa8c0@Kevin> From: "Kevin P. Fleming" To: "Tom Browder" , References: <00f201c0e8aa$ef5fef20$98520c18@CX376762B> Subject: Re: Devfs and LS-120 Date: Wed, 30 May 2001 00:52:37 -0700 Organization: LSG, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-devfs@oss.sgi.com Precedence: bulk Well, you've found a problem I found about two weeks ago: the short answer is, devfs and removable media are not really very compatible right now, specifically the ide-floppy driver that you're using (and I also use for a 250Mo ZIP drive). As it stands today, if you compile ide-floppy as a module, then load it when you want to use a disk, it will see the media in the drive and register the appropriate entries with devfs. You can then use the disk. However, if you then eject the disk and unload ide-floppy, the devfs entries won't go away. I've sent a patch to Richard to fix that, hopefully it will make into an -ac kernel soon. However, ide-floppy does not currently monitor the drive for media insertions and removals, so that's the extent of what can be accomplished. That probably means that automounting ide-floppy media while using devfs is not going to work for a while. I will be modifying the ide-floppy driver to watch for media changes and handle them appropriately, but this will not be ready for some time, as the work won't start until the IDE subsystem gets changed to support some new functionality (which is being done as we speak, targeted at the 2.5 kernel). Sorry to tell you this, but at this point if you want to automount ide-floppy media (or even have the drive work without loading/unloading ide-floppy repeatedly), you probably don't want to use devfs. ----- Original Message ----- From: "Tom Browder" To: Sent: Tuesday, May 29, 2001 6:50 PM Subject: Devfs and LS-120 > OK, I have the XFS 1 Red Hat 7.1 going, removed ext2labels > from my fstab file (still getting some weird messages but > everything > mounts and I can use all partitions), and just have one > small problem, > my LS-120 which is /dev/hdd. > > When I boot with a disk in it, the system recognizes it > fine. But when I > boot without a disk in, I can't figure out how to get the > automounter to > work. I have the following line in fstab: > > /dev/hdd /mnt/ls120 auto > noauto,owner 0 0 > > Any help will be appreciated. > > Tom Browder > > > > > From owner-devfs@oss.sgi.com Wed May 30 11:11:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4UIBW611788 for devfs-outgoing; Wed, 30 May 2001 11:11:32 -0700 Received: from energy.pdb.sbs.de (energy.pdb.sbs.de [192.109.2.19]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UIB4h11774 for ; Wed, 30 May 2001 11:11:05 -0700 Received: from trolli.pdb.fsc.net ([172.25.97.20]) by energy.pdb.sbs.de (8.9.3/8.9.3) with ESMTP id SAA15638; Wed, 30 May 2001 18:42:23 +0200 Received: from biker.pdb.fsc.net (biker.pdb.fsc.net [172.25.187.106]) by trolli.pdb.fsc.net (8.9.3/8.9.3) with ESMTP id SAA13003; Wed, 30 May 2001 18:42:22 +0200 Received: from localhost (martin@localhost) by biker.pdb.fsc.net (8.11.0/8.11.0) with ESMTP id f4UGfKV23476; Wed, 30 May 2001 18:41:20 +0200 Date: Wed, 30 May 2001 18:41:20 +0200 (CEST) From: Martin Wilck To: Linux-IA64 Mailing list , devfs mailing list Subject: Patch: /dev/guid support Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-devfs@oss.sgi.com Precedence: bulk Hello, here is a small patch I suggest for Linux/IA64. It makes the kernel aware of the GUIDs of hard disks and partitions and thereby allows to e.g. mount volumes by GUID rather than driver/bus/target/lun, so that volumes can be uniquely identified even if the sequence of controllers or disks on a controller changes. The patch relies heavily on devfs and the EFI/GPT code in the IA64 kernel. It is against 2.4.4 with David's latest IA64 patch (08/05/2001). GUIDs are only recognized on disks with an EFI GPT partition table. The GUIDs appear as soft links in /dev/guid, like this: $ ls -l /dev/guid total 0 25fb7980-1dd2-1000-8b55-00d0b7c7f993 -> ../scsi/host0/bus0/target0/lun0/disc lr-xr-xr-x 1 root root 37 Jan 1 1970 272ca680-1dd2-1000-b7ef-00d0b7c7f993 -> ../scsi/host0/bus0/target0/lun0/part1 lr-xr-xr-x 1 root root 37 Jan 1 1970 87821d20-f3fa-2444-96b9-7ad4423d337b -> ../scsi/host0/bus0/target0/lun0/part2 lr-xr-xr-x 1 root root 36 Jan 1 1970 a1050a55-2b64-244a-924d-8f6b9ea01931 -> ../scsi/host1/bus0/target3/lun0/disc lr-xr-xr-x 1 root root 37 Jan 1 1970 e3f2fd2f-604c-614e-b135-d74f3b5f9277 -> ../scsi/host0/bus0/target0/lun0/part3 lr-xr-xr-x 1 root root 37 Jan 1 1970 e853dbd1-6dc3-1f4d-8e23-09311b60dd9e -> ../scsi/host1/bus0/target3/lun0/part1 As you can see, there are links for the entire disks as well as the partitions. On my system, links are correctly deleted / replaced if a disk is repartitioned. Notes: - The most heavy change in kernel internals is the inclusion of a efi_guid_t* field in the hd_struct structure. - I have copied Matt's uuid_unparse() function to fs/partition/check.c. I assume it would have been better to export Matt's function and have it only once in the code, but I couldn't figure out in which subtree it would then best belong. Any improvements/suggestions/fixes greatly appreciated. Martin -- Martin Wilck FSC EP PS DS1, Paderborn Tel. +49 5251 8 15113 diff -ru -x *.o -x.* -x*.rej -x*~ linux-2.4.4-orig/Documentation/Configure.help linux-2.4.4mw/Documentation/Configure.help --- linux-2.4.4-orig/Documentation/Configure.help Wed May 30 20:27:55 2001 +++ linux-2.4.4mw/Documentation/Configure.help Wed May 30 18:24:09 2001 @@ -11996,6 +11996,12 @@ were partitioned using EFI GPT. Presently only useful on the IA-64 platform. +/dev/guid support (EXPERIMENTAL) +CONFIG_DEVFS_GUID + Say Y here if you would like to access disks and partitions by + their Globally Unique Identifiers (GUIDs) which will appear as + symbolic links in /dev/guid. + Ultrix partition support CONFIG_ULTRIX_PARTITION Say Y here if you would like to be able to read the hard disk diff -ru -x *.o -x.* -x*.rej -x*~ linux-2.4.4-orig/fs/devfs/base.c linux-2.4.4mw/fs/devfs/base.c --- linux-2.4.4-orig/fs/devfs/base.c Wed May 30 20:27:55 2001 +++ linux-2.4.4mw/fs/devfs/base.c Wed May 30 20:27:38 2001 @@ -1903,6 +1903,27 @@ return master->slave; } /* End Function devfs_get_unregister_slave */ +#ifdef CONFIG_DEVFS_GUID +/** + * devfs_unregister_slave - remove the slave that is unregistered when @master is unregistered. + * Destroys the connection established by devfs_auto_unregister. + * + * @master: The master devfs entry. + */ + +void devfs_unregister_slave (devfs_handle_t master) +{ + devfs_handle_t slave; + + if (master == NULL) return; + + slave = master->slave; + if (slave) { + master->slave = NULL; + unregister (slave); + }; +} +#endif /* CONFIG_DEVFS_GUID */ /** * devfs_get_name - Get the name for a device entry in its parent directory. @@ -2103,6 +2124,9 @@ EXPORT_SYMBOL(devfs_get_next_sibling); EXPORT_SYMBOL(devfs_auto_unregister); EXPORT_SYMBOL(devfs_get_unregister_slave); +#ifdef CONFIG_DEVFS_GUID +EXPORT_SYMBOL(devfs_unregister_slave); +#endif EXPORT_SYMBOL(devfs_register_chrdev); EXPORT_SYMBOL(devfs_register_blkdev); EXPORT_SYMBOL(devfs_unregister_chrdev); diff -ru -x *.o -x.* -x*.rej -x*~ linux-2.4.4-orig/fs/partitions/Config.in linux-2.4.4mw/fs/partitions/Config.in --- linux-2.4.4-orig/fs/partitions/Config.in Wed May 30 20:27:55 2001 +++ linux-2.4.4mw/fs/partitions/Config.in Wed May 30 18:24:03 2001 @@ -25,6 +25,7 @@ bool ' Solaris (x86) partition table support' CONFIG_SOLARIS_X86_PARTITION bool ' Unixware slices support' CONFIG_UNIXWARE_DISKLABEL bool ' EFI GUID Partition support' CONFIG_EFI_PARTITION + dep_bool ' /dev/guid support (EXPERIMENTAL)' CONFIG_DEVFS_GUID $CONFIG_DEVFS_FS $CONFIG_EFI_PARTITION fi bool ' SGI partition support' CONFIG_SGI_PARTITION bool ' Ultrix partition table support' CONFIG_ULTRIX_PARTITION diff -ru -x *.o -x.* -x*.rej -x*~ linux-2.4.4-orig/fs/partitions/check.c linux-2.4.4mw/fs/partitions/check.c --- linux-2.4.4-orig/fs/partitions/check.c Wed May 30 20:27:55 2001 +++ linux-2.4.4mw/fs/partitions/check.c Wed May 30 19:29:55 2001 @@ -37,6 +37,18 @@ # include "efi.h" #endif +#ifdef CONFIG_DEVFS_GUID +#define GUID_UNPARSED_LEN 36 +static void +uuid_unparse_1(efi_guid_t *guid, char *out) +{ + sprintf(out, "%08x-%04x-%04x-%02x%02x-%02x%02x%02x%02x%02x%02x", + guid->data1, guid->data2, guid->data3, + guid->data4[0], guid->data4[1], guid->data4[2], guid->data4[3], + guid->data4[4], guid->data4[5], guid->data4[6], guid->data4[7]); +} +#endif + extern void device_init(void); extern int *blk_size[]; extern void rd_load(void); @@ -82,6 +94,10 @@ NULL }; +#ifdef CONFIG_DEVFS_GUID +static devfs_handle_t guid_top_handle; +#endif + /* * disk_name() is used by partition check code and the md driver. * It formats the devicename of the indicated disk into @@ -317,6 +333,101 @@ devfs_register_partitions (hd, i, hd->sizes ? 0 : 1); } +#ifdef CONFIG_DEVFS_GUID +/* + devfs_register_guid: create a /dev/guid entry for a disk or partition + if it has a GUID. + + The /dev/guid entry will be a symlink to the "real" devfs device. + It is marked as "slave" of the real device, + to be automatically unregistered by devfs if that device is unregistered. + + If the partition already had a /dev/guid entry, delete (unregister) it. + (If the disk was repartitioned, it's likely the old GUID entry will be wrong). + + dev, minor: Device for which an entry is to be created. + + Prerequisites: dev->part[minor].guid must be either NULL or point + to a valid kmalloc'ed GUID. +*/ + +static void devfs_register_guid (struct gendisk *dev, int minor) +{ + efi_guid_t *guid = dev->part[minor].guid; + devfs_handle_t guid_handle, slave, + real_master = dev->part[minor].de; + devfs_handle_t master = real_master; + char guid_link[GUID_UNPARSED_LEN + 1]; + char dirname[128]; + int pos, st; + + if (!guid_top_handle) + guid_top_handle = devfs_mk_dir (NULL, "guid", NULL); + + if (!guid || !master) return; + + do { + slave = devfs_get_unregister_slave (master); + if (slave) { + if (slave == master || slave == real_master) { + printk (KERN_WARNING + "devfs_register_guid: infinite slave loop!\n"); + return; + } else if (devfs_get_parent (slave) == guid_top_handle) { + printk (KERN_INFO + "devfs_register_guid: unregistering %s\n", + devfs_get_name (slave, NULL)); + devfs_unregister_slave (master); + slave = NULL; + } else + master = slave; + }; + } while (slave); + + uuid_unparse_1 (guid, guid_link); + pos = devfs_generate_path (real_master, dirname + 3, + sizeof (dirname) - 3); + if (pos < 0) { + printk (KERN_WARNING + "devfs_register_guid: error generating path: %d\n", + pos); + return; + }; + + strncpy (dirname + pos, "../", 3); + + st = devfs_mk_symlink (guid_top_handle, guid_link, + DEVFS_FL_DEFAULT, + dirname + pos, &guid_handle, NULL); + + if (st < 0) { + printk ("Error %d creating symlink\n", st); + } else { + devfs_auto_unregister (master, guid_handle); + }; +}; + +/* + free_disk_guids: kfree all guid data structures alloced for + the disk device specified by (dev, minor) and all its partitions. + + This function does not remove symlinks in /dev/guid. +*/ +static void free_disk_guids (struct gendisk *dev, int minor) +{ + int i; + efi_guid_t *guid; + + for (i = 0; i < dev->max_p; i++) { + guid = dev->part[minor + i].guid; + if (!guid) continue; + kfree (guid); + dev->part[minor + i].guid = NULL; + }; +} + +#endif /* CONFIG_DEVFS_GUID */ + #ifdef CONFIG_DEVFS_FS static void devfs_register_partition (struct gendisk *dev, int minor, int part) { @@ -325,7 +436,11 @@ unsigned int devfs_flags = DEVFS_FL_DEFAULT; char devname[16]; - if (dev->part[minor + part].de) return; + /* Even if the devfs handle is still up-to-date, + the GUID entry probably isn't */ + if (dev->part[minor + part].de) + goto do_guid; + dir = devfs_get_parent (dev->part[minor].de); if (!dir) return; if ( dev->flags && (dev->flags[devnum] & GENHD_FL_REMOVABLE) ) @@ -336,6 +451,11 @@ dev->major, minor + part, S_IFBLK | S_IRUSR | S_IWUSR, dev->fops, NULL); + do_guid: +#ifdef CONFIG_DEVFS_GUID + devfs_register_guid (dev, minor + part); +#endif + return; } static void devfs_register_disc (struct gendisk *dev, int minor) @@ -348,7 +468,9 @@ static unsigned int disc_counter; static devfs_handle_t devfs_handle; - if (dev->part[minor].de) return; + if (dev->part[minor].de) + goto do_guid; + if ( dev->flags && (dev->flags[devnum] & GENHD_FL_REMOVABLE) ) devfs_flags |= DEVFS_FL_REMOVABLE; if (dev->de_arr) { @@ -375,6 +497,12 @@ devfs_auto_unregister (dev->part[minor].de, slave); if (!dev->de_arr) devfs_auto_unregister (slave, dir); + + do_guid: +#ifdef CONFIG_DEVFS_GUID + devfs_register_guid (dev, minor); +#endif + return; } #endif /* CONFIG_DEVFS_FS */ @@ -396,6 +524,7 @@ if (unregister) { devfs_unregister (dev->part[minor].de); dev->part[minor].de = NULL; + free_disk_guids (dev, minor); } #endif /* CONFIG_DEVFS_FS */ } @@ -413,8 +542,21 @@ void register_disk(struct gendisk *gdev, kdev_t dev, unsigned minors, struct block_device_operations *ops, long size) { + int i; + if (!gdev) return; + +#ifdef CONFIG_DEVFS_GUID + /* Initialize all guid fields to NULL (=^ not kmalloc'ed). + It is assumed that drivers call register_disk after + allocating the gen_hd structure, and call grok_partitions + directly for a revalidate event, as those drives I've inspected + (among which hd and sd) do. */ + for (i = 0; i < gdev->max_p; i++) + gdev->part[MINOR(dev) + i].guid = NULL; +#endif + grok_partitions(gdev, MINOR(dev)>>gdev->minor_shift, minors, size); } @@ -432,6 +574,13 @@ if (!size || minors == 1) return; +#ifdef CONFIG_DEVFS_GUID + /* In case this is a revalidation, free GUID memory. + On the first call for this device, + register_disk has set all entries to NULL, + and nothing will happen. */ + free_disk_guids (dev, first_minor); +#endif blk_size[dev->major] = NULL; check_partition(dev, MKDEV(dev->major, first_minor), 1 + first_minor); diff -ru -x *.o -x.* -x*.rej -x*~ linux-2.4.4-orig/fs/partitions/efi.c linux-2.4.4mw/fs/partitions/efi.c --- linux-2.4.4-orig/fs/partitions/efi.c Wed May 30 20:27:55 2001 +++ linux-2.4.4mw/fs/partitions/efi.c Wed May 30 20:11:12 2001 @@ -479,7 +479,31 @@ return 0; } +#ifdef CONFIG_DEVFS_GUID +/* set_partition_guid */ +/* Fill in the GUID field of the partition. + It is set to NULL by register_disk before. */ +static void set_partition_guid (struct gendisk *hd, + const int minor, + const efi_guid_t *guid) +{ + char guid_buf[GUID_UNPARSED_LEN + 1]; + efi_guid_t *part_guid = hd->part[minor].guid; + if (!guid || !hd) return; + + part_guid = kmalloc (sizeof (efi_guid_t), GFP_KERNEL); + + if (part_guid) { + memcpy (part_guid, guid, sizeof (efi_guid_t)); + } else { + printk (KERN_WARNING + "add_gpt_partitions: cannot allocate GUID memory!\n"); + }; + + hd->part[minor].guid = part_guid; +} +#endif /* CONFIG_DEVFS_GUID */ /* * Create devices for each entry in the GUID Partition Table Entries. @@ -516,6 +540,11 @@ } debug_printk(efi_printk_level "GUID Partition Table is valid! Yea!\n"); + +#ifdef CONFIG_DEVFS_GUID + set_partition_guid (hd, nextminor - 1, &(gpt->DiskGUID)); +#endif + for (i = 0; i < gpt->NumberOfPartitionEntries && nummade < (hd->max_p - 1); i++) { if (!efi_guidcmp(unusedGuid, ptes[i].PartitionTypeGuid)) @@ -523,6 +552,10 @@ add_gd_partition(hd, nextminor, ptes[i].StartingLBA, (ptes[i].EndingLBA-ptes[i].StartingLBA + 1)); + +#ifdef CONFIG_DEVFS_GUID + set_partition_guid (hd, nextminor, &(ptes[i].UniquePartitionGuid)); +#endif /* If there's this is a RAID volume, tell md */ #if CONFIG_BLK_DEV_MD && CONFIG_AUTODETECT_RAID diff -ru -x *.o -x.* -x*.rej -x*~ linux-2.4.4-orig/include/linux/devfs_fs_kernel.h linux-2.4.4mw/include/linux/devfs_fs_kernel.h --- linux-2.4.4-orig/include/linux/devfs_fs_kernel.h Wed May 30 20:27:55 2001 +++ linux-2.4.4mw/include/linux/devfs_fs_kernel.h Wed May 30 20:24:15 2001 @@ -81,6 +81,9 @@ extern devfs_handle_t devfs_get_next_sibling (devfs_handle_t de); extern void devfs_auto_unregister (devfs_handle_t master,devfs_handle_t slave); extern devfs_handle_t devfs_get_unregister_slave (devfs_handle_t master); +#ifdef CONFIG_DEVFS_GUID +extern void devfs_unregister_slave (devfs_handle_t master); +#endif extern const char *devfs_get_name (devfs_handle_t de, unsigned int *namelen); extern int devfs_register_chrdev (unsigned int major, const char *name, struct file_operations *fops); diff -ru -x *.o -x.* -x*.rej -x*~ linux-2.4.4-orig/include/linux/genhd.h linux-2.4.4mw/include/linux/genhd.h --- linux-2.4.4-orig/include/linux/genhd.h Wed May 30 20:27:55 2001 +++ linux-2.4.4mw/include/linux/genhd.h Wed May 30 18:26:02 2001 @@ -13,6 +13,10 @@ #include #include +#ifdef CONFIG_DEVFS_GUID +#include +#endif + /* These three have identical behaviour; use the second one if DOS fdisk gets confused about extended/logical partitions starting past cylinder 1023. */ #define DOS_EXTENDED_PARTITION 5 @@ -51,6 +55,9 @@ long start_sect; long nr_sects; devfs_handle_t de; /* primary (master) devfs entry */ +#ifdef CONFIG_DEVFS_GUID + efi_guid_t *guid; +#endif }; #define GENHD_FL_REMOVABLE 1 From owner-devfs@oss.sgi.com Thu May 31 10:41:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4VHfZN23366 for devfs-outgoing; Thu, 31 May 2001 10:41:35 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VHeuh23342 for ; Thu, 31 May 2001 10:40:56 -0700 Received: from energy.pdb.sbs.de (energy.pdb.sbs.de [192.109.2.19]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA06306 for ; Thu, 31 May 2001 10:40:50 -0700 (PDT) mail_from (Martin.Wilck@fujitsu-siemens.com) Received: from trulli.pdb.fsc.net ([172.25.96.20]) by energy.pdb.sbs.de (8.9.3/8.9.3) with ESMTP id TAA18870; Thu, 31 May 2001 19:39:39 +0200 Received: from biker.pdb.fsc.net (biker.pdb.fsc.net [172.25.187.106]) by trulli.pdb.fsc.net (8.9.3/8.9.3) with ESMTP id TAA29241; Thu, 31 May 2001 19:39:39 +0200 Received: from localhost (martin@localhost) by biker.pdb.fsc.net (8.11.0/8.11.0) with ESMTP id f4VHcVw24788; Thu, 31 May 2001 19:38:31 +0200 Date: Thu, 31 May 2001 19:38:31 +0200 (CEST) From: Martin Wilck To: "Leonard N. Zubkoff" , Richard Gooch cc: devfs mailing list , Richard Gooch , Tom Duffy , Martin Wilck Subject: [PATCH]: devfs & DAC960 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-devfs@oss.sgi.com Precedence: bulk Hello Leonard, Richard, all, in response to my inquiry about the current conflicts between devfs and the DAC960 driver, Richard told me he was too busy to go into this problem. So I took some time myself and made a patch that makes the DAC960 driver behave correctly with devfs. I got some guidance by the patch against 2.2.16 Tom Duffy sent me (thanks Tom!), but I basically rewrote the patch from scratch. The patch is against kernel 2.4.4 with IA64, it works with plain 2.4.4. I have made the patch a configurable option that appears below "/dev filesystem support". I have taken much care to make the DAC960 driver behave exactly the same as the original if this option is disabled. I also wrote a devfsd patch that brings up the /dev/rd/cXdYpZ devices again. Since it is certainly not my business to decide what the final device names should be, I have made these configurable through a set of macros in DAC960.h. An anologous macro (DAC960_BASE_DIR_NAME) appears also in the patch for devfsd. Also, I decided to make /proc file names configurable independently of the /dev file names, and in the current version of the patch left the /proc file names as they used to be with the DAC960 driver (in order not to break user space software that reads these /proc files). I hope sincerely that this will be a solid base for you to get devfs and the DAC960 driver in sync. Any suggestions and improvements are of course greatly appreciated. I am including the two patches in this e-mail. The devfsd patch (against 1.3.11) comes first. Cheers, Martin -- Martin Wilck FSC EP PS DS1, Paderborn Tel. +49 5251 8 15113 ******************* devfsd patch ************************** diff -ur -x *.o -x devfsd devfsd/devfsd.c devfsd.mw/devfsd.c --- devfsd/devfsd.c Tue Feb 6 07:13:19 2001 +++ devfsd.mw/devfsd.c Thu May 31 20:33:59 2001 @@ -203,6 +203,7 @@ #include #include "devfsd.h" #include "version.h" +#include #ifndef RTLD_DEFAULT /* Glibc 2.2 broke old code */ # define RTLD_DEFAULT RTLD_NEXT @@ -233,6 +234,8 @@ #define AC_RMOLDCOMPAT 9 #define AC_RMNEWCOMPAT 10 +#define DAC960_MINOR_SHIFT 3 +#define DAC960_BASE_DIR_NAME "dac960/" struct permissions_type { @@ -1340,6 +1343,19 @@ host, bus, target, lun, ptr + 2); else compat_name = NULL; } + else if (strncmp (info->devname, DAC960_BASE_DIR_NAME, + strlen (DAC960_BASE_DIR_NAME)) == 0) { + int ctrl = info->major - DAC960_MAJOR; + int disk = info->minor >> DAC960_MINOR_SHIFT; + int part = info->minor & ((1 << DAC960_MINOR_SHIFT) - 1); + sprintf (dest_buf, "../%s", info->devname); + dest_name = dest_buf; + if (!part) + sprintf (compat_buf, "rd/c%dd%d", ctrl, disk); + else + sprintf (compat_buf, "rd/c%dd%dp%d", ctrl, disk, part); + compat_name = compat_buf; + }; break; } if (compat_name == NULL) return; ********************** kernel patch ************************ --- linux-2.4.4-orig/fs/Config.in Wed May 30 17:37:00 2001 +++ linux-2.4.4mw/fs/Config.in Thu May 31 14:05:33 2001 @@ -49,6 +49,7 @@ dep_bool '/dev file system support (EXPERIMENTAL)' CONFIG_DEVFS_FS $CONFIG_EXPERIMENTAL dep_bool ' Automatically mount at boot' CONFIG_DEVFS_MOUNT $CONFIG_DEVFS_FS dep_bool ' Debug devfs' CONFIG_DEVFS_DEBUG $CONFIG_DEVFS_FS +dep_bool ' devfs support for Mylex DAC960/DAC1100 driver' CONFIG_DAC960_DEVFS $CONFIG_DEVFS_FS # It compiles as a module for testing only. It should not be used # as a module in general. If we make this "tristate", a bunch of people --- linux-2.4.4-orig/Documentation/Configure.help Wed May 30 20:31:31 2001 +++ linux-2.4.4mw/Documentation/Configure.help Thu May 31 14:02:43 2001 @@ -11565,6 +11565,15 @@ If unsure, say N. +devfs support for Mylex DAC960/DAC1100 driver +CONFIG_DAC960_DEVFS + This option will add devfs support to the Mylex DAC960/DAC1100 + PCI RAID driver. If you use this driver in a system configured + to use devfs, say Y. Otherwise, say N. + + The RAID devices on the Mylex controller(s) will then appear + under /dev/dac960/hostX/ for controller number X. + NFS file system support CONFIG_NFS_FS If you are connected to some other (usually local) Unix computer --- linux-2.4.4-orig/drivers/block/DAC960.c Wed Feb 21 06:26:22 2001 +++ linux-2.4.4mw/drivers/block/DAC960.c Thu May 31 19:48:20 2001 @@ -45,6 +45,13 @@ #include #include "DAC960.h" +#ifdef CONFIG_DAC960_DEVFS +/* + dac960_top_handle is the devfs handle for the top directory + with DAC960 entries (/dev/dac960) +*/ +static devfs_handle_t dac960_top_handle = NULL; +#endif /* DAC960_ControllerCount is the number of DAC960 Controllers detected. @@ -85,7 +92,8 @@ /* - DAC960_ProcDirectoryEntry is the DAC960 /proc/rd directory entry. + DAC960_ProcDirectoryEntry is the DAC960 /proc/[DAC960_PROC_DIR_NAME] + directory entry. */ static PROC_DirectoryEntry_T @@ -1613,7 +1621,8 @@ { DAC960_V1_LogicalDriveInformation_T *LogicalDriveInformation = &Controller->V1.LogicalDriveInformation[LogicalDriveNumber]; - DAC960_Info(" /dev/rd/c%dd%d: RAID-%d, %s, %d blocks, %s\n", + DAC960_Info(" /dev" DAC960_FORMAT + ": RAID-%d, %s, %d blocks, %s\n", Controller, Controller->ControllerNumber, LogicalDriveNumber, LogicalDriveInformation->RAIDLevel, (LogicalDriveInformation->LogicalDriveState @@ -1746,7 +1755,8 @@ Controller, LogicalDeviceInfo->DriveGeometry); break; } - DAC960_Info(" /dev/rd/c%dd%d: RAID-%d, %s, %d blocks\n", + DAC960_Info(" /dev" DAC960_FORMAT + ": RAID-%d, %s, %d blocks\n", Controller, Controller->ControllerNumber, LogicalDriveNumber, LogicalDeviceInfo->RAIDLevel, (LogicalDeviceInfo->LogicalDeviceState @@ -1884,6 +1894,13 @@ GenericDiskInfo_T *GenericDiskInfo; RequestQueue_T *RequestQueue; int MinorNumber; + +#ifdef CONFIG_DAC960_DEVFS + char DevfsName[sizeof (DAC960_HOST_NAME) + 1]; + char DiskName[sizeof (DAC960_DISK_NAME) + 2]; + int i; +#endif + /* Register the Block Device Major Number for this DAC960 Controller. */ @@ -1894,6 +1911,34 @@ Controller, MajorNumber); return false; } + +#ifdef CONFIG_DAC960_DEVFS + Controller->TopDevfsHandle = NULL; + sprintf (DevfsName, DAC960_HOST_NAME "%d", + Controller->ControllerNumber); + + if (!dac960_top_handle) { + dac960_top_handle = + devfs_mk_dir (NULL, DAC960_BASE_DIR_NAME, NULL); + if (!dac960_top_handle) { + DAC960_Error ("failed to create /dev" DAC960_BASE_DIR, + Controller); + return false; + }; + }; + + Controller->TopDevfsHandle = + devfs_mk_dir (dac960_top_handle, DevfsName, NULL); + + if (!Controller->TopDevfsHandle) { + DAC960_Error ("failed to create /dev" + DAC960_BASE_DIR DAC960_HOST_FORMAT"\n", + Controller, + Controller->ControllerNumber); + return false; + }; +#endif /* CONFIG_DAC960_DEVFS */ + /* Initialize the I/O Request Queue. */ @@ -1933,6 +1978,29 @@ Controller->GenericDiskInfo.nr_real = Controller->LogicalDriveCount; Controller->GenericDiskInfo.next = NULL; Controller->GenericDiskInfo.fops = &DAC960_BlockDeviceOperations; + +#ifdef CONFIG_DAC960_DEVFS + for (i = 0; i < DAC960_MaxLogicalDrives; i++) { + Controller->DevfsHandles[i] = NULL; + Controller->DevfsFlags[i] = DEVFS_FL_NONE; + }; + + /* Create devfs handles only for existing logical disks (??) */ + for (i = 0; i < Controller->LogicalDriveCount; i++) { + sprintf (DiskName, DAC960_DISK_NAME "%d", i); + Controller->DevfsHandles[i] = + devfs_mk_dir (Controller->TopDevfsHandle, DiskName, NULL); + if (!Controller->DevfsHandles[i]) { + DAC960_Error ("cannot create /dev" DAC960_FORMAT "\n", + Controller, Controller->ControllerNumber, i); + return false; + }; + }; + + Controller->GenericDiskInfo.de_arr = Controller->DevfsHandles; + Controller->GenericDiskInfo.flags = Controller->DevfsFlags; +#endif + /* Install the Generic Disk Information structure at the end of the list. */ @@ -1958,10 +2026,20 @@ static void DAC960_UnregisterBlockDevice(DAC960_Controller_T *Controller) { int MajorNumber = DAC960_MAJOR + Controller->ControllerNumber; + /* Unregister the Block Device Major Number for this DAC960 Controller. */ devfs_unregister_blkdev(MajorNumber, "dac960"); + +#ifdef CONFIG_DAC960_DEVFS + /* + Unregister the devfs handle for this controller. + */ + if (Controller->TopDevfsHandle) + devfs_unregister (Controller->TopDevfsHandle); +#endif + /* Remove the I/O Request Queue. */ @@ -2879,12 +2957,14 @@ Controller, Command->V1.CommandStatus, CommandName); break; } - DAC960_Error(" /dev/rd/c%dd%d: absolute blocks %d..%d\n", + DAC960_Error(" /dev" DAC960_FORMAT + ": absolute blocks %d..%d\n", Controller, Controller->ControllerNumber, Command->LogicalDriveNumber, Command->BlockNumber, Command->BlockNumber + Command->BlockCount - 1); if (DAC960_PartitionNumber(Command->BufferHeader->b_rdev) > 0) - DAC960_Error(" /dev/rd/c%dd%dp%d: relative blocks %d..%d\n", + DAC960_Error(" /dev" DAC960_FORMAT + ": relative blocks %d..%d\n", Controller, Controller->ControllerNumber, Command->LogicalDriveNumber, DAC960_PartitionNumber(Command->BufferHeader->b_rdev), @@ -3042,7 +3122,8 @@ { int LogicalDriveNumber = Controller->LogicalDriveCount - 1; while (++LogicalDriveNumber < NewEnquiry->NumberOfLogicalDrives) - DAC960_Critical("Logical Drive %d (/dev/rd/c%dd%d) " + DAC960_Critical("Logical Drive %d (/dev" + DAC960_FORMAT ") " "Now Exists\n", Controller, LogicalDriveNumber, Controller->ControllerNumber, @@ -3052,7 +3133,8 @@ { int LogicalDriveNumber = NewEnquiry->NumberOfLogicalDrives - 1; while (++LogicalDriveNumber < Controller->LogicalDriveCount) - DAC960_Critical("Logical Drive %d (/dev/rd/c%dd%d) " + DAC960_Critical("Logical Drive %d (/dev" + DAC960_FORMAT ") " "No Longer Exists\n", Controller, LogicalDriveNumber, Controller->ControllerNumber, @@ -3308,7 +3390,8 @@ &Controller->V1.NewLogicalDriveInformation[LogicalDriveNumber]; if (NewLogicalDriveInformation->LogicalDriveState != OldLogicalDriveInformation->LogicalDriveState) - DAC960_Critical("Logical Drive %d (/dev/rd/c%dd%d) " + DAC960_Critical("Logical Drive %d (/dev" + DAC960_FORMAT ") " "is now %s\n", Controller, LogicalDriveNumber, Controller->ControllerNumber, @@ -3321,7 +3404,8 @@ ? "CRITICAL" : "OFFLINE")); if (NewLogicalDriveInformation->WriteBack != OldLogicalDriveInformation->WriteBack) - DAC960_Critical("Logical Drive %d (/dev/rd/c%dd%d) " + DAC960_Critical("Logical Drive %d (/dev" + DAC960_FORMAT ") " "is now %s\n", Controller, LogicalDriveNumber, Controller->ControllerNumber, @@ -3349,7 +3433,8 @@ case DAC960_V1_NormalCompletion: Controller->EphemeralProgressMessage = true; DAC960_Progress("Rebuild in Progress: " - "Logical Drive %d (/dev/rd/c%dd%d) " + "Logical Drive %d (/dev" + DAC960_FORMAT ") " "%d%% completed\n", Controller, LogicalDriveNumber, Controller->ControllerNumber, @@ -3406,7 +3491,8 @@ { Controller->EphemeralProgressMessage = true; DAC960_Progress("Consistency Check in Progress: " - "Logical Drive %d (/dev/rd/c%dd%d) " + "Logical Drive %d (/dev" + DAC960_FORMAT ") " "%d%% completed\n", Controller, LogicalDriveNumber, Controller->ControllerNumber, @@ -3662,12 +3748,14 @@ } DAC960_Error("Error Condition %s on %s:\n", Controller, SenseErrors[Command->V2.RequestSense.SenseKey], CommandName); - DAC960_Error(" /dev/rd/c%dd%d: absolute blocks %d..%d\n", + DAC960_Error(" /dev" DAC960_FORMAT + ": absolute blocks %d..%d\n", Controller, Controller->ControllerNumber, Command->LogicalDriveNumber, Command->BlockNumber, Command->BlockNumber + Command->BlockCount - 1); if (DAC960_PartitionNumber(Command->BufferHeader->b_rdev) > 0) - DAC960_Error(" /dev/rd/c%dd%dp%d: relative blocks %d..%d\n", + DAC960_Error(" /dev" DAC960_FORMAT + ": relative blocks %d..%d\n", Controller, Controller->ControllerNumber, Command->LogicalDriveNumber, DAC960_PartitionNumber(Command->BufferHeader->b_rdev), @@ -3822,12 +3910,15 @@ Event->Channel, Event->TargetID, EventMessage); break; case 'L': - DAC960_Critical("Logical Drive %d (/dev/rd/c%dd%d) %s\n", Controller, + DAC960_Critical("Logical Drive %d (/dev" + DAC960_FORMAT ") %s\n", Controller, Event->LogicalUnit, Controller->ControllerNumber, Event->LogicalUnit, EventMessage); break; case 'M': - DAC960_Progress("Logical Drive %d (/dev/rd/c%dd%d) %s\n", Controller, + DAC960_Progress("Logical Drive %d (/dev" + DAC960_FORMAT + ") %s\n", Controller, Event->LogicalUnit, Controller->ControllerNumber, Event->LogicalUnit, EventMessage); break; @@ -3892,7 +3983,8 @@ unsigned long LogicalDeviceSize) { Controller->EphemeralProgressMessage = true; - DAC960_Progress("%s in Progress: Logical Drive %d (/dev/rd/c%dd%d) " + DAC960_Progress("%s in Progress: Logical Drive %d (/dev" + DAC960_FORMAT ") " "%d%% completed\n", Controller, MessageString, LogicalDeviceNumber, @@ -4281,7 +4373,8 @@ kmalloc(sizeof(DAC960_V2_LogicalDeviceInfo_T), GFP_ATOMIC); Controller->V2.LogicalDeviceInformation[LogicalDeviceNumber] = LogicalDeviceInfo; - DAC960_Critical("Logical Drive %d (/dev/rd/c%dd%d) " + DAC960_Critical("Logical Drive %d (/dev" + DAC960_FORMAT ") " "Now Exists%s\n", Controller, LogicalDeviceNumber, Controller->ControllerNumber, @@ -4298,7 +4391,8 @@ NewLogicalDeviceInfo->ConfigurableDeviceSizeIn512ByteBlocksOrMB; if (NewLogicalDeviceInfo->LogicalDeviceState != LogicalDeviceInfo->LogicalDeviceState) - DAC960_Critical("Logical Drive %d (/dev/rd/c%dd%d) " + DAC960_Critical("Logical Drive %d (/dev" + DAC960_FORMAT ") " "is now %s\n", Controller, LogicalDeviceNumber, Controller->ControllerNumber, @@ -4315,7 +4409,8 @@ LogicalDeviceInfo->CommandsFailed) || (NewLogicalDeviceInfo->DeferredWriteErrors != LogicalDeviceInfo->DeferredWriteErrors)) - DAC960_Critical("Logical Drive %d (/dev/rd/c%dd%d) Errors: " + DAC960_Critical("Logical Drive %d (/dev" + DAC960_FORMAT ") Errors: " "Soft = %d, Failed = %d, Deferred Write = %d\n", Controller, LogicalDeviceNumber, Controller->ControllerNumber, @@ -4367,7 +4462,8 @@ LogicalDeviceSize); if (LogicalDeviceInfo->BackgroundInitializationInProgress && !NewLogicalDeviceInfo->BackgroundInitializationInProgress) - DAC960_Progress("Logical Drive %d (/dev/rd/c%dd%d) " + DAC960_Progress("Logical Drive %d (/dev" + DAC960_FORMAT ") " "Background Initialization %s\n", Controller, LogicalDeviceNumber, @@ -4396,7 +4492,8 @@ Controller->V2.LogicalDriveFoundDuringScan [LogicalDriveNumber]) continue; - DAC960_Critical("Logical Drive %d (/dev/rd/c%dd%d) " + DAC960_Critical("Logical Drive %d (/dev" + DAC960_FORMAT ") " "No Longer Exists\n", Controller, LogicalDriveNumber, Controller->ControllerNumber, @@ -6126,14 +6223,14 @@ { case DAC960_V1_NormalCompletion: DAC960_UserCritical("Consistency Check of Logical Drive %d " - "(/dev/rd/c%dd%d) Initiated\n", + "(/dev" DAC960_FORMAT ") Initiated\n", Controller, LogicalDriveNumber, Controller->ControllerNumber, LogicalDriveNumber); break; case DAC960_V1_DependentDiskIsDead: DAC960_UserCritical("Consistency Check of Logical Drive %d " - "(/dev/rd/c%dd%d) Failed - " + "(/dev" DAC960_FORMAT ") Failed - " "Dependent Physical Device is DEAD\n", Controller, LogicalDriveNumber, Controller->ControllerNumber, @@ -6141,7 +6238,7 @@ break; case DAC960_V1_InvalidOrNonredundantLogicalDrive: DAC960_UserCritical("Consistency Check of Logical Drive %d " - "(/dev/rd/c%dd%d) Failed - " + "(/dev" DAC960_FORMAT ") Failed - " "Invalid or Nonredundant Logical Drive\n", Controller, LogicalDriveNumber, Controller->ControllerNumber, @@ -6149,7 +6246,7 @@ break; case DAC960_V1_RebuildOrCheckAlreadyInProgress: DAC960_UserCritical("Consistency Check of Logical Drive %d " - "(/dev/rd/c%dd%d) Failed - Rebuild or " + "(/dev" DAC960_FORMAT ") Failed - Rebuild or " "Consistency Check Already in Progress\n", Controller, LogicalDriveNumber, Controller->ControllerNumber, @@ -6157,7 +6254,7 @@ break; default: DAC960_UserCritical("Consistency Check of Logical Drive %d " - "(/dev/rd/c%dd%d) Failed - " + "(/dev" DAC960_FORMAT ") Failed - " "Unexpected Status %04X\n", Controller, LogicalDriveNumber, Controller->ControllerNumber, @@ -6376,7 +6473,7 @@ CommandMailbox->ConsistencyCheck.InitializedAreaOnly = false; DAC960_ExecuteCommand(Command); DAC960_UserCritical("Consistency Check of Logical Drive %d " - "(/dev/rd/c%dd%d) %s\n", + "(/dev" DAC960_FORMAT ") %s\n", Controller, LogicalDriveNumber, Controller->ControllerNumber, LogicalDriveNumber, @@ -6394,7 +6491,7 @@ DAC960_V2_ConsistencyCheckStop; DAC960_ExecuteCommand(Command); DAC960_UserCritical("Consistency Check of Logical Drive %d " - "(/dev/rd/c%dd%d) %s\n", + "(/dev" DAC960_FORMAT ") %s\n", Controller, LogicalDriveNumber, Controller->ControllerNumber, LogicalDriveNumber, @@ -6414,7 +6511,7 @@ /* - DAC960_ProcReadStatus implements reading /proc/rd/status. + DAC960_ProcReadStatus implements reading /proc/[DAC960_PROC_DIR_NAME]/status. */ static int DAC960_ProcReadStatus(char *Page, char **Start, off_t Offset, @@ -6448,7 +6545,8 @@ /* - DAC960_ProcReadInitialStatus implements reading /proc/rd/cN/initial_status. + DAC960_ProcReadInitialStatus implements reading + /proc/[DAC960_PROC_DIR_NAME]/[DAC960_HOST_NAME]N/initial_status. */ static int DAC960_ProcReadInitialStatus(char *Page, char **Start, off_t Offset, @@ -6469,7 +6567,8 @@ /* - DAC960_ProcReadCurrentStatus implements reading /proc/rd/cN/current_status. + DAC960_ProcReadCurrentStatus implements reading + /proc/[DAC960_PROC_DIR_NAME]/[DAC960_HOST_NAME]N/current_status. */ static int DAC960_ProcReadCurrentStatus(char *Page, char **Start, off_t Offset, @@ -6517,7 +6616,8 @@ /* - DAC960_ProcReadUserCommand implements reading /proc/rd/cN/user_command. + DAC960_ProcReadUserCommand implements reading + /proc/[DAC960_PROC_DIR_NAME]/[DAC960_HOST_NAME]N/user_command. */ static int DAC960_ProcReadUserCommand(char *Page, char **Start, off_t Offset, @@ -6538,7 +6638,8 @@ /* - DAC960_ProcWriteUserCommand implements writing /proc/rd/cN/user_command. + DAC960_ProcWriteUserCommand implements writing + /proc/[DAC960_PROC_DIR_NAME]/[DAC960_HOST_NAME]N/user_command. */ static int DAC960_ProcWriteUserCommand(File_T *File, const char *Buffer, @@ -6563,15 +6664,15 @@ /* - DAC960_CreateProcEntries creates the /proc/rd/... entries for the - DAC960 Driver. + DAC960_CreateProcEntries creates the /proc/[DAC960_PROC_DIR_NAME]/... + entries for the DAC960 Driver. */ static void DAC960_CreateProcEntries(void) { PROC_DirectoryEntry_T *StatusProcEntry; int ControllerNumber; - DAC960_ProcDirectoryEntry = proc_mkdir("rd", NULL); + DAC960_ProcDirectoryEntry = proc_mkdir(DAC960_PROC_DIR_NAME, NULL); StatusProcEntry = create_proc_read_entry("status", 0, DAC960_ProcDirectoryEntry, DAC960_ProcReadStatus, NULL); @@ -6583,7 +6684,8 @@ PROC_DirectoryEntry_T *ControllerProcEntry; PROC_DirectoryEntry_T *UserCommandProcEntry; if (Controller == NULL) continue; - sprintf(Controller->ControllerName, "c%d", Controller->ControllerNumber); + sprintf(Controller->ControllerName, DAC960_PROC_HOST_NAME "%d", + Controller->ControllerNumber); ControllerProcEntry = proc_mkdir(Controller->ControllerName, DAC960_ProcDirectoryEntry); create_proc_read_entry("initial_status", 0, ControllerProcEntry, @@ -6619,8 +6721,8 @@ remove_proc_entry("user_command", Controller->ControllerProcEntry); remove_proc_entry(Controller->ControllerName, DAC960_ProcDirectoryEntry); } - remove_proc_entry("rd/status", NULL); - remove_proc_entry("rd", NULL); + remove_proc_entry(DAC960_PROC_DIR_NAME "/status", NULL); + remove_proc_entry(DAC960_PROC_DIR_NAME, NULL); } --- linux-2.4.4-orig/drivers/block/DAC960.h Wed Feb 21 06:26:22 2001 +++ linux-2.4.4mw/drivers/block/DAC960.h Thu May 31 20:42:39 2001 @@ -60,6 +60,33 @@ #define DAC960_V1_MaxPhysicalDevices 45 #define DAC960_V2_MaxPhysicalDevices 272 +/* + Names and format strings for /proc and /dev (with devfs) entries. + */ +#define DAC960_DRIVER_NAME "dac960" +#ifdef CONFIG_DAC960_DEVFS +# define DAC960_BASE_DIR_NAME "dac960" /* base dir in /dev */ +# define DAC960_PROC_DIR_NAME "rd" /* base dir in /proc */ +# define DAC960_MAJOR_NAME "rd" /* major_name of gendisk */ +# define DAC960_BASE_DIR "/" DAC960_BASE_DIR_NAME +# define DAC960_HOST_NAME "host" /* base name of controller ID in /dev */ +# define DAC960_PROC_HOST_NAME "c" /* the same in /proc */ +# define DAC960_HOST_FORMAT "/" DAC960_HOST_NAME "%d" +# define DAC960_DISK_NAME "disc" /* base name of disk ID in /dev */ +# define DAC960_DISK_FORMAT "/" DAC960_DISK_NAME "%d" +#else +# define DAC960_BASE_DIR_NAME "rd" +# define DAC960_PROC_DIR_NAME "rd" +# define DAC960_MAJOR_NAME "rd" +# define DAC960_BASE_DIR "/" DAC960_BASE_DIR_NAME +# define DAC960_HOST_NAME "c" +# define DAC960_PROC_HOST_NAME "c" +# define DAC960_HOST_FORMAT "/" DAC960_HOST_NAME "%d" +# define DAC960_DISK_NAME "d" +# define DAC960_DISK_FORMAT DAC960_DISK_NAME "%d" +#endif +#define DAC960_FORMAT \ + DAC960_BASE_DIR DAC960_HOST_FORMAT DAC960_DISK_FORMAT /* Define a Boolean data type. @@ -2268,7 +2295,7 @@ DAC960_IO_Address_T IO_Address; DAC960_PCI_Address_T PCI_Address; unsigned char ControllerNumber; - unsigned char ControllerName[4]; + unsigned char ControllerName[sizeof (DAC960_PROC_HOST_NAME) + 2]; unsigned char ModelName[20]; unsigned char FullModelName[28]; unsigned char FirmwareVersion[12]; @@ -2415,6 +2442,11 @@ int PartitionSizes[DAC960_MinorCount]; int BlockSizes[DAC960_MinorCount]; int MaxSectorsPerRequest[DAC960_MinorCount]; +#ifdef CONFIG_DAC960_DEVFS + devfs_handle_t TopDevfsHandle; + devfs_handle_t DevfsHandles[DAC960_MaxLogicalDrives]; + char DevfsFlags[DAC960_MaxLogicalDrives]; +#endif unsigned char ProgressBuffer[DAC960_ProgressBufferSize]; unsigned char UserStatusBuffer[DAC960_UserMessageSize]; }