From owner-devfs@oss.sgi.com Tue Oct 2 10:07:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f92H7LT20250 for devfs-outgoing; Tue, 2 Oct 2001 10:07:21 -0700 Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f92H7ID20246 for ; Tue, 2 Oct 2001 10:07:18 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id f92H3Ki07831; Tue, 2 Oct 2001 11:03:20 -0600 Date: Tue, 2 Oct 2001 11:03:20 -0600 Message-Id: <200110021703.f92H3Ki07831@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: linux-kernel@vger.kernel.org, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: [PATCH] devfs v193 available Sender: owner-devfs@oss.sgi.com Precedence: bulk Hi, all. Version 193 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.10. Highlights of this release: - Went back to global rwsem for symlinks (refcount scheme no good) Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Mon Oct 8 23:04:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9964Su05390 for devfs-outgoing; Mon, 8 Oct 2001 23:04:28 -0700 Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9964ND05386 for ; Mon, 8 Oct 2001 23:04:23 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id f99644D23291; Tue, 9 Oct 2001 00:04:04 -0600 Date: Tue, 9 Oct 2001 00:04:04 -0600 Message-Id: <200110090604.f99644D23291@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: linux-kernel@vger.kernel.org, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: [PATCH] devfs v194 available Sender: owner-devfs@oss.sgi.com Precedence: bulk Hi, all. Version 194 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.11-pre6. Highlights of this release: - Fixed overrun in by removing function (not needed) - Updated README from master HTML file Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Tue Oct 9 09:04:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f99G48W18971 for devfs-outgoing; Tue, 9 Oct 2001 09:04:08 -0700 Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f99G42D18967 for ; Tue, 9 Oct 2001 09:04:02 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id f99G32o28831; Tue, 9 Oct 2001 10:03:02 -0600 Date: Tue, 9 Oct 2001 10:03:02 -0600 Message-Id: <200110091603.f99G32o28831@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Alexander Viro Cc: linux-kernel@vger.kernel.org, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: Re: [PATCH] devfs v194 available In-Reply-To: References: <200110090604.f99644D23291@vindaloo.ras.ucalgary.ca> Sender: owner-devfs@oss.sgi.com Precedence: bulk Alexander Viro writes: > ... doesn't fix _under_run in try_modload() (see what happens if > namelen is 255 and parent is devfs root) What underrun? How can this be a problem? Before I use pos, I have the following check: if (namelen >= STRING_LENGTH) return -ENAMETOOLONG; so the maximum value that namelen can be is STRING_LENGTH-1. Thus we have: pos = STRING_LENGTH - (STRING_LENGTH - 1) - 1; -> pos = 0; > ... doesn't fix the deadlock introduced into -pre6 in place of symlink > races. That > > /* Need to follow the link: this is a stack chomper */ > down_read (&symlink_rwsem); > retval = curr->registered ? > search_for_entry (parent, curr->u.symlink.linkname, > curr->u.symlink.length, FALSE, FALSE, NULL, > TRUE) : NULL; > up_read (&symlink_rwsem); > > is a fairly bad idea. Think what happens if somebody else tries to > acquire symlink_rwsem for write between two calls of down_read() in > that recursion. Where is the problem? After the first call to down_read(), anyone calling down_write() will block, which is fine. Then the second call to down_read() should still work, right? Once the recursion unwinds, the semaphore will be released and whoever is waiting on down_write() will unblock. There should be no code paths where there is recursion between down_read() and down_write() (otherwise we *would* have a deadlock). Ah, shit. I just checked the rwsem implementation. It seems that once we do a down_write() (even if that blocks because someone else has a down_read() already), subsequent down_read() calls will block until the writer is granted access and then does up_write(). Damn. It would have been good for this to be documented somewhere. Those are the kinds of traps that should be mentioned in the header file. OK: is there a variant of rwsem which is "unfair" (i.e. readers can starve writers indefinately)? Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Tue Oct 9 10:12:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f99HCc319803 for devfs-outgoing; Tue, 9 Oct 2001 10:12:38 -0700 Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f99HCYD19800 for ; Tue, 9 Oct 2001 10:12:34 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id f99HBoe30168; Tue, 9 Oct 2001 11:11:50 -0600 Date: Tue, 9 Oct 2001 11:11:50 -0600 Message-Id: <200110091711.f99HBoe30168@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: linux-kernel@vger.kernel.org, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: [PATCH] devfs v195 available Sender: owner-devfs@oss.sgi.com Precedence: bulk Hi, all. Version 195 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.11-pre6. Highlights of this release: - Fixed buffer underrun in - Moved down_read() from to Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Sat Oct 13 15:58:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9DMwK921432 for devfs-outgoing; Sat, 13 Oct 2001 15:58:20 -0700 Received: from VL-MS-MR003.sc1.videotron.ca (relais.videotron.ca [24.201.245.36]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9DMwFD21428 for ; Sat, 13 Oct 2001 15:58:15 -0700 Received: from cthulhu.gerg.ca ([24.201.33.127]) by VL-MS-MR003.sc1.videotron.ca (Netscape Messaging Server 4.15 MR003 Jul 24 2001 16:23:26) with ESMTP id GL62H202.3JL for ; Sat, 13 Oct 2001 18:58:14 -0400 Received: from greg by cthulhu.gerg.ca with local (Exim 3.32 #1 (Debian)) id 15sXjS-0000Lx-00 for ; Sat, 13 Oct 2001 18:58:14 -0400 Date: Sat, 13 Oct 2001 18:58:14 -0400 From: Greg Ward To: devfs@oss.sgi.com Subject: Regex question Message-ID: <20011013185814.A1334@cthulhu.mems-exchange.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.22i Sender: owner-devfs@oss.sgi.com Precedence: bulk I'm a little unclear on the regex syntax used in devfsd.conf. Or rather, parentheses don't seem to be working for me, and I'm not sure if it's my thick-headedness, inadequated docs, a real honest-to-goodness bug. Here's what I'm trying to do: whenever a "scsi/.*/cd" device is registered, change the corresponding "generic" device to group "cdrom", group writeable. I would have *thought* that this would do the trick: REGISTER ^(scsi/.*/)cd$ EXECUTE chgrp cdrom \1/generic REGISTER ^(scsi/.*/)cd$ EXECUTE chmod 660 \1/generic In fact, the Debian packaging of devfsd ships with an /etc/devfs/perms that does basically this. But it doesn't work. As near as I can work out, that pattern is simply never matched. In fact, every pattern with parens in it has never matched for me. I tried doing this instead: REGISTER ^\(scsi/.*/\)cd$ EXECUTE chgrp cdrom \1/generic with the same result, ie. nothing. But if I change it to this: REGISTER ^scsi/host1/.*/cd$ EXECUTE chgrp cdrom scsi/host1/bus0/target0/lun0/generic REGISTER ^scsi/host1/.*/cd$ EXECUTE chmod 660 scsi/host1/bus0/target0/lun0/generic ...it works fine. That's gross, because it assumes my "SCSI" CD-ROM (actually an IDE drive that is occasionally under the control of ide-scsi) is always in the same place. I don't like assumptions like that -- they seem counter to the spirit of devfs. Can someone tell me what the heck is wrong with my regexes-with-parens above? This is with kernel 2.4.12 and/or 2.4.10 (I've been bouncing back and forth, I can't remember exactly what happened under which kernel). Debian "woody", devfsd 1.3.18-3. Thanks -- Greg -- Greg Ward - geek gward@python.net http://starship.python.net/~gward/ A day without sunshine is like night. From owner-devfs@oss.sgi.com Sun Oct 14 05:42:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ECgTa08416 for devfs-outgoing; Sun, 14 Oct 2001 05:42:29 -0700 Received: from tsv.sws.net.au (tsv.sws.net.au [203.36.46.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ECgND08413 for ; Sun, 14 Oct 2001 05:42:24 -0700 Received: from lyta.coker.com.au (localhost [127.0.0.1]) by tsv.sws.net.au (Postfix) with ESMTP id 51E0D92600; Sun, 14 Oct 2001 22:42:16 +1000 (EST) Received: from there (lyta [127.0.0.1]) by lyta.coker.com.au (Postfix) with SMTP id 01F0834CF7; Sun, 14 Oct 2001 14:42:59 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: Russell Coker Reply-To: Russell Coker To: Greg Ward , devfs@oss.sgi.com Subject: Re: Regex question - maybe devfsd should use REG_EXTENDED Date: Sun, 14 Oct 2001 13:37:00 +0200 X-Mailer: KMail [version 1.3.1] References: <20011013185814.A1334@cthulhu.mems-exchange.org> In-Reply-To: <20011013185814.A1334@cthulhu.mems-exchange.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20011014124259.01F0834CF7@lyta.coker.com.au> Sender: owner-devfs@oss.sgi.com Precedence: bulk On Sun, 14 Oct 2001 00:58, Greg Ward wrote: > I'm a little unclear on the regex syntax used in devfsd.conf. Or > rather, parentheses don't seem to be working for me, and I'm not sure if > it's my thick-headedness, inadequated docs, a real honest-to-goodness > bug. > > Here's what I'm trying to do: whenever a "scsi/.*/cd" device is > registered, change the corresponding "generic" device to group "cdrom", > group writeable. I would have *thought* that this would do the trick: > > REGISTER ^(scsi/.*/)cd$ EXECUTE chgrp cdrom \1/generic > REGISTER ^(scsi/.*/)cd$ EXECUTE chmod 660 \1/generic > > In fact, the Debian packaging of devfsd ships with an /etc/devfs/perms > that does basically this. That was a mistake, I don't think I ever uploaded that version to Debian, I hope that was only a test version. Devfsd only uses basic regular expressions. I have been thinking of enabling extended regex compilation, but have been hesitant to allow Debian users to create config files that won't work anywhere else... > REGISTER ^scsi/host1/.*/cd$ EXECUTE chgrp cdrom > scsi/host1/bus0/target0/lun0/generic REGISTER ^scsi/host1/.*/cd$ EXECUTE > chmod 660 scsi/host1/bus0/target0/lun0/generic > > ...it works fine. That's gross, because it assumes my "SCSI" CD-ROM > (actually an IDE drive that is occasionally under the control of > ide-scsi) is always in the same place. I don't like assumptions like > that -- they seem counter to the spirit of devfs. You could use the following (default for the next Debian package): REGISTER ^ide/.*/cd$ PERMISSIONS root.cdrom 0660 REGISTER ^scsi/.*/cd$ PERMISSIONS root.cdrom 0660 REGISTER ^ide/.*/disc$ PERMISSIONS root.disk 0660 REGISTER ^ide/.*/part[0-9]*$ PERMISSIONS root.disk 0660 REGISTER ^scsi/.*/disc$ PERMISSIONS root.disk 0660 REGISTER ^scsi/.*/part[0-9]*$ PERMISSIONS root.disk 0660 REGISTER ^cciss/.* PERMISSIONS root.disk 0660 > Can someone tell me what the heck is wrong with my regexes-with-parens > above? This is with kernel 2.4.12 and/or 2.4.10 (I've been bouncing > back and forth, I can't remember exactly what happened under which > kernel). Debian "woody", devfsd 1.3.18-3. Kernel version doesn't matter for these things (as long as the kernel isn't inherantly buggy in this regard). -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page From owner-devfs@oss.sgi.com Sun Oct 14 12:34:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9EJYWP15203 for devfs-outgoing; Sun, 14 Oct 2001 12:34:32 -0700 Received: from VL-MS-MR004.sc1.videotron.ca (relais.videotron.ca [24.201.245.36]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9EJYPD15200 for ; Sun, 14 Oct 2001 12:34:25 -0700 Received: from cthulhu.gerg.ca ([24.201.33.127]) by VL-MS-MR004.sc1.videotron.ca (Netscape Messaging Server 4.15) with ESMTP id GL7NPC02.DO7; Sun, 14 Oct 2001 15:34:24 -0400 Received: from greg by cthulhu.gerg.ca with local (Exim 3.32 #1 (Debian)) id 15sr1k-0000Kc-00; Sun, 14 Oct 2001 15:34:24 -0400 Date: Sun, 14 Oct 2001 15:34:24 -0400 From: Greg Ward To: Russell Coker Cc: devfs@oss.sgi.com Subject: Re: Regex question - maybe devfsd should use REG_EXTENDED Message-ID: <20011014153424.C954@cthulhu.mems-exchange.org> References: <20011013185814.A1334@cthulhu.mems-exchange.org> <20011014124259.01F0834CF7@lyta.coker.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011014124259.01F0834CF7@lyta.coker.com.au> User-Agent: Mutt/1.3.22i Sender: owner-devfs@oss.sgi.com Precedence: bulk On 14 October 2001, Russell Coker said: > > REGISTER ^(scsi/.*/)cd$ EXECUTE chgrp cdrom \1/generic > > REGISTER ^(scsi/.*/)cd$ EXECUTE chmod 660 \1/generic > > > > In fact, the Debian packaging of devfsd ships with an /etc/devfs/perms > > that does basically this. > > That was a mistake, I don't think I ever uploaded that version to Debian, I > hope that was only a test version. I hope you mean "tweaking the permssions of CD-ROM generic devices" was a mistake, not "having /etc/devfsd/devfs.conf include perms". The perms file is a great idea! Anyways, I'm pretty sure the devfsd 1.3.18-3 package did include a perms file that tweaked the "generic" permissions whenever a "cd" device was registered. Seems like a good idea to me, although maybe not one that should be in Debian installation by default. > Devfsd only uses basic regular expressions. I have been thinking of > enabling extended regex compilation, but have been hesitant to allow > Debian users to create config files that won't work anywhere else... But the devfsd man page says: REGULAR EXPRESSION SUBSTITUTION Sections of the matched regular expression can be included in an action. Use \0 to refer to the entire regular expression matched, \1 to refer to the first parenthesized subexpression, \2 to refer to the second, and so on. (Use \\ to include an actual backslash.) ...which I take to mean that REGISTER ^foo.*bar$ EXECUTE chown luser $devname is exactly equivalent to all three of the following: REGISTER ^(foo.*bar)$ EXECUTE chown luser $devname REGISTER ^(foo.*bar)$ EXECUTE chown luser \0 REGISTER ^(foo.*bar)$ EXECUTE chown luser \1 Is this true or not? As near as I can tell, the real rule is: any regular expression with parentheses in it fails. > You could use the following (default for the next Debian package): > REGISTER ^ide/.*/cd$ PERMISSIONS root.cdrom 0660 > REGISTER ^scsi/.*/cd$ PERMISSIONS root.cdrom 0660 > REGISTER ^ide/.*/disc$ PERMISSIONS root.disk 0660 > REGISTER ^ide/.*/part[0-9]*$ PERMISSIONS root.disk 0660 > REGISTER ^scsi/.*/disc$ PERMISSIONS root.disk 0660 > REGISTER ^scsi/.*/part[0-9]*$ PERMISSIONS root.disk 0660 > REGISTER ^cciss/.* PERMISSIONS root.disk 0660 But that doesn't do anything about the "generic" device that's created alongside the "cd" device, does it? What I want is this: whenever a "scsi/.*/cd" device is registered, set the permissions of the "generic" device in the same file to "root.cdrom 0660". I don't see a clean way to do this without having regexes that support paren matching, just like the devfsd man page says they do. Greg -- Greg Ward - programmer-at-large gward@python.net http://starship.python.net/~gward/ Support bacteria -- it's the only culture some people have! From owner-devfs@oss.sgi.com Sun Oct 14 16:38:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ENcbR19506 for devfs-outgoing; Sun, 14 Oct 2001 16:38:37 -0700 Received: from tsv.sws.net.au (tsv.sws.net.au [203.36.46.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ENcRD19502 for ; Sun, 14 Oct 2001 16:38:28 -0700 Received: from lyta.coker.com.au (localhost [127.0.0.1]) by tsv.sws.net.au (Postfix) with ESMTP id E9B2792600; Mon, 15 Oct 2001 09:38:23 +1000 (EST) Received: from there (lyta [127.0.0.1]) by lyta.coker.com.au (Postfix) with SMTP id B405732889F; Mon, 15 Oct 2001 01:39:03 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: Russell Coker Reply-To: Russell Coker To: Greg Ward Subject: Re: Regex question - maybe devfsd should use REG_EXTENDED Date: Mon, 15 Oct 2001 01:39:03 +0200 X-Mailer: KMail [version 1.3.1] Cc: devfs@oss.sgi.com References: <20011013185814.A1334@cthulhu.mems-exchange.org> <20011014124259.01F0834CF7@lyta.coker.com.au> <20011014153424.C954@cthulhu.mems-exchange.org> In-Reply-To: <20011014153424.C954@cthulhu.mems-exchange.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20011014233903.B405732889F@lyta.coker.com.au> Sender: owner-devfs@oss.sgi.com Precedence: bulk On Sun, 14 Oct 2001 21:34, Greg Ward wrote: > > > REGISTER ^(scsi/.*/)cd$ EXECUTE chgrp cdrom \1/generic > > > REGISTER ^(scsi/.*/)cd$ EXECUTE chmod 660 \1/generic > > > > > > In fact, the Debian packaging of devfsd ships with an /etc/devfs/perms > > > that does basically this. > > > > That was a mistake, I don't think I ever uploaded that version to Debian, > > I hope that was only a test version. > > I hope you mean "tweaking the permssions of CD-ROM generic devices" was > a mistake, not "having /etc/devfsd/devfs.conf include perms". The perms > file is a great idea! No to both. The mistake was ever writing a config file that blatantly didn't work. The fact that (AFAIK) I only sent it to 3-4 people before discovering it is a relief. > Anyways, I'm pretty sure the devfsd 1.3.18-3 package did include a perms > file that tweaked the "generic" permissions whenever a "cd" device was > registered. Seems like a good idea to me, although maybe not one that > should be in Debian installation by default. No, it should be the default. The Debian way is to setup default permissions for all devices that fit with the Debian scheme (groups cdrom and video etc). > > Devfsd only uses basic regular expressions. I have been thinking of > > enabling extended regex compilation, but have been hesitant to allow > > Debian users to create config files that won't work anywhere else... > > But the devfsd man page says: > > REGULAR EXPRESSION SUBSTITUTION > Sections of the matched regular expression can be included > in an action. Use \0 to refer to the entire regular > expression matched, \1 to refer to the first parenthesized > subexpression, \2 to refer to the second, and so on. (Use > \\ to include an actual backslash.) > > ...which I take to mean that > > REGISTER ^foo.*bar$ EXECUTE chown luser $devname > > is exactly equivalent to all three of the following: > > REGISTER ^(foo.*bar)$ EXECUTE chown luser $devname > REGISTER ^(foo.*bar)$ EXECUTE chown luser \0 > REGISTER ^(foo.*bar)$ EXECUTE chown luser \1 > > Is this true or not? As near as I can tell, the real rule is: any > regular expression with parentheses in it fails. I don't know. We'll have to wait for clarification from Richard I think. > > You could use the following (default for the next Debian package): > > REGISTER ^ide/.*/cd$ PERMISSIONS root.cdrom 0660 > > REGISTER ^scsi/.*/cd$ PERMISSIONS root.cdrom 0660 > > REGISTER ^ide/.*/disc$ PERMISSIONS root.disk 0660 > > REGISTER ^ide/.*/part[0-9]*$ PERMISSIONS root.disk 0660 > > REGISTER ^scsi/.*/disc$ PERMISSIONS root.disk 0660 > > REGISTER ^scsi/.*/part[0-9]*$ PERMISSIONS root.disk 0660 > > REGISTER ^cciss/.* PERMISSIONS root.disk 0660 > > But that doesn't do anything about the "generic" device that's created > alongside the "cd" device, does it? What I want is this: whenever a > "scsi/.*/cd" device is registered, set the permissions of the "generic" > device in the same file to "root.cdrom 0660". I don't see a clean way > to do this without having regexes that support paren matching, just like > the devfsd man page says they do. Right. Maybe I should just recompile it with EXTENDED... -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page From owner-devfs@oss.sgi.com Mon Oct 15 09:02:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9FG2Xv08960 for devfs-outgoing; Mon, 15 Oct 2001 09:02:33 -0700 Received: from VL-MS-MR002.sc1.videotron.ca (relais.videotron.ca [24.201.245.36]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9FG2UD08955 for ; Mon, 15 Oct 2001 09:02:30 -0700 Received: from cthulhu.gerg.ca ([24.202.92.59]) by VL-MS-MR002.sc1.videotron.ca (Netscape Messaging Server 4.15) with ESMTP id GL98K400.1SD; Mon, 15 Oct 2001 12:02:28 -0400 Received: from greg by cthulhu.gerg.ca with local (Exim 3.32 #1 (Debian)) id 15tACC-0000tD-00; Mon, 15 Oct 2001 12:02:28 -0400 Date: Mon, 15 Oct 2001 12:02:28 -0400 From: Greg Ward To: Russell Coker Cc: devfs@oss.sgi.com Subject: Re: Regex question - maybe devfsd should use REG_EXTENDED Message-ID: <20011015120228.A3397@cthulhu.mems-exchange.org> References: <20011013185814.A1334@cthulhu.mems-exchange.org> <20011014124259.01F0834CF7@lyta.coker.com.au> <20011014153424.C954@cthulhu.mems-exchange.org> <20011014233903.B405732889F@lyta.coker.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011014233903.B405732889F@lyta.coker.com.au> User-Agent: Mutt/1.3.22i Sender: owner-devfs@oss.sgi.com Precedence: bulk On 15 October 2001, Russell Coker said: > > Is this true or not? As near as I can tell, the real rule is: any > > regular expression with parentheses in it fails. > > I don't know. We'll have to wait for clarification from Richard I think. OK. Still not clear to me whether the problem is the code, the docs, or my brain. I guess I could always look at the code... ;-) > Right. Maybe I should just recompile it with EXTENDED... I'd vote for that! I know nothing about Debian policy, but I personally don't have a problem with enabling features on Debian builds that aren't necessarily enabled in other distributions, even if it means I can't take my config files from a Debian box to (say) a Red Hat box. Greg -- Greg Ward - Unix geek gward@python.net http://starship.python.net/~gward/ This message transmitted with 100% recycled electrons. From owner-devfs@oss.sgi.com Tue Oct 16 21:07:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9H47pg17161 for devfs-outgoing; Tue, 16 Oct 2001 21:07:51 -0700 Received: from mobilix.atnf.CSIRO.AU (tinylinux.tip.CSIRO.AU [130.155.192.102]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9H47hD17158 for ; Tue, 16 Oct 2001 21:07:43 -0700 Received: (from rgooch@localhost) by mobilix.ras.ucalgary.ca (8.10.0/8.10.0) id f9G2FaH26921; Mon, 15 Oct 2001 19:15:36 -0700 Date: Mon, 15 Oct 2001 19:15:36 -0700 Message-Id: <200110160215.f9G2FaH26921@mobilix.ras.ucalgary.ca> From: Richard Gooch To: Russell Coker Cc: Greg Ward , devfs@oss.sgi.com Subject: Re: Regex question - maybe devfsd should use REG_EXTENDED In-Reply-To: <20011014233903.B405732889F@lyta.coker.com.au> References: <20011013185814.A1334@cthulhu.mems-exchange.org> <20011014124259.01F0834CF7@lyta.coker.com.au> <20011014153424.C954@cthulhu.mems-exchange.org> <20011014233903.B405732889F@lyta.coker.com.au> Sender: owner-devfs@oss.sgi.com Precedence: bulk Russell Coker writes: > On Sun, 14 Oct 2001 21:34, Greg Ward wrote: > > > Devfsd only uses basic regular expressions. I have been thinking of > > > enabling extended regex compilation, but have been hesitant to allow > > > Debian users to create config files that won't work anywhere else... > > > > But the devfsd man page says: > > > > REGULAR EXPRESSION SUBSTITUTION > > Sections of the matched regular expression can be included > > in an action. Use \0 to refer to the entire regular > > expression matched, \1 to refer to the first parenthesized > > subexpression, \2 to refer to the second, and so on. (Use > > \\ to include an actual backslash.) > > > > ...which I take to mean that > > > > REGISTER ^foo.*bar$ EXECUTE chown luser $devname > > > > is exactly equivalent to all three of the following: > > > > REGISTER ^(foo.*bar)$ EXECUTE chown luser $devname > > REGISTER ^(foo.*bar)$ EXECUTE chown luser \0 > > REGISTER ^(foo.*bar)$ EXECUTE chown luser \1 > > > > Is this true or not? As near as I can tell, the real rule is: any > > regular expression with parentheses in it fails. > > I don't know. We'll have to wait for clarification from Richard I > think. Cough! As if I know! The regular subexpression code was contributed by Chris Rankin. I assume he tested it, since I think he used it. Check the devfsd.conf(5) man page for examples of regular subexpression use. In that page it tells you what you need to know to get it working. I won't tell you the answer, because I want you to read the manual :-) > > > You could use the following (default for the next Debian package): > > > REGISTER ^ide/.*/cd$ PERMISSIONS root.cdrom 0660 > > > REGISTER ^scsi/.*/cd$ PERMISSIONS root.cdrom 0660 > > > REGISTER ^ide/.*/disc$ PERMISSIONS root.disk 0660 > > > REGISTER ^ide/.*/part[0-9]*$ PERMISSIONS root.disk 0660 > > > REGISTER ^scsi/.*/disc$ PERMISSIONS root.disk 0660 > > > REGISTER ^scsi/.*/part[0-9]*$ PERMISSIONS root.disk 0660 > > > REGISTER ^cciss/.* PERMISSIONS root.disk 0660 > > > > But that doesn't do anything about the "generic" device that's created > > alongside the "cd" device, does it? What I want is this: whenever a > > "scsi/.*/cd" device is registered, set the permissions of the "generic" > > device in the same file to "root.cdrom 0660". I don't see a clean way > > to do this without having regexes that support paren matching, just like > > the devfsd man page says they do. > > Right. Maybe I should just recompile it with EXTENDED... No, just use regular subexpressions, which should work. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Wed Oct 17 10:58:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9HHwlT05675 for devfs-outgoing; Wed, 17 Oct 2001 10:58:47 -0700 Received: from tsv.sws.net.au (tsv.sws.net.au [203.36.46.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9HHweD05671 for ; Wed, 17 Oct 2001 10:58:40 -0700 Received: from lyta.coker.com.au (localhost [127.0.0.1]) by tsv.sws.net.au (Postfix) with ESMTP id D08BB92606; Thu, 18 Oct 2001 03:58:35 +1000 (EST) Received: from there (lyta [127.0.0.1]) by lyta.coker.com.au (Postfix) with SMTP id D31713656DC; Wed, 17 Oct 2001 19:59:22 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: Russell Coker Reply-To: Russell Coker To: Richard Gooch Subject: Re: Regex question - maybe devfsd should use REG_EXTENDED Date: Wed, 17 Oct 2001 14:01:38 +0200 X-Mailer: KMail [version 1.3.1] Cc: Greg Ward , devfs@oss.sgi.com References: <20011013185814.A1334@cthulhu.mems-exchange.org> <20011014233903.B405732889F@lyta.coker.com.au> <200110160215.f9G2FaH26921@mobilix.ras.ucalgary.ca> In-Reply-To: <200110160215.f9G2FaH26921@mobilix.ras.ucalgary.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20011017175922.D31713656DC@lyta.coker.com.au> Sender: owner-devfs@oss.sgi.com Precedence: bulk On Tue, 16 Oct 2001 04:15, Richard Gooch wrote: > > > REGISTER ^foo.*bar$ EXECUTE chown luser $devname > > > > > > is exactly equivalent to all three of the following: > > > > > > REGISTER ^(foo.*bar)$ EXECUTE chown luser $devname > > > REGISTER ^(foo.*bar)$ EXECUTE chown luser \0 > > > REGISTER ^(foo.*bar)$ EXECUTE chown luser \1 > > > > > > Is this true or not? As near as I can tell, the real rule is: any > > > regular expression with parentheses in it fails. > > > > I don't know. We'll have to wait for clarification from Richard I > > think. > > Cough! As if I know! The regular subexpression code was contributed by > Chris Rankin. I assume he tested it, since I think he used it. Check > the devfsd.conf(5) man page for examples of regular subexpression use. > In that page it tells you what you need to know to get it working. I > won't tell you the answer, because I want you to read the manual :-) REGISTER ^ide.*(part.) CFUNCTION GLOBAL symlink $devname \1 OK, the above is my test expression. It is to create symlinks /dev/part? that point to /dev/ide/host*/bus*/target*/lun*/part? (I know it's pretty crappy and I wouldn't do it in production but it's a usable test). I ran it with the regular devfsd freshly compiled and it didn't work. I ran it with a hacked version of devfsd that uses REG_EXTENDED and it worked fine. Also the version that was compiled with REG_EXTENDED used the same memory in the regular case (mod 4K) but an extra page when I started actually using extended regular expressions EG (ide|scsi). I believe that REG_EXTENDED should be in the default setup for this. -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page From owner-devfs@oss.sgi.com Wed Oct 17 17:33:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9I0Xfh12125 for devfs-outgoing; Wed, 17 Oct 2001 17:33:41 -0700 Received: from VL-MS-MR003.sc1.videotron.ca (relais.videotron.ca [24.201.245.36]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9I0XYD12120 for ; Wed, 17 Oct 2001 17:33:34 -0700 Received: from cthulhu.gerg.ca ([24.202.92.59]) by VL-MS-MR003.sc1.videotron.ca (Netscape Messaging Server 4.15 MR003 Jul 24 2001 16:23:26) with ESMTP id GLDLJV00.9QT; Wed, 17 Oct 2001 20:33:31 -0400 Received: from greg by cthulhu.gerg.ca with local (Exim 3.32 #1 (Debian)) id 15u17r-0001cZ-00; Wed, 17 Oct 2001 20:33:31 -0400 Date: Wed, 17 Oct 2001 20:33:31 -0400 From: Greg Ward To: Richard Gooch Cc: Russell Coker , devfs@oss.sgi.com Subject: Re: Regex question - maybe devfsd should use REG_EXTENDED Message-ID: <20011017203330.A6057@cthulhu.mems-exchange.org> References: <20011013185814.A1334@cthulhu.mems-exchange.org> <20011014124259.01F0834CF7@lyta.coker.com.au> <20011014153424.C954@cthulhu.mems-exchange.org> <20011014233903.B405732889F@lyta.coker.com.au> <200110160215.f9G2FaH26921@mobilix.ras.ucalgary.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200110160215.f9G2FaH26921@mobilix.ras.ucalgary.ca> User-Agent: Mutt/1.3.22i Sender: owner-devfs@oss.sgi.com Precedence: bulk On 15 October 2001, Richard Gooch said: > Cough! As if I know! The regular subexpression code was contributed by > Chris Rankin. I assume he tested it, since I think he used it. Check > the devfsd.conf(5) man page for examples of regular subexpression use. > In that page it tells you what you need to know to get it working. I > won't tell you the answer, because I want you to read the manual :-) A-ha! So it's not even a doc bug, just my thick skull. D'ohh! Sorry to bother you. May I propose a tiny little patch to the devfsd.8 man page? --- devfsd-1.3.18/devfsd.8 Wed Oct 17 20:29:57 2001 +++ devfsd-1.3.18-hacked/devfsd.8 Wed Oct 17 20:27:58 2001 @@ -293,4 +293,6 @@ \fI\\2\fP to refer to the second, and so on. (Use \fI\\\\\fP to include an actual backslash.) +.PP +See devfsd.conf(5) for examples of regular expression substitution. .SH SIGNALS Hope I've got my *roff syntax right. This should reduce future confusion. Thanks! Greg -- Greg Ward - programmer-at-big gward@python.net http://starship.python.net/~gward/ No animals were harmed in transmitting this message. From owner-devfs@oss.sgi.com Wed Oct 17 23:40:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9I6ebj18620 for devfs-outgoing; Wed, 17 Oct 2001 23:40:37 -0700 Received: from mta01ps.bigpond.com (mta01ps.bigpond.com [144.135.25.133] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9I6eWD18615 for ; Wed, 17 Oct 2001 23:40:33 -0700 Received: from mobilix.atnf.CSIRO.AU ([144.135.25.72]) by mta01ps.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GLE2U100.0YM; Thu, 18 Oct 2001 16:46:49 +1000 Received: from CPE-61-9-176-57.vic.bigpond.net.au ([61.9.176.57]) by PSMAM02.mailsvc.email.bigpond.com(MailRouter V2.9k 8383/1784575); 18 Oct 2001 16:46:49 Received: (from rgooch@localhost) by mobilix.atnf.CSIRO.AU (8.10.0/8.10.0) id f9I6eHg01380; Thu, 18 Oct 2001 16:40:17 +1000 Date: Thu, 18 Oct 2001 16:40:17 +1000 Message-Id: <200110180640.f9I6eHg01380@mobilix.atnf.CSIRO.AU> From: Richard Gooch To: Russell Coker Cc: Greg Ward , devfs@oss.sgi.com Subject: Re: Regex question - maybe devfsd should use REG_EXTENDED In-Reply-To: <20011017175922.D31713656DC@lyta.coker.com.au> References: <20011013185814.A1334@cthulhu.mems-exchange.org> <20011014233903.B405732889F@lyta.coker.com.au> <200110160215.f9G2FaH26921@mobilix.ras.ucalgary.ca> <20011017175922.D31713656DC@lyta.coker.com.au> Sender: owner-devfs@oss.sgi.com Precedence: bulk Russell Coker writes: > On Tue, 16 Oct 2001 04:15, Richard Gooch wrote: > > Cough! As if I know! The regular subexpression code was contributed by > > Chris Rankin. I assume he tested it, since I think he used it. Check > > the devfsd.conf(5) man page for examples of regular subexpression use. > > In that page it tells you what you need to know to get it working. I > > won't tell you the answer, because I want you to read the manual :-) > > REGISTER ^ide.*(part.) CFUNCTION GLOBAL symlink $devname \1 > > OK, the above is my test expression. It is to create symlinks > /dev/part? that point to /dev/ide/host*/bus*/target*/lun*/part? (I > know it's pretty crappy and I wouldn't do it in production but it's > a usable test). > > I ran it with the regular devfsd freshly compiled and it didn't > work. Of course not! devfsd.conf(5) tells you why not. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Wed Oct 17 23:46:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9I6kUp18701 for devfs-outgoing; Wed, 17 Oct 2001 23:46:30 -0700 Received: from mta03ps.bigpond.com (mta03ps.bigpond.com [144.135.25.135] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9I6kQD18697 for ; Wed, 17 Oct 2001 23:46:26 -0700 Received: from mobilix.atnf.CSIRO.AU ([144.135.25.72]) by mta03ps.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GLE33Z00.EPJ; Thu, 18 Oct 2001 16:52:47 +1000 Received: from CPE-61-9-176-57.vic.bigpond.net.au ([61.9.176.57]) by PSMAM02.mailsvc.email.bigpond.com(MailRouter V2.9k 8383/1791326); 18 Oct 2001 16:52:47 Received: (from rgooch@localhost) by mobilix.atnf.CSIRO.AU (8.10.0/8.10.0) id f9I6kIb01468; Thu, 18 Oct 2001 16:46:18 +1000 Date: Thu, 18 Oct 2001 16:46:18 +1000 Message-Id: <200110180646.f9I6kIb01468@mobilix.atnf.CSIRO.AU> From: Richard Gooch To: Greg Ward Cc: Russell Coker , devfs@oss.sgi.com Subject: Re: Regex question - maybe devfsd should use REG_EXTENDED In-Reply-To: <20011017203330.A6057@cthulhu.mems-exchange.org> References: <20011013185814.A1334@cthulhu.mems-exchange.org> <20011014124259.01F0834CF7@lyta.coker.com.au> <20011014153424.C954@cthulhu.mems-exchange.org> <20011014233903.B405732889F@lyta.coker.com.au> <200110160215.f9G2FaH26921@mobilix.ras.ucalgary.ca> <20011017203330.A6057@cthulhu.mems-exchange.org> Sender: owner-devfs@oss.sgi.com Precedence: bulk Greg Ward writes: > On 15 October 2001, Richard Gooch said: > > Cough! As if I know! The regular subexpression code was contributed by > > Chris Rankin. I assume he tested it, since I think he used it. Check > > the devfsd.conf(5) man page for examples of regular subexpression use. > > In that page it tells you what you need to know to get it working. I > > won't tell you the answer, because I want you to read the manual :-) > > A-ha! So it's not even a doc bug, just my thick skull. D'ohh! Well, let's call it a doc mis-feature, since there wasn't a pointer in the place you most needed it. > May I propose a tiny little patch to the devfsd.8 man page? > > --- devfsd-1.3.18/devfsd.8 Wed Oct 17 20:29:57 2001 > +++ devfsd-1.3.18-hacked/devfsd.8 Wed Oct 17 20:27:58 2001 > @@ -293,4 +293,6 @@ > \fI\\2\fP to refer to the second, and so on. (Use \fI\\\\\fP to > include an actual backslash.) > +.PP > +See devfsd.conf(5) for examples of regular expression substitution. > > .SH SIGNALS > > Hope I've got my *roff syntax right. This should reduce future > confusion. Indeed. Applied. Thanks. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Fri Oct 19 08:25:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9JFPIo30640 for devfs-outgoing; Fri, 19 Oct 2001 08:25:18 -0700 Received: from tsv.sws.net.au (tsv.sws.net.au [203.36.46.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9JFPFD30637 for ; Fri, 19 Oct 2001 08:25:15 -0700 Received: from lyta.coker.com.au (localhost [127.0.0.1]) by tsv.sws.net.au (Postfix) with ESMTP id 8B7DE92600 for ; Sat, 20 Oct 2001 01:25:11 +1000 (EST) Received: from there (lyta [127.0.0.1]) by lyta.coker.com.au (Postfix) with SMTP id 3E1D2354E1C for ; Fri, 19 Oct 2001 17:24:50 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" From: Russell Coker Reply-To: Russell Coker To: devfs@oss.sgi.com Subject: Error setting event mask???Device or resource busy Date: Fri, 19 Oct 2001 17:24:49 +0200 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20011019152450.3E1D2354E1C@lyta.coker.com.au> Sender: owner-devfs@oss.sgi.com Precedence: bulk What exactly does this message mean? Someone reported it in the Debian bug tracking system against my devfsd package. I have not seen such an error before and can't reproduce it. The user in question is using an "-ac" kernel. Have other people using "-ac" kernels had any devfs problems recently? -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page From owner-devfs@oss.sgi.com Sun Oct 21 21:05:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9M458F25574 for devfs-outgoing; Sun, 21 Oct 2001 21:05:08 -0700 Received: from mobilix.atnf.CSIRO.AU (tinylinux.tip.CSIRO.AU [130.155.192.102]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9M452D25571 for ; Sun, 21 Oct 2001 21:05:03 -0700 Received: (from rgooch@localhost) by mobilix.atnf.CSIRO.AU (8.10.0/8.10.0) id f9M44TM05285; Mon, 22 Oct 2001 14:04:29 +1000 Date: Mon, 22 Oct 2001 14:04:29 +1000 Message-Id: <200110220404.f9M44TM05285@mobilix.atnf.CSIRO.AU> From: Richard Gooch To: Russell Coker Cc: devfs@oss.sgi.com Subject: Re: Error setting event mask???Device or resource busy In-Reply-To: <20011019152450.3E1D2354E1C@lyta.coker.com.au> References: <20011019152450.3E1D2354E1C@lyta.coker.com.au> Sender: owner-devfs@oss.sgi.com Precedence: bulk Russell Coker writes: > What exactly does this message mean? > > Someone reported it in the Debian bug tracking system against my devfsd > package. I have not seen such an error before and can't reproduce it. > > The user in question is using an "-ac" kernel. Have other people > using "-ac" kernels had any devfs problems recently? Two instances of devfsd running at the same time. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Tue Oct 23 04:07:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9NB73t01398 for devfs-outgoing; Tue, 23 Oct 2001 04:07:03 -0700 Received: from tsv.sws.net.au (tsv.sws.net.au [203.36.46.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9NB6uD01394 for ; Tue, 23 Oct 2001 04:06:57 -0700 Received: from lyta.coker.com.au (localhost [127.0.0.1]) by tsv.sws.net.au (Postfix) with ESMTP id 01DF39260D for ; Tue, 23 Oct 2001 21:06:49 +1000 (EST) Received: from there (lyta [127.0.0.1]) by lyta.coker.com.au (Postfix) with SMTP id 505AE8E6 for ; Tue, 23 Oct 2001 13:06:39 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" From: Russell Coker Reply-To: Russell Coker To: devfs@oss.sgi.com Subject: setsid() and new sysvinit Date: Mon, 22 Oct 2001 22:32:39 +0200 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20011023110639.505AE8E6@lyta.coker.com.au> Sender: owner-devfs@oss.sgi.com Precedence: bulk Firstly I just noticed that devfsd is not calling setsid() after doing close(0);close(1);close(2); is there a good reason for this or is it an oversight? It is my understanding that all daemons should call setsid()... I came across this while investigating a problem that occurs with the latest sysvinit package in Debian. Sysvinit now makes /dev/console the controlling terminal for daemons started before multi-user mode is initiated. This means that it will be sent a SIGHUP by the kernel when the session ends (IE multi-user mode is started). The SIGHUP results in the configuration reload which displays annoying error messages to the console. With the current way devfsd works the console is kept open until /dev/log is created, at which time openlog() is called and the stdin/stdout/stderr are closed. But the session is ended before syslogd is started. What can we do about this? Would it be a good idea to do close(0);close(1);close(2); at the start of the program and then open("/dev/console", O_WRONLY|O_NOCTTY); ? Of course if you want to start devfsd on some other device and have all the error messages go there before syslogd is started and not have the messages go there then this won't be what you want. -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page From owner-devfs@oss.sgi.com Wed Oct 24 13:22:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OKMIf02529 for devfs-outgoing; Wed, 24 Oct 2001 13:22:18 -0700 Received: from tsv.sws.net.au (tsv.sws.net.au [203.36.46.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OKMBD02524 for ; Wed, 24 Oct 2001 13:22:11 -0700 Received: from lyta.coker.com.au (localhost [127.0.0.1]) by tsv.sws.net.au (Postfix) with ESMTP id 58E609260C for ; Thu, 25 Oct 2001 06:22:07 +1000 (EST) Received: from there (lyta [127.0.0.1]) by lyta.coker.com.au (Postfix) with SMTP id 1288A3836C2 for ; Wed, 24 Oct 2001 22:22:08 +0200 (CEST) From: Russell Coker Reply-To: Russell Coker To: devfs@oss.sgi.com Subject: patch for annoying symlink warnings Date: Wed, 24 Oct 2001 21:57:46 +0200 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="------------Boundary-00=_AG7Q9PO794R2BOUVWH2G" Message-Id: <20011024202208.1288A3836C2@lyta.coker.com.au> Sender: owner-devfs@oss.sgi.com Precedence: bulk --------------Boundary-00=_AG7Q9PO794R2BOUVWH2G Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit error calling: "symlink" in "GLOBAL" error calling: "symlink" in "GLOBAL" error calling: "symlink" in "GLOBAL" When you do "killall -1 devfsd" to reload the config you often see errors such as the above. These are because of "CFUNCTION GLOBAL symlink" events trying to create the link a second time. I have attached a patch that fixes this issue. It has special case code for "GLOBAL symlink" which calls an internal function instead of the libc function (to preserve config file compatibility). This function does the usual symlink operation but gives no error message when the link as desired is already there (if you ask for "symlink $devname modem" and there is already a symlink /dev/modem pointing at /dev/$devname then it's not an error IMHO). When there is a real error it gives slightly more information. Richard, please consider this for inclusion in the main tree. -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page --------------Boundary-00=_AG7Q9PO794R2BOUVWH2G Content-Type: text/x-diff; charset="us-ascii"; name="diff-annoying-errs" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="diff-annoying-errs" LS0tIGRldmZzZC0xLjMuMTgub3JpZy9kZXZmc2QuYworKysgZGV2ZnNkLTEuMy4xOC9kZXZmc2Qu YwpAQCAtNzIxLDYgKzcyNSwzMiBAQAogCVNZU0xPRyAoTE9HX0lORk8sICJyZWFkIGNvbmZpZyBm aWxlOiBcIiVzXCJcbiIsIHBhdGgpOwogfSAgIC8qICBFbmQgRnVuY3Rpb24gcmVhZF9jb25maWdf ZmlsZSAgICovCiAKK2ludCBpbnRlcm5hbF9zeW1saW5rKGNoYXIgKm9sZHBhdGgsIGNoYXIgKm5l d3BhdGgpCit7CisgICAgc3RydWN0IHN0YXQgYnVmOworCisgICAgaWYobHN0YXQob2xkcGF0aCwg JmJ1ZikpCisgICAgeworCVNZU0xPRyhMT0dfRVJSLCAiTGluayBkZXN0aW5hdGlvbiBcIiVzXCIg ZG9lc24ndCBleGlzdC4iLCBvbGRwYXRoKTsKKwlyZXR1cm4gMDsKKyAgICB9CisgICAgaWYoc3lt bGluayhvbGRwYXRoLCBuZXdwYXRoKSkKKyAgICB7CisJaWYoZXJybm8gPT0gRUVYSVNUKQorCXsK KwkgICAgY2hhciByZWFkX2J1ZltNQVhQQVRITEVOXTsKKwkgICAgaWYoIWxzdGF0KG5ld3BhdGgs ICZidWYpICYmIChidWYuc3RfbW9kZSAmIFNfSUZMTkspKQorCSAgICB7CisJCWlmKHJlYWRsaW5r KG5ld3BhdGgsIHJlYWRfYnVmLCBNQVhQQVRITEVOKSA+IDAgJiYgc3RyY21wKHJlYWRfYnVmLCBv bGRwYXRoKSA9PSAwKQorCQkgICAgcmV0dXJuIDA7CisJICAgIH0KKwl9CisJU1lTTE9HKExPR19F UlIsICJMaW5rIFwiJXNcIiB0byBcIiVzXCIgZ2l2ZXMgZXJyb3IgJW0uXG4iLCBvbGRwYXRoLCBu ZXdwYXRoKTsKKworICAgIH0KKyAgICByZXR1cm4gMDsKK30KKwogc3RhdGljIHZvaWQgcHJvY2Vz c19jb25maWdfbGluZSAoQ09OU1QgY2hhciAqbGluZSwgdW5zaWduZWQgbG9uZyAqZXZlbnRfbWFz aykKIC8qICBbU1VNTUFSWV0gUHJvY2VzcyBhIGxpbmUgZnJvbSBhIGNvbmZpZ3VyYXRpb24gZmls ZS4KICAgICA8bGluZT4gVGhlIGNvbmZpZ3VyYXRpb24gbGluZS4KQEAgLTg1MCw4ICs4ODAsMTIg QEAKIAkgICAgU1lTTE9HIChMT0dfRVJSLCAiZXJyb3IgbG9hZGluZzogXCIlc1wiXHQlc1xuIiwg cFswXSwgZGxlcnJvciAoKSApOwogCSAgICBleGl0ICgxKTsKIAl9Ci0JbmV3LT51LmZ1bmN0aW9u LmZ1bmMubSA9Ci0JICAgIGRsc3ltX25vZmFpbCAocFswXSwgbmV3LT51LmZ1bmN0aW9uLnNvLT5o YW5kbGUsIHBbMV0pOworCWlmICggc3RyY21wKHBbMF0sICJHTE9CQUwiKSA9PSAwICYmIHN0cmNt cChwWzFdLCAic3ltbGluayIpID09IDAgKQorCSAgICBuZXctPnUuZnVuY3Rpb24uZnVuYy5tID0K KwkgICAgICAgIGRsc3ltX25vZmFpbCAocFswXSwgbmV3LT51LmZ1bmN0aW9uLnNvLT5oYW5kbGUs ICJpbnRlcm5hbF9zeW1saW5rIik7CisJZWxzZQorCSAgICBuZXctPnUuZnVuY3Rpb24uZnVuYy5t ID0KKwkgICAgICAgIGRsc3ltX25vZmFpbCAocFswXSwgbmV3LT51LmZ1bmN0aW9uLnNvLT5oYW5k bGUsIHBbMV0pOwogCS0tbnVtX2FyZ3M7CiAJZm9yIChjb3VudCA9IDA7IGNvdW50IDwgbnVtX2Fy Z3M7ICsrY291bnQpCiAJewo= --------------Boundary-00=_AG7Q9PO794R2BOUVWH2G-- From owner-devfs@oss.sgi.com Wed Oct 24 14:15:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9OLF9605558 for devfs-outgoing; Wed, 24 Oct 2001 14:15:09 -0700 Received: from VL-MS-MR004.sc1.videotron.ca (relais.videotron.ca [24.201.245.36]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9OLF4D05552 for ; Wed, 24 Oct 2001 14:15:05 -0700 Received: from cthulhu.gerg.ca ([24.202.154.157]) by VL-MS-MR004.sc1.videotron.ca (Netscape Messaging Server 4.15) with ESMTP id GLQB0Z04.LGJ; Wed, 24 Oct 2001 17:14:59 -0400 Received: from greg by cthulhu.gerg.ca with local (Exim 3.32 #1 (Debian)) id 15wVMZ-0005O4-00; Wed, 24 Oct 2001 17:14:59 -0400 Date: Wed, 24 Oct 2001 17:14:59 -0400 From: Greg Ward To: Russell Coker Cc: devfs@oss.sgi.com Subject: Re: patch for annoying symlink warnings Message-ID: <20011024171459.A20660@gerg.ca> References: <20011024202208.1288A3836C2@lyta.coker.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011024202208.1288A3836C2@lyta.coker.com.au> User-Agent: Mutt/1.3.22i Sender: owner-devfs@oss.sgi.com Precedence: bulk On 24 October 2001, Russell Coker said: > error calling: "symlink" in "GLOBAL" > error calling: "symlink" in "GLOBAL" > error calling: "symlink" in "GLOBAL" > > When you do "killall -1 devfsd" to reload the config you often see errors > such as the above. These are because of "CFUNCTION GLOBAL symlink" events > trying to create the link a second time. So I'm not the only one who's bugged by this! > I have attached a patch that fixes this issue. Great! Even though I'm an innocent bystander and have only been using devfs for a few weeks, I still have a few comments. ;-) > + if(lstat(oldpath, &buf)) > + { > + SYSLOG(LOG_ERR, "Link destination \"%s\" doesn't exist.", oldpath); > + return 0; > + } This is subtly different from the semantics of the standard symlink(): it bars you from creating dangling symlinks at all. I can envision circumstances where this is useful, but I agree that it should produce a warning. How about downgrading this to a warning (does LOG_WARN exist?), and allowing the (dangling) link to be created anyways? > + if(symlink(oldpath, newpath)) > + { > [...] > + SYSLOG(LOG_ERR, "Link \"%s\" to \"%s\" gives error %m.\n", oldpath, newpath); If "%m" expands to strerror(errno), I only have one comment about this: it could be tightened up a bit, eg.: SYSLOG(LOG_ERR, "symlink \"%s\" to \"%s\": error: %m\n", oldpath, newpath); Minor quibble. Greg -- Greg Ward - Linux geek gward@python.net http://starship.python.net/~gward/ A day for firm decisions!!!!! Or is it? From owner-devfs@oss.sgi.com Wed Oct 24 16:33:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ONXhu12709 for devfs-outgoing; Wed, 24 Oct 2001 16:33:43 -0700 Received: from tower.fukt.bth.se (postfix@tower.fukt.bth.se [194.47.143.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ONXSD12704 for ; Wed, 24 Oct 2001 16:33:28 -0700 Received: from localhost (localhost [127.0.0.1]) by tower.fukt.bth.se (Postfix) with ESMTP id 101BF532F1 for ; Thu, 25 Oct 2001 00:55:30 +0200 (CEST) Date: Thu, 25 Oct 2001 00:55:30 +0200 (CEST) From: =?iso-8859-1?Q?Per_Lid=E9n?= To: Subject: Problems with devfs v.117 (patch) Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="801243791-593193032-1003962892=:23035" Content-ID: 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. --801243791-593193032-1003962892=:23035 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Hi, I've been having problems with devfs since kernel 2.4.11 (ie. devfs version 117). The problem (which I can easily reproduce) occurs if I start X and then start a number of xterms. Then /dev becomes unreadable and all xterms hangs. Any further access to /dev by any program will produce an unkillable process. E.g. "ls /dev" will hang and if I switch to another vc and do "kill -9" on the ls process nothing happens. And as a result, I can't even do a clean shutdown since init, umount, etc all access /dev. Now, everything works fine for me with the 2.4.10 kernel (but not with 2.4.11-2.4.13) so I made a patch which basically undos the changes made in devfs v.117. If I apply my patch to kernel 2.4.13 I'm in business again and devfs works just fine. A friend of mine had the exact same problem. However, he noticed that if he enabled the "Unix98 PTY support" in the kernel the problem went away! I'm not sure what to make out of that. Has anyone else seen this problem? I've attached my patch. Please note that it's quick and dirty and probably broken in some respect, but at least it makes devfs usable for me again ;) best regards, Per --801243791-593193032-1003962892=:23035 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="devfs-undo117.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="devfs-undo117.diff" ZGlmZiAtcnUgbGludXgtMi45LjEzL2ZzL2RldmZzL2Jhc2UuYyBsaW51eC9m cy9kZXZmcy9iYXNlLmMNCi0tLSBsaW51eC0yLjkuMTMvZnMvZGV2ZnMvYmFz ZS5jCVRodSBPY3QgMTEgMDg6MjM6MjQgMjAwMQ0KKysrIGxpbnV4L2ZzL2Rl dmZzL2Jhc2UuYwlUaHUgT2N0IDI1IDAwOjAyOjM0IDIwMDENCkBAIC02Njks NiArNjY5LDggQEANCiANCiBzdHJ1Y3Qgc3ltbGlua190eXBlDQogew0KKyAg ICBhdG9taWNfdCByZWZjb3VudDsgICAgICAgICAgIC8qICBXaGVuIHRoaXMg ZHJvcHMgdG8gemVybywgaXQncyB1bnVzZWQgICAgKi8NCisgICAgcndsb2Nr X3QgbG9jazsgICAgICAgICAgICAgICAvKiAgTG9jayBhcm91bmQgdGhlIHJl Z2lzdGVyZWQgZmxhZyAgICAgICAgICovDQogICAgIHVuc2lnbmVkIGludCBs ZW5ndGg7ICAgICAgICAgLyogIE5vdCBpbmNsdWRpbmcgdGhlIE5VTEwtdGVy bWltYXRvciAgICAgICAqLw0KICAgICBjaGFyICpsaW5rbmFtZTsgICAgICAg ICAgICAgIC8qICBUaGlzIGlzIE5VTEwtdGVybWluYXRlZCAgICAgICAgICAg ICAgICAgKi8NCiB9Ow0KQEAgLTc1OCw4ICs3NjAsNiBAQA0KIHN0YXRpYyB1 bnNpZ25lZCBpbnQgYm9vdF9vcHRpb25zID0gT1BUSU9OX05PTkU7DQogI2Vu ZGlmDQogDQotc3RhdGljIERFQ0xBUkVfUldTRU0gKHN5bWxpbmtfcndzZW0p Ow0KLQ0KIC8qICBGb3J3YXJkIGZ1bmN0aW9uIGRlY2xhcmF0aW9ucyAgKi8N CiBzdGF0aWMgc3RydWN0IGRldmZzX2VudHJ5ICpzZWFyY2hfZm9yX2VudHJ5 IChzdHJ1Y3QgZGV2ZnNfZW50cnkgKmRpciwNCiAJCQkJCSAgICAgY29uc3Qg Y2hhciAqbmFtZSwNCkBAIC04MTcsMTAgKzgxNywxOSBAQA0KICAgICBpZiAo Y3VyciA9PSBOVUxMKSByZXR1cm4gTlVMTDsNCiAgICAgaWYgKCFTX0lTTE5L IChjdXJyLT5tb2RlKSB8fCAhdHJhdmVyc2Vfc3ltbGluaykgcmV0dXJuIGN1 cnI7DQogICAgIC8qICBOZWVkIHRvIGZvbGxvdyB0aGUgbGluazogdGhpcyBp cyBhIHN0YWNrIGNob21wZXIgICovDQotICAgIHJldHZhbCA9IGN1cnItPnJl Z2lzdGVyZWQgPw0KLQlzZWFyY2hfZm9yX2VudHJ5IChwYXJlbnQsIGN1cnIt PnUuc3ltbGluay5saW5rbmFtZSwNCi0JCQkgIGN1cnItPnUuc3ltbGluay5s ZW5ndGgsIEZBTFNFLCBGQUxTRSwgTlVMTCwNCi0JCQkgIFRSVUUpIDogTlVM TDsNCisgICAgcmVhZF9sb2NrICgmY3Vyci0+dS5zeW1saW5rLmxvY2spOw0K KyAgICBpZiAoIWN1cnItPnJlZ2lzdGVyZWQpDQorICAgIHsNCisgICAgICAg cmVhZF91bmxvY2sgKCZjdXJyLT51LnN5bWxpbmsubG9jayk7DQorICAgICAg IHJldHVybiBOVUxMOw0KKyAgICB9DQorICAgIGF0b21pY19pbmMgKCZjdXJy LT51LnN5bWxpbmsucmVmY291bnQpOw0KKyAgICByZWFkX3VubG9jayAoJmN1 cnItPnUuc3ltbGluay5sb2NrKTsNCisgICAgcmV0dmFsID0gc2VhcmNoX2Zv cl9lbnRyeSAocGFyZW50LCBjdXJyLT51LnN5bWxpbmsubGlua25hbWUsDQor ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY3Vyci0+dS5zeW1saW5r Lmxlbmd0aCwgRkFMU0UsIEZBTFNFLCBOVUxMLA0KKyAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFRSVUUpOw0KKyAgICBpZiAoIGF0b21pY19kZWNf YW5kX3Rlc3QgKCZjdXJyLT51LnN5bWxpbmsucmVmY291bnQpICkNCisgICAg ICAga2ZyZWUgKGN1cnItPnUuc3ltbGluay5saW5rbmFtZSk7DQogICAgIHJl dHVybiByZXR2YWw7DQogfSAgIC8qICBFbmQgRnVuY3Rpb24gc2VhcmNoX2Zv cl9lbnRyeV9pbl9kaXIgICovDQogDQpAQCAtMTA5MCwxMCArMTA5OSw4IEBA DQogCSAgICArK25hbWU7DQogCSAgICAtLW5hbWVsZW47DQogCX0NCi0JaWYg KHRyYXZlcnNlX3N5bWxpbmspIGRvd25fcmVhZCAoJnN5bWxpbmtfcndzZW0p Ow0KIAllbnRyeSA9IHNlYXJjaF9mb3JfZW50cnkgKGRpciwgbmFtZSwgbmFt ZWxlbiwgRkFMU0UsIEZBTFNFLCBOVUxMLA0KIAkJCQkgIHRyYXZlcnNlX3N5 bWxpbmspOw0KLQlpZiAodHJhdmVyc2Vfc3ltbGluaykgdXBfcmVhZCAoJnN5 bWxpbmtfcndzZW0pOw0KIAlpZiAoZW50cnkgIT0gTlVMTCkgcmV0dXJuIGVu dHJ5Ow0KICAgICB9DQogICAgIC8qICBIYXZlIHRvIHNlYXJjaCBieSBtYWpv ciBhbmQgbWlub3I6IHNsb3cgICovDQpAQCAtMTQzOSwxMSArMTQ0NiwxMSBA QA0KICAgICB9DQogICAgIGlmIChTX0lTTE5LIChkZS0+bW9kZSkgJiYgZGUt PnJlZ2lzdGVyZWQpDQogICAgIHsNCi0JZGUtPnJlZ2lzdGVyZWQgPSBGQUxT RTsNCi0JZG93bl93cml0ZSAoJnN5bWxpbmtfcndzZW0pOw0KLQlpZiAoZGUt PnUuc3ltbGluay5saW5rbmFtZSkga2ZyZWUgKGRlLT51LnN5bWxpbmsubGlu a25hbWUpOw0KLQlkZS0+dS5zeW1saW5rLmxpbmtuYW1lID0gTlVMTDsNCi0J dXBfd3JpdGUgKCZzeW1saW5rX3J3c2VtKTsNCisgICAgICAgIHdyaXRlX2xv Y2sgKCZkZS0+dS5zeW1saW5rLmxvY2spOw0KKyAgICAgICAgZGUtPnJlZ2lz dGVyZWQgPSBGQUxTRTsNCisgICAgICAgIHdyaXRlX3VubG9jayAoJmRlLT51 LnN5bWxpbmsubG9jayk7DQorICAgICAgICBpZiAoIGF0b21pY19kZWNfYW5k X3Rlc3QgKCZkZS0+dS5zeW1saW5rLnJlZmNvdW50KSApDQorICAgICAgICAg IGtmcmVlIChkZS0+dS5zeW1saW5rLmxpbmtuYW1lKTsNCiAJcmV0dXJuOw0K ICAgICB9DQogICAgIGlmICggU19JU0ZJRk8gKGRlLT5tb2RlKSApDQpAQCAt MTUyMywxMCArMTUzMCw4IEBADQogCWtmcmVlIChuZXdsaW5rKTsNCiAJcmV0 dXJuIC1FTk9NRU07DQogICAgIH0NCi0gICAgZG93bl93cml0ZSAoJnN5bWxp bmtfcndzZW0pOw0KICAgICBpZiAoZGUtPnJlZ2lzdGVyZWQpDQogICAgIHsN Ci0JdXBfd3JpdGUgKCZzeW1saW5rX3J3c2VtKTsNCiAJa2ZyZWUgKG5ld2xp bmspOw0KIAlwcmludGsgKCIlczogZGV2ZnNfZG9fc3ltbGluayglcyk6IGVu dHJ5IGFscmVhZHkgZXhpc3RzXG4iLA0KIAkJREVWRlNfTkFNRSwgbmFtZSk7 DQpAQCAtMTUzNyw4ICsxNTQyLDkgQEANCiAgICAgZGUtPmhpZGUgPSAoZmxh Z3MgJiBERVZGU19GTF9ISURFKSA/IFRSVUUgOiBGQUxTRTsNCiAgICAgZGUt PnUuc3ltbGluay5saW5rbmFtZSA9IG5ld2xpbms7DQogICAgIGRlLT51LnN5 bWxpbmsubGVuZ3RoID0gbGlua2xlbmd0aDsNCisgICAgYXRvbWljX3NldCAo JmRlLT51LnN5bWxpbmsucmVmY291bnQsIDEpOw0KKyAgICByd2xvY2tfaW5p dCAoJmRlLT51LnN5bWxpbmsubG9jayk7DQogICAgIGRlLT5yZWdpc3RlcmVk ID0gVFJVRTsNCi0gICAgdXBfd3JpdGUgKCZzeW1saW5rX3J3c2VtKTsNCiAg ICAgaWYgKGhhbmRsZSAhPSBOVUxMKSAqaGFuZGxlID0gZGU7DQogICAgIHJl dHVybiAwOw0KIH0gICAvKiAgRW5kIEZ1bmN0aW9uIGRldmZzX2RvX3N5bWxp bmsgICovDQpAQCAtMjgwOCwxNSArMjgxNCwxNiBAQA0KICAgICBpZiAoZGUg PT0gTlVMTCkgcmV0dXJuIC1FTk9FTlQ7DQogICAgIGRldmZzZF9ub3RpZnlf b25lIChkZSwgREVWRlNEX05PVElGWV9ERUxFVEUsIGlub2RlLT5pX21vZGUs DQogCQkgICAgICAgaW5vZGUtPmlfdWlkLCBpbm9kZS0+aV9naWQsIGRpci0+ aV9zYi0+dS5nZW5lcmljX3NicCk7DQotICAgIGRlLT5yZWdpc3RlcmVkID0g RkFMU0U7DQotICAgIGRlLT5oaWRlID0gVFJVRTsNCiAgICAgaWYgKCBTX0lT TE5LIChkZS0+bW9kZSkgKQ0KICAgICB7DQotCWRvd25fd3JpdGUgKCZzeW1s aW5rX3J3c2VtKTsNCi0JaWYgKGRlLT51LnN5bWxpbmsubGlua25hbWUpIGtm cmVlIChkZS0+dS5zeW1saW5rLmxpbmtuYW1lKTsNCi0JZGUtPnUuc3ltbGlu ay5saW5rbmFtZSA9IE5VTEw7DQotCXVwX3dyaXRlICgmc3ltbGlua19yd3Nl bSk7DQorICAgICAgIHdyaXRlX2xvY2sgKCZkZS0+dS5zeW1saW5rLmxvY2sp Ow0KKyAgICAgICBkZS0+cmVnaXN0ZXJlZCA9IEZBTFNFOw0KKyAgICAgICB3 cml0ZV91bmxvY2sgKCZkZS0+dS5zeW1saW5rLmxvY2spOw0KKyAgICAgICBp ZiAoIGF0b21pY19kZWNfYW5kX3Rlc3QgKCZkZS0+dS5zeW1saW5rLnJlZmNv dW50KSApDQorICAgICAgICAgICBrZnJlZSAoZGUtPnUuc3ltbGluay5saW5r bmFtZSk7DQogICAgIH0NCisgICAgZWxzZSBkZS0+cmVnaXN0ZXJlZCA9IEZB TFNFOw0KKyAgICBkZS0+aGlkZSA9IFRSVUU7DQogICAgIGZyZWVfZGVudHJp ZXMgKGRlKTsNCiAgICAgcmV0dXJuIDA7DQogfSAgIC8qICBFbmQgRnVuY3Rp b24gZGV2ZnNfdW5saW5rICAqLw0KQEAgLTMwMTgsMTAgKzMwMjUsMTcgQEAN CiANCiAgICAgZGUgPSBnZXRfZGV2ZnNfZW50cnlfZnJvbV92ZnNfaW5vZGUg KGRlbnRyeS0+ZF9pbm9kZSwgVFJVRSk7DQogICAgIGlmICghZGUpIHJldHVy biAtRU5PREVWOw0KLSAgICBkb3duX3JlYWQgKCZzeW1saW5rX3J3c2VtKTsN Ci0gICAgZXJyID0gZGUtPnJlZ2lzdGVyZWQgPyB2ZnNfcmVhZGxpbmsgKGRl bnRyeSwgYnVmZmVyLCBidWZsZW4sDQotCQkJCQkgZGUtPnUuc3ltbGluay5s aW5rbmFtZSkgOiAtRU5PREVWOw0KLSAgICB1cF9yZWFkICgmc3ltbGlua19y d3NlbSk7DQorICAgIHJlYWRfbG9jayAoJmRlLT51LnN5bWxpbmsubG9jayk7 DQorICAgIGlmICghZGUtPnJlZ2lzdGVyZWQpDQorICAgIHsNCisgICAgICAg cmVhZF91bmxvY2sgKCZkZS0+dS5zeW1saW5rLmxvY2spOw0KKyAgICAgICBy ZXR1cm4gLUVOT0RFVjsNCisgICAgfQ0KKyAgICBhdG9taWNfaW5jICgmZGUt PnUuc3ltbGluay5yZWZjb3VudCk7DQorICAgIHJlYWRfdW5sb2NrICgmZGUt PnUuc3ltbGluay5sb2NrKTsNCisgICAgZXJyID0gdmZzX3JlYWRsaW5rIChk ZW50cnksIGJ1ZmZlciwgYnVmbGVuLCBkZS0+dS5zeW1saW5rLmxpbmtuYW1l KTsNCisgICAgaWYgKCBhdG9taWNfZGVjX2FuZF90ZXN0ICgmZGUtPnUuc3lt bGluay5yZWZjb3VudCkgKQ0KKyAgICAgICBrZnJlZSAoZGUtPnUuc3ltbGlu ay5saW5rbmFtZSk7DQogICAgIHJldHVybiBlcnI7DQogfSAgIC8qICBFbmQg RnVuY3Rpb24gZGV2ZnNfcmVhZGxpbmsgICovDQogDQpAQCAtMzAzMiwxMCAr MzA0NiwxNyBAQA0KIA0KICAgICBkZSA9IGdldF9kZXZmc19lbnRyeV9mcm9t X3Zmc19pbm9kZSAoZGVudHJ5LT5kX2lub2RlLCBUUlVFKTsNCiAgICAgaWYg KCFkZSkgcmV0dXJuIC1FTk9ERVY7DQotICAgIGRvd25fcmVhZCAoJnN5bWxp bmtfcndzZW0pOw0KLSAgICBlcnIgPSBkZS0+cmVnaXN0ZXJlZCA/IHZmc19m b2xsb3dfbGluayAobmQsDQotCQkJCQkgICAgZGUtPnUuc3ltbGluay5saW5r bmFtZSkgOiAtRU5PREVWOw0KLSAgICB1cF9yZWFkICgmc3ltbGlua19yd3Nl bSk7DQorICAgIHJlYWRfbG9jayAoJmRlLT51LnN5bWxpbmsubG9jayk7DQor ICAgIGlmICghZGUtPnJlZ2lzdGVyZWQpDQorICAgIHsNCisgICAgICAgcmVh ZF91bmxvY2sgKCZkZS0+dS5zeW1saW5rLmxvY2spOw0KKyAgICAgICByZXR1 cm4gLUVOT0RFVjsNCisgICAgfQ0KKyAgICBhdG9taWNfaW5jICgmZGUtPnUu c3ltbGluay5yZWZjb3VudCk7DQorICAgIHJlYWRfdW5sb2NrICgmZGUtPnUu c3ltbGluay5sb2NrKTsNCisgICAgZXJyID0gdmZzX2ZvbGxvd19saW5rIChu ZCwgZGUtPnUuc3ltbGluay5saW5rbmFtZSk7DQorICAgIGlmICggYXRvbWlj X2RlY19hbmRfdGVzdCAoJmRlLT51LnN5bWxpbmsucmVmY291bnQpICkNCisg ICAgICAga2ZyZWUgKGRlLT51LnN5bWxpbmsubGlua25hbWUpOw0KICAgICBy ZXR1cm4gZXJyOw0KIH0gICAvKiAgRW5kIEZ1bmN0aW9uIGRldmZzX2ZvbGxv d19saW5rICAqLw0KIA0K --801243791-593193032-1003962892=:23035-- From owner-devfs@oss.sgi.com Fri Oct 26 05:38:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9QCcbq28879 for devfs-outgoing; Fri, 26 Oct 2001 05:38:37 -0700 Received: from tsv.sws.net.au (tsv.sws.net.au [203.36.46.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9QCcW028870 for ; Fri, 26 Oct 2001 05:38:32 -0700 Received: from lyta.coker.com.au (localhost [127.0.0.1]) by tsv.sws.net.au (Postfix) with ESMTP id 5F4AA92617; Fri, 26 Oct 2001 22:38:28 +1000 (EST) Received: from there (lyta [127.0.0.1]) by lyta.coker.com.au (Postfix) with SMTP id CA81E34EE1; Fri, 26 Oct 2001 14:38:28 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: Russell Coker Reply-To: Russell Coker To: Greg Ward Subject: Re: patch for annoying symlink warnings Date: Fri, 26 Oct 2001 14:11:03 +0200 X-Mailer: KMail [version 1.3.2] Cc: devfs@oss.sgi.com References: <20011024202208.1288A3836C2@lyta.coker.com.au> <20011024171459.A20660@gerg.ca> In-Reply-To: <20011024171459.A20660@gerg.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20011026123828.CA81E34EE1@lyta.coker.com.au> Sender: owner-devfs@oss.sgi.com Precedence: bulk On Wed, 24 Oct 2001 23:14, Greg Ward wrote: > > + if(lstat(oldpath, &buf)) > > + { > > + SYSLOG(LOG_ERR, "Link destination \"%s\" doesn't exist.", oldpath); > > + return 0; > > + } > > This is subtly different from the semantics of the standard symlink(): > it bars you from creating dangling symlinks at all. I can envision > circumstances where this is useful, but I agree that it should produce a > warning. How about downgrading this to a warning (does LOG_WARN > exist?), and allowing the (dangling) link to be created anyways? OK. The "GLOBAL symlink" operation is generally triggered by a REGISTER event. The normal operation of a register event is to link to the newly created device. So I can't imagine the automatic creation of a broken symlink to be anything other than a serious error. > > + if(symlink(oldpath, newpath)) > > + { > > [...] > > + SYSLOG(LOG_ERR, "Link \"%s\" to \"%s\" gives error %m.\n", oldpath, > > newpath); > > If "%m" expands to strerror(errno), I only have one comment about this: > it could be tightened up a bit, eg.: > > SYSLOG(LOG_ERR, "symlink \"%s\" to \"%s\": error: %m\n", oldpath, > newpath); OK. There's a bug in that bit of code. It uses "%m" after doing some other system calls (so the error may be different). I've fixed that by repeating the symlink attempt before logging the error. -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page From owner-devfs@oss.sgi.com Fri Oct 26 17:29:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9R0THQ18902 for devfs-outgoing; Fri, 26 Oct 2001 17:29:17 -0700 Received: from VL-MS-MR002.sc1.videotron.ca (relais.videotron.ca [24.201.245.36]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9R0TD018896 for ; Fri, 26 Oct 2001 17:29:13 -0700 Received: from cthulhu.gerg.ca ([24.202.154.157]) by VL-MS-MR002.sc1.videotron.ca (Netscape Messaging Server 4.15) with ESMTP id GLU9CO01.QN1; Fri, 26 Oct 2001 20:29:12 -0400 Received: from greg by cthulhu.gerg.ca with local (Exim 3.32 #1 (Debian)) id 15xHLc-0001IQ-00; Fri, 26 Oct 2001 20:29:12 -0400 Date: Fri, 26 Oct 2001 20:29:12 -0400 From: Greg Ward To: Russell Coker Cc: devfs@oss.sgi.com Subject: Re: patch for annoying symlink warnings Message-ID: <20011026202912.C4923@gerg.ca> References: <20011024202208.1288A3836C2@lyta.coker.com.au> <20011024171459.A20660@gerg.ca> <20011026123828.CA81E34EE1@lyta.coker.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011026123828.CA81E34EE1@lyta.coker.com.au> User-Agent: Mutt/1.3.23i Sender: owner-devfs@oss.sgi.com Precedence: bulk On 26 October 2001, Russell Coker said: > OK. The "GLOBAL symlink" operation is generally triggered by a REGISTER > event. The normal operation of a register event is to link to the newly > created device. So I can't imagine the automatic creation of a broken > symlink to be anything other than a serious error. Quite likely an error, certainly worth warning about, but a serious error? Dangling symlinks are usually mistakes, but it's certainly possible for them to be useful. I don't think /dev should be any different from any other filesystem in this respect, although warning about them is a great idea. Greg -- Greg Ward - nerd gward@python.net http://starship.python.net/~gward/ Dyslexics of the world, untie! From owner-devfs@oss.sgi.com Tue Oct 30 15:06:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9UN6P713421 for devfs-outgoing; Tue, 30 Oct 2001 15:06:25 -0800 Received: from panmunjom.compgen.com (IDENT:root@pyongsan.compgen.com [158.155.0.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9UN6K013418 for ; Tue, 30 Oct 2001 15:06:20 -0800 Received: from bass.compgen.com (root@bass.compgen.com [158.155.4.59]) by panmunjom.compgen.com (8.8.7/8.8.7) with ESMTP id SAA20073 for ; Tue, 30 Oct 2001 18:06:18 -0500 Received: (from jlm@localhost) by bass.compgen.com (8.8.7/8.8.7) id SAA21849; Tue, 30 Oct 2001 18:06:17 -0500 From: Jesse Marlin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15327.12905.387514.268529@bass.compgen.com> Date: Tue, 30 Oct 2001 18:06:17 -0500 To: devfs mailing list Subject: blogd failing to startup at boot X-Mailer: VM 6.89 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid Reply-To: Jesse.Marlin@intec-telecom-systems.com X-Face: FbxF/xY!V>vZ.$FXyN9:*'ZV?cib-\o'fWz2=}_Pb!#.JveZp_T18ZKC5T0RXNN=~_HPOF; Tue, 30 Oct 2001 22:36:48 -0800 Received: from there (lyta [127.0.0.1]) by lyta.coker.com.au (Postfix) with SMTP id 59AF5388C4E; Tue, 30 Oct 2001 22:13:08 +0100 (CET) Content-Type: text/plain; charset="iso-8859-1" From: Russell Coker Reply-To: Russell Coker To: Greg Ward Subject: Re: patch for annoying symlink warnings Date: Tue, 30 Oct 2001 18:07:36 +0100 X-Mailer: KMail [version 1.3.2] Cc: devfs@oss.sgi.com References: <20011024202208.1288A3836C2@lyta.coker.com.au> <20011026123828.CA81E34EE1@lyta.coker.com.au> <20011026202912.C4923@gerg.ca> In-Reply-To: <20011026202912.C4923@gerg.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20011030211308.59AF5388C4E@lyta.coker.com.au> Sender: owner-devfs@oss.sgi.com Precedence: bulk On Sat, 27 Oct 2001 02:29, Greg Ward wrote: > On 26 October 2001, Russell Coker said: > > OK. The "GLOBAL symlink" operation is generally triggered by a REGISTER > > event. The normal operation of a register event is to link to the newly > > created device. So I can't imagine the automatic creation of a broken > > symlink to be anything other than a serious error. > > Quite likely an error, certainly worth warning about, but a serious > error? Dangling symlinks are usually mistakes, but it's certainly > possible for them to be useful. I don't think /dev should be any > different from any other filesystem in this respect, although warning > about them is a great idea. OK. In my latest version I've made it log as an error but keep on working. So you can have your machine work with broken links if you really want to, but it'll give you error messages. -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page