From owner-devfs@oss.sgi.com Sat Feb 2 07:56:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g12FuO407913 for devfs-outgoing; Sat, 2 Feb 2002 07:56:24 -0800 Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g12FuId07907 for ; Sat, 2 Feb 2002 07:56:19 -0800 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id g12Eu7O24993; Sat, 2 Feb 2002 15:56:07 +0100 (MET) Received: from MOWD019A.mow.siemens.ru ([139.24.18.3]) by mail2.siemens.de (8.11.6/8.11.6) with ESMTP id g12Eu6g15819; Sat, 2 Feb 2002 15:56:06 +0100 (MET) Received: by mowd019a.mow.siemens.ru with Internet Mail Service (5.5.2653.19) id <1DTTQGKN>; Sat, 2 Feb 2002 17:59:19 +0300 Received: from [149.202.201.201] (149.202.201.201 [149.202.201.201]) by MOWD019A.mow.siemens.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1DTTQGKM; Sat, 2 Feb 2002 17:59:13 +0300 From: Borsenkow Andrej To: Thierry Vignaud Cc: devfs mailing list , Pixel Subject: Re: FW: [Cooker] devfs & my cd-rw ide device In-Reply-To: References: <005701c1a810$a0f4deb0$21c9ca95@mow.siemens.ru> Content-Type: text/plain; charset=KOI8-R X-Mailer: Evolution/1.0.11mdk Date: 02 Feb 2002 17:55:51 +0300 Message-Id: <1012661760.11781.2.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g12FuJd07908 Sender: owner-devfs@oss.sgi.com Precedence: bulk On , 2002-01-28 at 19:00, Thierry Vignaud wrote: > Borsenkow Andrej writes: > > > > > The problem is with devfs+ide-scsi there is no /dev/hdc (or /dev/ide/...) > > > > if hdc is ide-scsi'd so it is impossible to use hdparm. > > > > > > you can have it if you've both eide cd and ide-scsi drivers in kernel core > > > (not tested with modules). > > > > > > /dev/XX is availlable to hdparm even when XXX=ide-scsi is there. ^^^^^^^^^^^^ not quite > > > > What is eide? I can't find it anywhere in kernel-source. > > you can say eide = ide = ata > > extended ide has replaced ide for quite a number of years, now. > > it provided us with : > - two ide channels > - atapi integration > > it has then been enhanced to support higher data rate (udma 33, 66, 100, 133) > > > i wanted to mean: normal ide driver for cds and ide-scsi. > You can have both /dev/scd0 and /dev/hdd if you are using hdd=scsi. If you are using hdd=ide-scsi you do not have /dev/hdd anymore (because it effectively means to use ide-scsi driver so IDE layer does not see this drive at all). Pixel, should we default to hdX=scsi for SCSI emulation? Else it is really bad for those who need hdparm-tune there bad burners. -andrej From owner-devfs@oss.sgi.com Sat Feb 2 08:11:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g12GBYL08187 for devfs-outgoing; Sat, 2 Feb 2002 08:11:34 -0800 Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g12GBWd08184 for ; Sat, 2 Feb 2002 08:11:32 -0800 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id g12FBRO26628; Sat, 2 Feb 2002 16:11:27 +0100 (MET) Received: from MOWD019A.mow.siemens.ru ([139.24.18.3]) by mail2.siemens.de (8.11.6/8.11.6) with ESMTP id g12FBQg17782; Sat, 2 Feb 2002 16:11:26 +0100 (MET) Received: by mowd019a.mow.siemens.ru with Internet Mail Service (5.5.2653.19) id <1DTTQGKX>; Sat, 2 Feb 2002 18:14:39 +0300 Received: from [149.202.201.201] (149.202.201.201 [149.202.201.201]) by MOWD019A.mow.siemens.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1DTTQGKW; Sat, 2 Feb 2002 18:14:33 +0300 From: Borsenkow Andrej To: Thierry Vignaud , devfs mailing list , Pixel Subject: Re: FW: [Cooker] devfs & my cd-rw ide device In-Reply-To: <1012661760.11781.2.camel@localhost.localdomain> References: <005701c1a810$a0f4deb0$21c9ca95@mow.siemens.ru> <1012661760.11781.2.camel@localhost.localdomain> Content-Type: text/plain; charset=KOI8-R X-Mailer: Evolution/1.0.11mdk Date: 02 Feb 2002 18:11:14 +0300 Message-Id: <1012662680.2316.5.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g12GBWd08185 Sender: owner-devfs@oss.sgi.com Precedence: bulk On , 2002-02-02 at 17:55, Andrej Borsenkow wrote: > > You can have both /dev/scd0 and /dev/hdd if you are using hdd=scsi. Forget it. It does not work. With hdd=ide-scsi I get SCSI and no IDE and with hdd=scsi I get just IDE and no SCSI. The last one is probably a bug, but I am not sure how easy it is to fix. Sigh ... -andrej From owner-devfs@oss.sgi.com Mon Feb 4 09:41:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g14HfMv00359 for devfs-outgoing; Mon, 4 Feb 2002 09:41:22 -0800 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 g14HfBA32643 for ; Mon, 4 Feb 2002 09:41:11 -0800 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id g14GeZx27277; Mon, 4 Feb 2002 09:40:35 -0700 Date: Mon, 4 Feb 2002 09:40:35 -0700 Message-Id: <200202041640.g14GeZx27277@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: linux-kernel@vger.kernel.org, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: devfsd-v1.3.23 available Sender: owner-devfs@oss.sgi.com Precedence: bulk Hi, all. I've just released version 1.3.23 of my devfsd (devfs daemon) at: http://www.atnf.csiro.au/~rgooch/linux/ Tarball directly available from: ftp://ftp.??.kernel.org/pub/linux/daemons/devfsd/devfsd.tar.gz AND: ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/daemons/devfsd/devfsd.tar.gz This works with devfs-patch-v130, kernel 2.3.46 and devfs-patch-v99.7 (or later). The main changes are: - Added compatibility entries for parallel port generic ATAPI interface - Minor documentation improvement - Added sample configuration entries for devfsd.conf for media revalidation of compatibility entries - Changed modules.devfs to use kernel naming scheme. Specifically, changed: /dev/sound to sound-slot-0 scsi-hosts to scsi_hostadapter - Added entries to modules.devfs for agpgart and Irda. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Tue Feb 5 05:34:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15DYcO21522 for devfs-outgoing; Tue, 5 Feb 2002 05:34:38 -0800 Received: from vador.mandrakesoft.com (office.mandrakesoft.com [195.68.114.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15DYUA21424 for ; Tue, 5 Feb 2002 05:34:31 -0800 Received: from vador.mandrakesoft.com (localhost.localdomain [127.0.0.1]) by vador.mandrakesoft.com (Postfix) with ESMTP id ADDE1430C; Tue, 5 Feb 2002 14:35:14 +0100 (CET) To: Borsenkow Andrej Cc: devfs mailing list , Pixel Subject: Re: FW: [Cooker] devfs & my cd-rw ide device References: <005701c1a810$a0f4deb0$21c9ca95@mow.siemens.ru> <1012661760.11781.2.camel@localhost.localdomain> X-URL: Date: Tue, 05 Feb 2002 14:35:14 +0100 In-Reply-To: <1012661760.11781.2.camel@localhost.localdomain> (Borsenkow Andrej's message of "02 Feb 2002 17:55:51 +0300") Message-ID: Lines: 18 User-Agent: Gnus/5.090005 (Oort Gnus v0.05) Emacs/21.1 (i386-mandrake-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-devfs@oss.sgi.com Precedence: bulk Borsenkow Andrej writes: > You can have both /dev/scd0 and /dev/hdd if you are using hdd=scsi. If > you are using hdd=ide-scsi you do not have /dev/hdd anymore (because it > effectively means to use ide-scsi driver so IDE layer does not see this > drive at all). you can have if you compile both ide-cdrom.o and ide-scsi.o in core kernel, not as modules > Pixel, should we default to hdX=scsi for SCSI emulation? Else it is > really bad for those who need hdparm-tune there bad burners. you can always use hdX=autotune,dma,... you may not do weird things such as -u -X ... options of hdparm but you can do a lot of things From owner-devfs@oss.sgi.com Tue Feb 5 05:49:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15Dn5R29554 for devfs-outgoing; Tue, 5 Feb 2002 05:49:05 -0800 Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15DmxA29541 for ; Tue, 5 Feb 2002 05:48:59 -0800 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id g15Dmw126260 for ; Tue, 5 Feb 2002 14:48:58 +0100 (MET) Received: from mowp002a.mowp.siemens.ru (mowp002a.mowp.siemens.ru [149.202.148.230]) by mail1.siemens.de (8.11.6/8.11.6) with ESMTP id g15Dmvp27402 for ; Tue, 5 Feb 2002 14:48:57 +0100 (MET) Received: by mowp002a.mowp.siemens.ru with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Feb 2002 16:51:35 +0300 Received: from mw1g17c (mw1g17c.mow.siemens.ru [149.202.201.33]) by MOWD019A.mow.siemens.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1JY558V2; Tue, 5 Feb 2002 16:52:10 +0300 From: Borsenkow Andrej To: "'Thierry Vignaud'" Cc: "'devfs mailing list'" , "'Pixel'" Subject: RE: FW: [Cooker] devfs & my cd-rw ide device Date: Tue, 5 Feb 2002 16:50:32 +0300 Message-ID: <004c01c1ae4c$142a7980$21c9ca95@mow.siemens.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 x-mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal Sender: owner-devfs@oss.sgi.com Precedence: bulk > > > Borsenkow Andrej writes: > > > You can have both /dev/scd0 and /dev/hdd if you are using hdd=scsi. If > > you are using hdd=ide-scsi you do not have /dev/hdd anymore (because it > > effectively means to use ide-scsi driver so IDE layer does not see this > > drive at all). > > > you can have if you compile both ide-cdrom.o and ide-scsi.o in core > kernel, not as modules > Sure. It does not help in this situation in any way. Mandrake has ide-scsi as module. Are you going to change it? > > Pixel, should we default to hdX=scsi for SCSI emulation? Else it is > > really bad for those who need hdparm-tune there bad burners. > > you can always use hdX=autotune,dma,... dma? I can do ideX=dma but not hdXX=dma ... besides, it is exactly what I want to turn off :-) > you may not do weird things such as -u -X ... options of hdparm but > you can do a lot of things Unfortunately kernel parameters are poorly documented for normal users that Mandrake is targeted at. I already have an idea about using direct echo -n setting:val > /proc/bus/hdXX/settings in our rc.sysinit using definitions from /etc/sysconfig/harddisks if we detect ide-scsi'd drive on devfs (for those settings that appear there). It looks pretty trivial, I probably send patch to Chmouel later this week. -andrej From owner-devfs@oss.sgi.com Tue Feb 5 06:08:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g15E8SE06149 for devfs-outgoing; Tue, 5 Feb 2002 06:08:28 -0800 Received: from vador.mandrakesoft.com (office.mandrakesoft.com [195.68.114.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g15E8KA06134 for ; Tue, 5 Feb 2002 06:08:21 -0800 Received: from vador.mandrakesoft.com (localhost.localdomain [127.0.0.1]) by vador.mandrakesoft.com (Postfix) with ESMTP id 9AEF5639C; Tue, 5 Feb 2002 15:09:06 +0100 (CET) To: Borsenkow Andrej Cc: "'devfs mailing list'" , "'Pixel'" Subject: Re: FW: [Cooker] devfs & my cd-rw ide device References: <004c01c1ae4c$142a7980$21c9ca95@mow.siemens.ru> X-URL: Date: Tue, 05 Feb 2002 15:09:06 +0100 In-Reply-To: <004c01c1ae4c$142a7980$21c9ca95@mow.siemens.ru> (Borsenkow Andrej's message of "Tue, 5 Feb 2002 16:50:32 +0300") Message-ID: Lines: 50 User-Agent: Gnus/5.090005 (Oort Gnus v0.05) Emacs/21.1 (i386-mandrake-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-devfs@oss.sgi.com Precedence: bulk Borsenkow Andrej writes: > > > You can have both /dev/scd0 and /dev/hdd if you are using > > > hdd=scsi. If you are using hdd=ide-scsi you do not have > > > /dev/hdd anymore (because it effectively means to use ide-scsi > > > driver so IDE layer does not see this drive at all). > > > > you can have if you compile both ide-cdrom.o and ide-scsi.o in > > core kernel, not as modules > > > > Sure. It does not help in this situation in any way. Mandrake has > ide-scsi as module. Are you going to change it? of course not but one can recompile the kernel from the kernel-source package. it's a solution > > > Pixel, should we default to hdX=scsi for SCSI emulation? Else it > > > is really bad for those who need hdparm-tune there bad burners. > > > > you can always use hdX=autotune,dma,... > > dma? I can do ideX=dma but not hdXX=dma ... sure you can (it works since at least kernel-2.0.2x times) for both ideX= and hdY= only ...=dma is restricted to ideX= > besides, it is exactly what I want to turn off :-) providing, there's nothing else on the eide cable, you can try ideX=noautotune (but i'm not sure it'll use pio instead of dma). just try. > > you may not do weird things such as -u -X ... options of hdparm > > but you can do a lot of things > > Unfortunately kernel parameters are poorly documented for normal users > that Mandrake is targeted at. providing one has installed kernel-doc package, he can look at Documentation/ide.txt as /usr/share/doc/kernel-source-2.4.XX/ide.txt > I already have an idea about using direct echo -n setting:val > > /proc/bus/hdXX/settings in our rc.sysinit using definitions from > /etc/sysconfig/harddisks if we detect ide-scsi'd drive on devfs (for > those settings that appear there). It looks pretty trivial, I > probably send patch to Chmouel later this week. ok. From owner-devfs@oss.sgi.com Wed Feb 6 22:32:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g176WwH15105 for devfs-outgoing; Wed, 6 Feb 2002 22:32:58 -0800 Received: from goliath.siemens.de (goliath.siemens.de [194.138.37.131]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g176WkA15101 for ; Wed, 6 Feb 2002 22:32:47 -0800 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id g176WiF25793 for ; Thu, 7 Feb 2002 07:32:45 +0100 (MET) Received: from mowp002a.mowp.siemens.ru (mowp002a.mowp.siemens.ru [149.202.148.230]) by mail1.siemens.de (8.11.6/8.11.6) with ESMTP id g176Whp21727 for ; Thu, 7 Feb 2002 07:32:44 +0100 (MET) Received: by mowp002a.mowp.siemens.ru with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Feb 2002 09:35:24 +0300 Received: from mw1g17c (mw1g17c.mow.siemens.ru [149.202.201.33]) by MOWD019A.mow.siemens.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1N8MT5T1; Thu, 7 Feb 2002 09:35:53 +0300 From: Borsenkow Andrej To: "'Richard Gooch'" , "'Russell Coker'" Cc: "'Thierry Vignaud'" , "'devfs mailing list'" , "'Keith Owens'" Subject: RE: [Fwd: [Cooker] modules.devfsd addition] Date: Thu, 7 Feb 2002 09:34:14 +0300 Message-ID: <001a01c1afa1$7647d8a0$21c9ca95@mow.siemens.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <200201290626.g0T6QOZ14180@vindaloo.ras.ucalgary.ca> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-devfs@oss.sgi.com Precedence: bulk > > Russell Coker writes: > > On Mon, 28 Jan 2002 17:16, Borsenkow Andrej wrote: > > > I too think that implementing per-package addition would be really nice. > > > But I am strongly against editing single monolithic configuration file. > > > If we ever have per-package config - please, implement support for > > > /etc/devfsd.d directory where packages can drop config files as needed. > > > > Devfsd already has support for that. If an OPTIONAL_INCLUDE or > > INCLUDE line references a directory then all files in that directory > > will be included. This is used in the default setup for Debian to > > include files in the directory /etc/devfs/conf.d/ . > > > > As for modules, this is done in Debian by having a script named > > update-modules which produces a file /etc/modules.conf from files in > > the directory /etc/modutils/ . > > So do you think that the modules.devfs file that I ship is useless? > You'd rather see that each package is responsible for their respective > parts? > > While that may have some benefits, it requires that all packages > install configuration files for devfsd. Some package maintainers may > have no interest in devfs. By shipping modules.devfs with devfsd, I > can increase the chance of things actually working. > modules.devfs actually serves as replacement for built-in aliases in modprobe. So I believe it should contain the same set of aliases by default - after all you do not recompile modutils every time kernel is reconfigured. May be it even should be built as part of modutils and serve as good reference to device names used in kernel. That said, I do not suggest adding every possible third-part module like nVidia or vmware of course. > I must say I dislike the script idea you have in Debian. I think it's > much cleaner for modutils to take care of this. If you specify a > directory for the "include" directive, it should recursively process > all files in that directory. > > Keith? > I second it. -andrej From owner-devfs@oss.sgi.com Wed Feb 6 23:12:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g177CgV15671 for devfs-outgoing; Wed, 6 Feb 2002 23:12:42 -0800 Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g177CcA15668 for ; Wed, 6 Feb 2002 23:12:39 -0800 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id g177Ca118064 for ; Thu, 7 Feb 2002 08:12:36 +0100 (MET) Received: from mowp002a.mowp.siemens.ru (mowp002a.mowp.siemens.ru [149.202.148.230]) by mail1.siemens.de (8.11.6/8.11.6) with ESMTP id g177CZp07418 for ; Thu, 7 Feb 2002 08:12:36 +0100 (MET) Received: by mowp002a.mowp.siemens.ru with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Feb 2002 10:15:16 +0300 Received: from mw1g17c (mw1g17c.mow.siemens.ru [149.202.201.33]) by MOWD019A.mow.siemens.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1N8MT56C; Thu, 7 Feb 2002 10:15:44 +0300 From: Borsenkow Andrej To: kernel@mandrakesoft.com, "'devfs mailing list'" Subject: char/raw.c devfs support Date: Thu, 7 Feb 2002 10:14:05 +0300 Message-ID: <001c01c1afa7$075191b0$21c9ca95@mow.siemens.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-devfs@oss.sgi.com Precedence: bulk Once upon a time two patches were sent (almost at the same time) to kernel@mandrake and lkml. Neither of them was ever applied. Lkml patch: http://marc.theaimsgroup.com/?l=linux-kernel&m=100780761210741&w=2 kernel@mandrake patch (cc'd to cooker: http://marc.theaimsgroup.com/?l=mandrake-cooker&m=100790713330801&w=2 I find lkml version a bit more clean. Any chance to get them into official 2.4.18 or at least into Mandrake kernel before 8.2? Regards -andrej From owner-devfs@oss.sgi.com Thu Feb 7 09:28:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g17HS7g27443 for devfs-outgoing; Thu, 7 Feb 2002 09:28:07 -0800 Received: from office.mandrakesoft.com (office.mandrakesoft.com [195.68.114.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g17HS1A27440 for ; Thu, 7 Feb 2002 09:28:02 -0800 Received: from localhost.mandrakesoft.com ([192.168.100.108]) by office.mandrakesoft.com (8.9.3/8.9.3) with ESMTP id SAA29508; Thu, 7 Feb 2002 18:26:12 +0100 Received: by localhost.mandrakesoft.com (Postfix, from userid 501) id EE9F416F1D; Thu, 7 Feb 2002 18:16:27 +0100 (CET) To: Borsenkow Andrej Cc: kernel@mandrakesoft.com, "'devfs mailing list'" Subject: Re: [kernel] char/raw.c devfs support References: <001c01c1afa7$075191b0$21c9ca95@mow.siemens.ru> X-Url: http://www.lfcia.org/~quintela From: Juan Quintela In-Reply-To: <001c01c1afa7$075191b0$21c9ca95@mow.siemens.ru> Date: 07 Feb 2002 18:16:27 +0100 Message-ID: Lines: 24 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-devfs@oss.sgi.com Precedence: bulk >>>>> "borsenkow" == Borsenkow Andrej writes: borsenkow> Once upon a time two patches were sent (almost at the same time) to borsenkow> kernel@mandrake and lkml. Neither of them was ever applied. borsenkow> Lkml patch: borsenkow> http://marc.theaimsgroup.com/?l=linux-kernel&m=100780761210741&w=2 borsenkow> kernel@mandrake patch (cc'd to cooker: borsenkow> http://marc.theaimsgroup.com/?l=mandrake-cooker&m=100790713330801&w=2 borsenkow> I find lkml version a bit more clean. borsenkow> Any chance to get them into official 2.4.18 or at least into Mandrake borsenkow> kernel before 8.2? in 16mdk. -- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy From owner-devfs@oss.sgi.com Thu Feb 7 09:37:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g17HbuZ27559 for devfs-outgoing; Thu, 7 Feb 2002 09:37:56 -0800 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 g17HbrA27556 for ; Thu, 7 Feb 2002 09:37:53 -0800 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id g17HbLi26463; Thu, 7 Feb 2002 10:37:21 -0700 Date: Thu, 7 Feb 2002 10:37:21 -0700 Message-Id: <200202071737.g17HbLi26463@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Juan Quintela Cc: Borsenkow Andrej , kernel@mandrakesoft.com, "'devfs mailing list'" Subject: Re: [kernel] char/raw.c devfs support In-Reply-To: References: <001c01c1afa7$075191b0$21c9ca95@mow.siemens.ru> Sender: owner-devfs@oss.sgi.com Precedence: bulk Juan Quintela writes: > in 16mdk. BTW, Juan: I haven't yet received a followup about what was going wrong with your /lib/dev-state and /dev/log problems. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Thu Feb 7 11:10:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g17JA0b30992 for devfs-outgoing; Thu, 7 Feb 2002 11:10:00 -0800 Received: from office.mandrakesoft.com (office.mandrakesoft.com [195.68.114.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g17J9uA30987 for ; Thu, 7 Feb 2002 11:09:57 -0800 Received: from localhost.mandrakesoft.com ([192.168.100.108]) by office.mandrakesoft.com (8.9.3/8.9.3) with ESMTP id UAA30220; Thu, 7 Feb 2002 20:08:41 +0100 Received: by localhost.mandrakesoft.com (Postfix, from userid 501) id C37C016F1D; Thu, 7 Feb 2002 19:58:56 +0100 (CET) To: Richard Gooch Cc: Borsenkow Andrej , kernel@mandrakesoft.com, "'devfs mailing list'" Subject: Re: [kernel] char/raw.c devfs support References: <001c01c1afa7$075191b0$21c9ca95@mow.siemens.ru> <200202071737.g17HbLi26463@vindaloo.ras.ucalgary.ca> X-Url: http://www.lfcia.org/~quintela From: Juan Quintela In-Reply-To: <200202071737.g17HbLi26463@vindaloo.ras.ucalgary.ca> Date: 07 Feb 2002 19:58:56 +0100 Message-ID: Lines: 17 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-devfs@oss.sgi.com Precedence: bulk >>>>> "richard" == Richard Gooch writes: richard> Juan Quintela writes: >> in 16mdk. richard> BTW, Juan: I haven't yet received a followup about what was going richard> wrong with your /lib/dev-state and /dev/log problems. I don't know really, I think that it was a devfsd package here that got a wrong config file :( Later, Juan. -- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy From owner-devfs@oss.sgi.com Thu Feb 7 14:17:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g17MH3c07698 for devfs-outgoing; Thu, 7 Feb 2002 14:17:03 -0800 Received: from vador.mandrakesoft.com (office.mandrakesoft.com [195.68.114.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g17MGwA07692 for ; Thu, 7 Feb 2002 14:16:58 -0800 Received: from vador.mandrakesoft.com (localhost.localdomain [127.0.0.1]) by vador.mandrakesoft.com (Postfix) with ESMTP id B13CB1200D; Thu, 7 Feb 2002 23:18:04 +0100 (CET) To: Juan Quintela Cc: Richard Gooch , Borsenkow Andrej , kernel@mandrakesoft.com, "'devfs mailing list'" , Frederic Lepied Subject: Re: [kernel] char/raw.c devfs support References: <001c01c1afa7$075191b0$21c9ca95@mow.siemens.ru> <200202071737.g17HbLi26463@vindaloo.ras.ucalgary.ca> X-URL: Date: Thu, 07 Feb 2002 23:18:03 +0100 In-Reply-To: (Juan Quintela's message of "07 Feb 2002 19:58:56 +0100") Message-ID: Lines: 31 User-Agent: Gnus/5.090005 (Oort Gnus v0.05) Emacs/21.1 (i386-mandrake-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-devfs@oss.sgi.com Precedence: bulk Juan Quintela writes: > > BTW, Juan: I haven't yet received a followup about what was going > > wrong with your /lib/dev-state and /dev/log problems. > > I don't know really, I think that it was a devfsd package here that > got a wrong config file :( the /dev/log problem has been traced back to the following portion of /etc/rc.d/rc.sysinit : # Restart devfsd actions now that the filesystems are ready if [ -c /dev/.devfsd ]; then if [ -x /sbin/devfsd ]; then # cleanup dynamic desktop directories before calling devfsd actions rm -f /usr/share/gnome/desktop/* /usr/share/apps/kdesktop/Desktop/* action "Running devfsd actions: " killall -HUP devfsd fi fi sometimes, the bootstraping process wait for minutes because of some sort of race between devfsd and minilogd (remeber syslogd hasn't yet be started since it's a service launched after rc.sysinit let rc play with init levels. we've found a solution: make a service of the previous piece of script and run it very late (ie in 99th position whereas syslogd service has a priority of 88). From owner-devfs@oss.sgi.com Thu Feb 7 21:58:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g185w9l19439 for devfs-outgoing; Thu, 7 Feb 2002 21:58:09 -0800 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 g185vxA19436 for ; Thu, 7 Feb 2002 21:57:59 -0800 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id g185vlc14531; Thu, 7 Feb 2002 22:57:47 -0700 Date: Thu, 7 Feb 2002 22:57:47 -0700 Message-Id: <200202080557.g185vlc14531@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Thierry Vignaud Cc: Juan Quintela , Borsenkow Andrej , kernel@mandrakesoft.com, "'devfs mailing list'" , Frederic Lepied Subject: Re: [kernel] char/raw.c devfs support In-Reply-To: References: <001c01c1afa7$075191b0$21c9ca95@mow.siemens.ru> <200202071737.g17HbLi26463@vindaloo.ras.ucalgary.ca> Sender: owner-devfs@oss.sgi.com Precedence: bulk Thierry Vignaud writes: > Juan Quintela writes: > > > > BTW, Juan: I haven't yet received a followup about what was going > > > wrong with your /lib/dev-state and /dev/log problems. > > > > I don't know really, I think that it was a devfsd package here that > > got a wrong config file :( > > the /dev/log problem has been traced back to the following portion of > /etc/rc.d/rc.sysinit : > > > # Restart devfsd actions now that the filesystems are ready > if [ -c /dev/.devfsd ]; then > if [ -x /sbin/devfsd ]; then > # cleanup dynamic desktop directories before calling devfsd actions > rm -f /usr/share/gnome/desktop/* /usr/share/apps/kdesktop/Desktop/* > > action "Running devfsd actions: " killall -HUP devfsd > fi > fi > > > sometimes, the bootstraping process wait for minutes because of some > sort of race between devfsd and minilogd (remeber syslogd hasn't yet > be started since it's a service launched after rc.sysinit let rc play > with init levels. > > we've found a solution: make a service of the previous piece of script > and run it very late (ie in 99th position whereas syslogd service has > a priority of 88). Ug! I hate work-arounds. Can you put time into helping track down whether there is a bug in devfs or devfsd, and what the cause of the bug is? Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Thu Feb 7 23:03:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1873sa20371 for devfs-outgoing; Thu, 7 Feb 2002 23:03:54 -0800 Received: from goliath.siemens.de (goliath.siemens.de [194.138.37.131]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1873nA20368 for ; Thu, 7 Feb 2002 23:03:49 -0800 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id g1873lF10237 for ; Fri, 8 Feb 2002 08:03:47 +0100 (MET) Received: from mowp002a.mowp.siemens.ru (mowp002a.mowp.siemens.ru [149.202.148.230]) by mail1.siemens.de (8.11.6/8.11.6) with ESMTP id g1873kp29875 for ; Fri, 8 Feb 2002 08:03:46 +0100 (MET) Received: by mowp002a.mowp.siemens.ru with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Feb 2002 10:06:27 +0300 Received: from mw1g17c (mw1g17c.mow.siemens.ru [149.202.201.33]) by MOWD019A.mow.siemens.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1P0A4FF7; Fri, 8 Feb 2002 10:06:56 +0300 From: Borsenkow Andrej To: "'Thierry Vignaud'" , "'Juan Quintela'" Cc: "'Richard Gooch'" , kernel@mandrakesoft.com, "'devfs mailing list'" , "'Frederic Lepied'" Subject: RE: [kernel] char/raw.c devfs support Date: Fri, 8 Feb 2002 10:05:32 +0300 Message-ID: <000501c1b06f$000e2530$21c9ca95@mow.siemens.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 x-mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal Sender: owner-devfs@oss.sgi.com Precedence: bulk > > the /dev/log problem has been traced back to the following portion of > /etc/rc.d/rc.sysinit : > > > # Restart devfsd actions now that the filesystems are ready > if [ -c /dev/.devfsd ]; then > if [ -x /sbin/devfsd ]; then > # cleanup dynamic desktop directories before calling devfsd actions > rm -f /usr/share/gnome/desktop/* /usr/share/apps/kdesktop/Desktop/* > > action "Running devfsd actions: " killall -HUP devfsd > fi > fi > > > sometimes, the bootstraping process wait for minutes because of some > sort of race between devfsd and minilogd (remeber syslogd hasn't yet > be started since it's a service launched after rc.sysinit let rc play > with init levels. > Is it related to those lockups with "Loading compose table ..." as the last message? -andrej From owner-devfs@oss.sgi.com Fri Feb 8 01:05:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1895hi23997 for devfs-outgoing; Fri, 8 Feb 2002 01:05:43 -0800 Received: from office.mandrakesoft.com (office.mandrakesoft.com [195.68.114.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1895cA23994 for ; Fri, 8 Feb 2002 01:05:38 -0800 Received: from localhost.mandrakesoft.com ([192.168.100.108]) by office.mandrakesoft.com (8.9.3/8.9.3) with ESMTP id KAA01286; Fri, 8 Feb 2002 10:03:07 +0100 Received: by localhost.mandrakesoft.com (Postfix, from userid 501) id B1AB916F1D; Fri, 8 Feb 2002 09:53:20 +0100 (CET) To: Borsenkow Andrej Cc: "'Thierry Vignaud'" , "'Richard Gooch'" , kernel@mandrakesoft.com, "'devfs mailing list'" , "'Frederic Lepied'" Subject: Re: [kernel] char/raw.c devfs support References: <000501c1b06f$000e2530$21c9ca95@mow.siemens.ru> X-Url: http://www.lfcia.org/~quintela From: Juan Quintela In-Reply-To: <000501c1b06f$000e2530$21c9ca95@mow.siemens.ru> Date: 08 Feb 2002 09:53:20 +0100 Message-ID: Lines: 35 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-devfs@oss.sgi.com Precedence: bulk >>>>> "borsenkow" == Borsenkow Andrej writes: >> >> the /dev/log problem has been traced back to the following portion of >> /etc/rc.d/rc.sysinit : >> >> >> # Restart devfsd actions now that the filesystems are ready >> if [ -c /dev/.devfsd ]; then >> if [ -x /sbin/devfsd ]; then >> # cleanup dynamic desktop directories before calling devfsd borsenkow> actions >> rm -f /usr/share/gnome/desktop/* borsenkow> /usr/share/apps/kdesktop/Desktop/* >> >> action "Running devfsd actions: " killall -HUP devfsd >> fi >> fi >> >> >> sometimes, the bootstraping process wait for minutes because of some >> sort of race between devfsd and minilogd (remeber syslogd hasn't yet >> be started since it's a service launched after rc.sysinit let rc play >> with init levels. >> borsenkow> Is it related to those lockups with "Loading compose table ..." as the borsenkow> last message? Yes. -- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy From owner-devfs@oss.sgi.com Fri Feb 8 01:10:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g189ADS24084 for devfs-outgoing; Fri, 8 Feb 2002 01:10:13 -0800 Received: from office.mandrakesoft.com (office.mandrakesoft.com [195.68.114.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g189A5A24081 for ; Fri, 8 Feb 2002 01:10:05 -0800 Received: from localhost.mandrakesoft.com ([192.168.100.108]) by office.mandrakesoft.com (8.9.3/8.9.3) with ESMTP id KAA01325; Fri, 8 Feb 2002 10:08:53 +0100 Received: by localhost.mandrakesoft.com (Postfix, from userid 501) id A153D16F1D; Fri, 8 Feb 2002 09:59:06 +0100 (CET) To: Richard Gooch Cc: Thierry Vignaud , Borsenkow Andrej , kernel@mandrakesoft.com, "'devfs mailing list'" , Frederic Lepied Subject: Re: [kernel] char/raw.c devfs support References: <001c01c1afa7$075191b0$21c9ca95@mow.siemens.ru> <200202071737.g17HbLi26463@vindaloo.ras.ucalgary.ca> <200202080557.g185vlc14531@vindaloo.ras.ucalgary.ca> X-Url: http://www.lfcia.org/~quintela From: Juan Quintela In-Reply-To: <200202080557.g185vlc14531@vindaloo.ras.ucalgary.ca> Date: 08 Feb 2002 09:59:06 +0100 Message-ID: Lines: 64 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-devfs@oss.sgi.com Precedence: bulk >>>>> "richard" == Richard Gooch writes: richard> Thierry Vignaud writes: >> Juan Quintela writes: >> >> > > BTW, Juan: I haven't yet received a followup about what was going >> > > wrong with your /lib/dev-state and /dev/log problems. >> > >> > I don't know really, I think that it was a devfsd package here that >> > got a wrong config file :( >> >> the /dev/log problem has been traced back to the following portion of >> /etc/rc.d/rc.sysinit : >> >> >> # Restart devfsd actions now that the filesystems are ready >> if [ -c /dev/.devfsd ]; then >> if [ -x /sbin/devfsd ]; then >> # cleanup dynamic desktop directories before calling devfsd actions >> rm -f /usr/share/gnome/desktop/* /usr/share/apps/kdesktop/Desktop/* >> >> action "Running devfsd actions: " killall -HUP devfsd >> fi >> fi >> >> >> sometimes, the bootstraping process wait for minutes because of some >> sort of race between devfsd and minilogd (remeber syslogd hasn't yet >> be started since it's a service launched after rc.sysinit let rc play >> with init levels. >> >> we've found a solution: make a service of the previous piece of script >> and run it very late (ie in 99th position whereas syslogd service has >> a priority of 88). richard> Ug! I hate work-arounds. Can you put time into helping track down richard> whether there is a bug in devfs or devfsd, and what the cause of the richard> bug is? I sent you a kernel trace with the _two_ minilogd & the devfsd trace. I don't know an easy way to get a gdb trace of devfsd in user space at this point in the boot procedure. Basically the problem is (from my reading of the traces): - one minilogd do: unlink("/dev/log"); this blocks (kernel space) wating for some kind of devfsd confirmation. - other minilogd tries to create /dev/log as an UNIX socket, and it takes some devfs semafore or similarn. - devfsd is not able to get that semaphore, which means that the first minilogd is unable to finish (the unlink of /dev/log), and then second minilogd is not able either of finish is creation of the UNIX socket (/dev/log is still not removed). This was after a fast look at the minilogd source, I still don't know why minilogd forks itself. Later, Juan. -- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy From owner-devfs@oss.sgi.com Fri Feb 8 02:16:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g18AGOG25275 for devfs-outgoing; Fri, 8 Feb 2002 02:16:24 -0800 Received: from vador.mandrakesoft.com (office.mandrakesoft.com [195.68.114.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g18AGKA25272 for ; Fri, 8 Feb 2002 02:16:21 -0800 Received: from vador.mandrakesoft.com (localhost.localdomain [127.0.0.1]) by vador.mandrakesoft.com (Postfix) with ESMTP id BD7665385; Fri, 8 Feb 2002 11:17:25 +0100 (CET) To: Juan Quintela Cc: Borsenkow Andrej , "'Richard Gooch'" , kernel@mandrakesoft.com, "'devfs mailing list'" , "'Frederic Lepied'" Subject: Re: [kernel] char/raw.c devfs support References: <000501c1b06f$000e2530$21c9ca95@mow.siemens.ru> X-URL: Date: Fri, 08 Feb 2002 11:17:24 +0100 In-Reply-To: (Juan Quintela's message of "08 Feb 2002 09:53:20 +0100") Message-ID: Lines: 18 User-Agent: Gnus/5.090005 (Oort Gnus v0.05) Emacs/21.1 (i386-mandrake-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-devfs@oss.sgi.com Precedence: bulk Juan Quintela writes: > > > sometimes, the bootstraping process wait for minutes because of > > > some sort of race between devfsd and minilogd (remeber syslogd > > > hasn't yet be started since it's a service launched after > > > rc.sysinit let rc play with init levels. > > > > Is it related to those lockups with "Loading compose table ..." as > > the last message? > > Yes. just a question of time : rc.sysinit has the time to do a few things before devfsd and minilogd clashes. aurora helps to debug: take a slow box with few memory, enable aurora, and you'll see it. with pixel, we've altered all /etc/rc.d/ stuff to use /bin/bash -x, run devfsd in debug mode on another console to find the problem source. From owner-devfs@oss.sgi.com Thu Feb 14 06:11:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1EEBA412362 for devfs-outgoing; Thu, 14 Feb 2002 06:11:10 -0800 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 g1EEB2912354 for ; Thu, 14 Feb 2002 06:11:03 -0800 Received: from lyta.coker.com.au (localhost [127.0.0.1]) by tsv.sws.net.au (Postfix) with ESMTP id 9151D9265F; Fri, 15 Feb 2002 00:10:48 +1100 (EST) Received: from there (lyta [127.0.0.1]) by lyta.coker.com.au (Postfix) with SMTP id D2E62C73D; Fri, 15 Feb 2002 00:10:17 +1100 (EST) Content-Type: text/plain; charset="us-ascii" From: Russell Coker Reply-To: Russell Coker To: devfs@oss.sgi.com Subject: modprobe /dev/* Date: Fri, 15 Feb 2002 00:10:17 +1100 X-Mailer: KMail [version 1.3.2] Cc: kaos@ocs.com.au MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020214131017.D2E62C73D@lyta.coker.com.au> Sender: owner-devfs@oss.sgi.com Precedence: bulk At linux.conf.au Keith and I were looking into devfs module loading issues. We noticed that the distribution he was running (some RPM distribution) had a lot of scripts with code like the following: for n in /dev/dsp* ; do ... done This results in `modprobe "/dev/dsp*"` being run once for the for line and then a second time in the body of the loop. We discovered that a significant number of useless modprobe runs were removed when we added the following to devfsd.conf: LOOKUP \*$ IGNORE Before the following line in the default config: LOOKUP .* MODLOAD I think that this should be part of the default config file. -- 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 Thu Feb 14 07:37:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1EFb7u13918 for devfs-outgoing; Thu, 14 Feb 2002 07:37:07 -0800 Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1EFaw913912 for ; Thu, 14 Feb 2002 07:36:59 -0800 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id g1EEatd14310 for ; Thu, 14 Feb 2002 15:36:56 +0100 (MET) Received: from mowp002a.mowp.siemens.ru (mowp002a.mowp.siemens.ru [149.202.148.230]) by mail2.siemens.de (8.11.6/8.11.6) with ESMTP id g1EETPg11389 for ; Thu, 14 Feb 2002 15:29:25 +0100 (MET) Received: by mowp002a.mowp.siemens.ru with Internet Mail Service (5.5.2653.19) id <16ZYPQM3>; Thu, 14 Feb 2002 17:32:16 +0300 Received: from mw1g17c (mw1g17c.mow.siemens.ru [149.202.201.33]) by MOWD019A.mow.siemens.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 17LB2018; Thu, 14 Feb 2002 17:32:57 +0300 From: Borsenkow Andrej To: "'Richard Gooch'" , "'Thierry Vignaud'" Cc: "'Juan Quintela'" , kernel@mandrakesoft.com, "'devfs mailing list'" , "'Frederic Lepied'" Subject: RE: [kernel] char/raw.c devfs support Date: Thu, 14 Feb 2002 17:32:50 +0300 Message-ID: <000201c1b564$7b15fc40$21c9ca95@mow.siemens.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <200202080557.g185vlc14531@vindaloo.ras.ucalgary.ca> x-mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-devfs@oss.sgi.com Precedence: bulk > > Thierry Vignaud writes: > > Juan Quintela writes: > > > > > > BTW, Juan: I haven't yet received a followup about what was going > > > > wrong with your /lib/dev-state and /dev/log problems. > > > > > > I don't know really, I think that it was a devfsd package here that > > > got a wrong config file :( > > > > the /dev/log problem has been traced back to the following portion of > > /etc/rc.d/rc.sysinit : > > > > > > # Restart devfsd actions now that the filesystems are ready > > if [ -c /dev/.devfsd ]; then > > if [ -x /sbin/devfsd ]; then > > # cleanup dynamic desktop directories before calling devfsd actions > > rm -f /usr/share/gnome/desktop/* /usr/share/apps/kdesktop/Desktop/* > > > > action "Running devfsd actions: " killall -HUP devfsd > > fi > > fi > > > > > > sometimes, the bootstraping process wait for minutes because of some > > sort of race between devfsd and minilogd (remeber syslogd hasn't yet > > be started since it's a service launched after rc.sysinit let rc play > > with init levels. > > > > we've found a solution: make a service of the previous piece of script > > and run it very late (ie in 99th position whereas syslogd service has > > a priority of 88). > > Ug! I hate work-arounds. Can you put time into helping track down > whether there is a bug in devfs or devfsd, and what the cause of the > bug is? > /dev/log is saved in /lib/dev-state first time after clean start and restored upon starting devfsd. It means, /dev/log exists *immediately* and devfsd tries to do openlog() before real syslog is started early in rc.sysinit. When syslog is started it tries to remove /dev/log: 2628 unlink("/dev/log") = -1 ENOENT (No such file or directory) 2628 socket(PF_UNIX, SOCK_DGRAM, 0) = 0 2628 bind(0, {sin_family=AF_UNIX, path="/dev/log"}, 10) = 0 2628 chmod("/dev/log", 0666) = 0 Any chance of deadlock here? Openlog does connect and send: 2678 connect(1, {sin_family=AF_UNIX, path="/dev/log"}, 16) = 0 2678 send(1, "<13>Feb 14 17:26:06 bor: test", 29, 0) = 29 2678 rt_sigaction(SIGPIPE, {SIG_DFL}, NULL, 8) = 0 2678 close(1) = 0 which means /dev/log is not empty (whatever it means) when syslog tries to remove it because nobody was there to consume message yet? -andrej From owner-devfs@oss.sgi.com Thu Feb 14 07:54:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1EFspX14263 for devfs-outgoing; Thu, 14 Feb 2002 07:54:51 -0800 Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1EFsl914260 for ; Thu, 14 Feb 2002 07:54:47 -0800 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id g1EEsid28966 for ; Thu, 14 Feb 2002 15:54:44 +0100 (MET) Received: from mowp002a.mowp.siemens.ru (mowp002a.mowp.siemens.ru [149.202.148.230]) by mail2.siemens.de (8.11.6/8.11.6) with ESMTP id g1EElEg23788 for ; Thu, 14 Feb 2002 15:47:14 +0100 (MET) Received: by mowp002a.mowp.siemens.ru with Internet Mail Service (5.5.2653.19) id <16ZYPQN1>; Thu, 14 Feb 2002 17:50:05 +0300 Received: from mw1g17c (mw1g17c.mow.siemens.ru [149.202.201.33]) by MOWD019A.mow.siemens.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 17LB202H; Thu, 14 Feb 2002 17:50:09 +0300 From: Borsenkow Andrej To: "'devfs mailing list'" Subject: stracing devfsd Date: Thu, 14 Feb 2002 17:50:02 +0300 Message-ID: <000301c1b566$e241a890$21c9ca95@mow.siemens.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 x-mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-devfs@oss.sgi.com Precedence: bulk Debugging recent problem here I pbserved following: stracing devfsd for the first time using simple strace -p 69 ends spitting out a screenfull of lines las one being output to stderr about broken pipe. Stracing the same devfsd the second time puts it into endless loop scanning /dev recursively and running REGISTER actions; if strace is killed immediately, devfsd calms down after 18s CPU time! (as reported by ps). I guess it is some bad interaction - devfsd does /dev rescan *every* time it receives an event from devfs and stracing process interrupts read. Is this rescan every time really necessary? Do I correctly understand it tries to compensate for missing events? But then it could check for overrun_count? Doing full rescan is very inefficient, at least here where we apply permissions every time. -andrej From owner-devfs@oss.sgi.com Thu Feb 14 08:24:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1EGOjn15124 for devfs-outgoing; Thu, 14 Feb 2002 08:24:45 -0800 Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1EGOd915121 for ; Thu, 14 Feb 2002 08:24:39 -0800 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id g1EFObd23591 for ; Thu, 14 Feb 2002 16:24:37 +0100 (MET) Received: from mowp002a.mowp.siemens.ru (mowp002a.mowp.siemens.ru [149.202.148.230]) by mail2.siemens.de (8.11.6/8.11.6) with ESMTP id g1EFH7g15030 for ; Thu, 14 Feb 2002 16:17:07 +0100 (MET) Received: by mowp002a.mowp.siemens.ru with Internet Mail Service (5.5.2653.19) id <16ZYPQ3T>; Thu, 14 Feb 2002 18:19:57 +0300 Received: from mw1g17c (mw1g17c.mow.siemens.ru [149.202.201.33]) by MOWD019A.mow.siemens.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 17LB20N8; Thu, 14 Feb 2002 18:20:37 +0300 From: Borsenkow Andrej To: "'Richard Gooch'" , "'Thierry Vignaud'" Cc: "'Juan Quintela'" , kernel@mandrakesoft.com, "'devfs mailing list'" , "'Frederic Lepied'" Subject: RE: [kernel] char/raw.c devfs support Date: Thu, 14 Feb 2002 18:20:31 +0300 Message-ID: <000601c1b56b$241be2e0$21c9ca95@mow.siemens.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <000201c1b564$7b15fc40$21c9ca95@mow.siemens.ru> x-mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-devfs@oss.sgi.com Precedence: bulk > > /dev/log is saved in /lib/dev-state first time after clean start and > restored upon starting devfsd. It means, /dev/log exists *immediately* > and devfsd tries to do openlog() before real syslog is started early in > rc.sysinit. When syslog is started it tries to remove /dev/log: > > 2628 unlink("/dev/log") = -1 ENOENT (No such file or > directory) > 2628 socket(PF_UNIX, SOCK_DGRAM, 0) = 0 > 2628 bind(0, {sin_family=AF_UNIX, path="/dev/log"}, 10) = 0 > 2628 chmod("/dev/log", 0666) = 0 > > Any chance of deadlock here? Openlog does connect and send: > > 2678 connect(1, {sin_family=AF_UNIX, path="/dev/log"}, 16) = 0 > 2678 send(1, "<13>Feb 14 17:26:06 bor: test", 29, 0) = 29 > 2678 rt_sigaction(SIGPIPE, {SIG_DFL}, NULL, 8) = 0 > 2678 close(1) = 0 > > which means /dev/log is not empty (whatever it means) when syslog tries > to remove it because nobody was there to consume message yet? > Getting these straces I killed syslog and restarted it. As a result I could not login anymore, all attempts just hung after accepting password. Unfortunately, SysRq-T responded only with "show tasks" explanation, but it did exactly that when system hung on startup. So it is very possibly related to /dev/log being created too early. Of course system should not deadlock which means some kernel problem. It may be possible to reproduce it this way - killing and restarting syslog and waiting for some time (assuming some activity with /dev/log). -andrej From owner-devfs@oss.sgi.com Thu Feb 14 08:33:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1EGX3R15291 for devfs-outgoing; Thu, 14 Feb 2002 08:33:03 -0800 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 g1EGWv915283 for ; Thu, 14 Feb 2002 08:32:58 -0800 Received: from lyta.coker.com.au (localhost [127.0.0.1]) by tsv.sws.net.au (Postfix) with ESMTP id B600F9265F; Fri, 15 Feb 2002 02:32:55 +1100 (EST) Received: from there (lyta [127.0.0.1]) by lyta.coker.com.au (Postfix) with SMTP id F0114C5B8; Fri, 15 Feb 2002 02:34:03 +1100 (EST) Content-Type: text/plain; charset="iso-8859-1" From: Russell Coker Reply-To: Russell Coker To: Borsenkow Andrej , "'devfs mailing list'" Subject: Re: stracing devfsd Date: Fri, 15 Feb 2002 02:34:03 +1100 X-Mailer: KMail [version 1.3.2] References: <000301c1b566$e241a890$21c9ca95@mow.siemens.ru> In-Reply-To: <000301c1b566$e241a890$21c9ca95@mow.siemens.ru> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020214153404.F0114C5B8@lyta.coker.com.au> Sender: owner-devfs@oss.sgi.com Precedence: bulk On Fri, 15 Feb 2002 01:50, Borsenkow Andrej wrote: > Debugging recent problem here I pbserved following: > > stracing devfsd for the first time using simple > > strace -p 69 > > ends spitting out a screenfull of lines las one being output to stderr > about broken pipe. > > Stracing the same devfsd the second time puts it into endless loop > scanning /dev recursively and running REGISTER actions; if strace is > killed immediately, devfsd calms down after 18s CPU time! (as reported > by ps). I guess it is some bad interaction - devfsd does /dev rescan > *every* time it receives an event from devfs and stracing process > interrupts read. > > Is this rescan every time really necessary? Do I correctly understand it > tries to compensate for missing events? But then it could check for > overrun_count? Doing full rescan is very inefficient, at least here > where we apply permissions every time. When you attach to it the devfsd process will think that it has been sent a SIGHUP and will reload it's config (which involves simulating events for all active devices). I think this is a bug, but haven't felt inclined to submit a patch as stracing devfsd isn't something you often want to do and code bloat is undesired. Also while on this topic, don't run gdb on devfsd from within X. The X server opens new devices if you try to change virtual consoles and often at other times opens device files. If devfsd is blocked then the kernel will block all open() calls for /dev, this can result in a system deadlock that can only be killed by a SAK. -- 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 Thu Feb 14 10:42:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1EIgCV29313 for devfs-outgoing; Thu, 14 Feb 2002 10:42:12 -0800 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 g1EIg5929309 for ; Thu, 14 Feb 2002 10:42:06 -0800 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id g1EHfko12085; Thu, 14 Feb 2002 10:41:46 -0700 Date: Thu, 14 Feb 2002 10:41:46 -0700 Message-Id: <200202141741.g1EHfko12085@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Russell Coker Cc: Borsenkow Andrej , "'devfs mailing list'" Subject: Re: stracing devfsd In-Reply-To: <20020214153404.F0114C5B8@lyta.coker.com.au> References: <000301c1b566$e241a890$21c9ca95@mow.siemens.ru> <20020214153404.F0114C5B8@lyta.coker.com.au> Sender: owner-devfs@oss.sgi.com Precedence: bulk Russell Coker writes: > On Fri, 15 Feb 2002 01:50, Borsenkow Andrej wrote: > > Debugging recent problem here I pbserved following: > > > > stracing devfsd for the first time using simple > > > > strace -p 69 > > > > ends spitting out a screenfull of lines las one being output to stderr > > about broken pipe. > > > > Stracing the same devfsd the second time puts it into endless loop > > scanning /dev recursively and running REGISTER actions; if strace is > > killed immediately, devfsd calms down after 18s CPU time! (as reported > > by ps). I guess it is some bad interaction - devfsd does /dev rescan > > *every* time it receives an event from devfs and stracing process > > interrupts read. > > > > Is this rescan every time really necessary? Do I correctly understand it > > tries to compensate for missing events? But then it could check for > > overrun_count? Doing full rescan is very inefficient, at least here > > where we apply permissions every time. > > When you attach to it the devfsd process will think that it has been sent a > SIGHUP and will reload it's config (which involves simulating events for all > active devices). > > I think this is a bug, but haven't felt inclined to submit a patch > as stracing devfsd isn't something you often want to do and code > bloat is undesired. True, but it's actually quite cheap to fix this. Since I've already got a SIGHUP handler, I can set a flag there and test for it in do_servicing(). If I get an EINTR from sig!=SIGHUP, I'll just ignore it. Sound reasonable? > Also while on this topic, don't run gdb on devfsd from within X. > The X server opens new devices if you try to change virtual consoles > and often at other times opens device files. If devfsd is blocked > then the kernel will block all open() calls for /dev, this can > result in a system deadlock that can only be killed by a SAK. Ouch. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Thu Feb 14 10:48:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1EIme429398 for devfs-outgoing; Thu, 14 Feb 2002 10:48:40 -0800 Received: from office.mandrakesoft.com (office.mandrakesoft.com [195.68.114.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1EImX929394 for ; Thu, 14 Feb 2002 10:48:34 -0800 Received: from localhost.mandrakesoft.com ([192.168.100.108]) by office.mandrakesoft.com (8.9.3/8.9.3) with ESMTP id SAA09420; Thu, 14 Feb 2002 18:45:15 +0100 Received: by localhost.mandrakesoft.com (Postfix, from userid 501) id 4E5ED16EFB; Thu, 14 Feb 2002 18:44:05 +0100 (CET) To: Borsenkow Andrej Cc: "'Richard Gooch'" , "'Thierry Vignaud'" , kernel@mandrakesoft.com, "'devfs mailing list'" , "'Frederic Lepied'" Subject: Re: [kernel] char/raw.c devfs support References: <000601c1b56b$241be2e0$21c9ca95@mow.siemens.ru> X-Url: http://www.lfcia.org/~quintela From: Juan Quintela In-Reply-To: <000601c1b56b$241be2e0$21c9ca95@mow.siemens.ru> Date: 14 Feb 2002 18:44:05 +0100 Message-ID: Lines: 46 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-devfs@oss.sgi.com Precedence: bulk >>>>> "borsenkow" == Borsenkow Andrej writes: >> >> /dev/log is saved in /lib/dev-state first time after clean start and >> restored upon starting devfsd. It means, /dev/log exists *immediately* >> and devfsd tries to do openlog() before real syslog is started early borsenkow> in >> rc.sysinit. When syslog is started it tries to remove /dev/log: >> >> 2628 unlink("/dev/log") = -1 ENOENT (No such file or >> directory) >> 2628 socket(PF_UNIX, SOCK_DGRAM, 0) = 0 >> 2628 bind(0, {sin_family=AF_UNIX, path="/dev/log"}, 10) = 0 >> 2628 chmod("/dev/log", 0666) = 0 >> >> Any chance of deadlock here? Openlog does connect and send: >> >> 2678 connect(1, {sin_family=AF_UNIX, path="/dev/log"}, 16) = 0 >> 2678 send(1, "<13>Feb 14 17:26:06 bor: test", 29, 0) = 29 >> 2678 rt_sigaction(SIGPIPE, {SIG_DFL}, NULL, 8) = 0 >> 2678 close(1) = 0 >> >> which means /dev/log is not empty (whatever it means) when syslog borsenkow> tries >> to remove it because nobody was there to consume message yet? >> borsenkow> Getting these straces I killed syslog and restarted it. As a result I borsenkow> could not login anymore, all attempts just hung after accepting borsenkow> password. Unfortunately, SysRq-T responded only with "show tasks" borsenkow> explanation, but it did exactly that when system hung on startup. borsenkow> So it is very possibly related to /dev/log being created too early. Of borsenkow> course system should not deadlock which means some kernel problem. It borsenkow> may be possible to reproduce it this way - killing and restarting syslog borsenkow> and waiting for some time (assuming some activity with /dev/log). Problem is in devfs :((( But I completeely failed to explain it to Richard how devfsd protocol broke when there are two programs removing/creating /dev/log. Later, Juan. -- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy From owner-devfs@oss.sgi.com Thu Feb 14 10:50:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1EIoTc29440 for devfs-outgoing; Thu, 14 Feb 2002 10:50:29 -0800 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 g1EIoK929435 for ; Thu, 14 Feb 2002 10:50:20 -0800 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id g1EHo2G12220; Thu, 14 Feb 2002 10:50:02 -0700 Date: Thu, 14 Feb 2002 10:50:02 -0700 Message-Id: <200202141750.g1EHo2G12220@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Juan Quintela Cc: Borsenkow Andrej , "'Thierry Vignaud'" , kernel@mandrakesoft.com, "'devfs mailing list'" , "'Frederic Lepied'" Subject: Re: [kernel] char/raw.c devfs support In-Reply-To: References: <000601c1b56b$241be2e0$21c9ca95@mow.siemens.ru> Sender: owner-devfs@oss.sgi.com Precedence: bulk Juan Quintela writes: > >>>>> "borsenkow" == Borsenkow Andrej writes: > > >> > >> /dev/log is saved in /lib/dev-state first time after clean start and > >> restored upon starting devfsd. It means, /dev/log exists *immediately* > >> and devfsd tries to do openlog() before real syslog is started early > borsenkow> in > >> rc.sysinit. When syslog is started it tries to remove /dev/log: > >> > >> 2628 unlink("/dev/log") = -1 ENOENT (No such file or > >> directory) > >> 2628 socket(PF_UNIX, SOCK_DGRAM, 0) = 0 > >> 2628 bind(0, {sin_family=AF_UNIX, path="/dev/log"}, 10) = 0 > >> 2628 chmod("/dev/log", 0666) = 0 > >> > >> Any chance of deadlock here? Openlog does connect and send: > >> > >> 2678 connect(1, {sin_family=AF_UNIX, path="/dev/log"}, 16) = 0 > >> 2678 send(1, "<13>Feb 14 17:26:06 bor: test", 29, 0) = 29 > >> 2678 rt_sigaction(SIGPIPE, {SIG_DFL}, NULL, 8) = 0 > >> 2678 close(1) = 0 > >> > >> which means /dev/log is not empty (whatever it means) when syslog > borsenkow> tries > >> to remove it because nobody was there to consume message yet? > >> > > borsenkow> Getting these straces I killed syslog and restarted it. As a result I > borsenkow> could not login anymore, all attempts just hung after accepting > borsenkow> password. Unfortunately, SysRq-T responded only with "show tasks" > borsenkow> explanation, but it did exactly that when system hung on startup. > > borsenkow> So it is very possibly related to /dev/log being created too early. Of > borsenkow> course system should not deadlock which means some kernel problem. It > borsenkow> may be possible to reproduce it this way - killing and restarting syslog > borsenkow> and waiting for some time (assuming some activity with /dev/log). > > Problem is in devfs :((( But I completeely failed to explain it to > Richard how devfsd protocol broke when there are two programs > removing/creating /dev/log. Um, what do you mean you failed to explain it? Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Thu Feb 14 11:11:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1EJBtY29971 for devfs-outgoing; Thu, 14 Feb 2002 11:11:55 -0800 Received: from office.mandrakesoft.com (office.mandrakesoft.com [195.68.114.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1EJBi929965 for ; Thu, 14 Feb 2002 11:11:45 -0800 Received: from localhost.mandrakesoft.com ([192.168.100.108]) by office.mandrakesoft.com (8.9.3/8.9.3) with ESMTP id TAA09631; Thu, 14 Feb 2002 19:09:24 +0100 Received: by localhost.mandrakesoft.com (Postfix, from userid 501) id 239B516EFB; Thu, 14 Feb 2002 19:08:14 +0100 (CET) To: Richard Gooch Cc: Borsenkow Andrej , "'Thierry Vignaud'" , kernel@mandrakesoft.com, "'devfs mailing list'" , "'Frederic Lepied'" Subject: Re: [kernel] char/raw.c devfs support References: <000601c1b56b$241be2e0$21c9ca95@mow.siemens.ru> <200202141750.g1EHo2G12220@vindaloo.ras.ucalgary.ca> X-Url: http://www.lfcia.org/~quintela From: Juan Quintela In-Reply-To: <200202141750.g1EHo2G12220@vindaloo.ras.ucalgary.ca> Date: 14 Feb 2002 19:08:14 +0100 Message-ID: Lines: 87 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-devfs@oss.sgi.com Precedence: bulk >>>>> "richard" == Richard Gooch writes: richard> Um, what do you mean you failed to explain it? 1) that I explain myself badly :( 2) that you didn't understand the problem from my explanation :( Here are the traces that I had at the moment: I still has that bug with 2.4.18-pre7, and it has this patch applied. stack traces again (in kernel land). p1: schedule() devfs_de_revalidate_wait() cached_lookup() lookup_hash() sys_unlink() system_call() p2: schedule() wait_for_devfsd_finished() devfs_lookup(() lookup_hash() unix_bind() sys_bind() sys_socketcall() system_call() the thing that they are tring to create/remove is /dev/log. And devfsd is already running in that state: __schedule() __down() __down_failed() __text_lock_namei() This has worked normally until now, it has beggining to fail yesterday. What the tasks are doing: the task does basically: unlink("/dev/log"); bind("/dev/log") -> type AF_LOCAL, we have already did the socket() listen() if (fork) exit(); else { stat(/dev/log); stat(/dev/log); (we need to make sure that nobody has changed the link under our toes exit(); } As you can see, the user space does something that looks normal to do, and the kernel handling that part looks strange. Other thing that is perhaps a bug in our setup is that we are storing /dev/log in /lib/dev-state, and probably we shouldn't(this was Andrej discovery), but that is a different story, i.e. I think that: create unix socket reboot devfsd recreate socket unlink socket create socket again stat the name of the socket should not hang devfsd. I hope that this time I has been clearer, I the info is not enough, I will try to get an userspace trace of devfsd while this is happening, but I don't have a good idea on how to do it yet. Later, Juan. -- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy From owner-devfs@oss.sgi.com Thu Feb 14 11:13:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1EJDQp30020 for devfs-outgoing; Thu, 14 Feb 2002 11:13:26 -0800 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 g1EJDK930015 for ; Thu, 14 Feb 2002 11:13:20 -0800 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id g1EICuX12721; Thu, 14 Feb 2002 11:12:56 -0700 Date: Thu, 14 Feb 2002 11:12:56 -0700 Message-Id: <200202141812.g1EICuX12721@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Russell Coker Cc: devfs@oss.sgi.com, kaos@ocs.com.au Subject: Re: modprobe /dev/* In-Reply-To: <20020214131017.D2E62C73D@lyta.coker.com.au> References: <20020214131017.D2E62C73D@lyta.coker.com.au> Sender: owner-devfs@oss.sgi.com Precedence: bulk Russell Coker writes: > At linux.conf.au Keith and I were looking into devfs module loading issues. > > We noticed that the distribution he was running (some RPM distribution) had a > lot of scripts with code like the following: > > for n in /dev/dsp* ; do > ... > done > > This results in `modprobe "/dev/dsp*"` being run once for the for line and > then a second time in the body of the loop. > > We discovered that a significant number of useless modprobe runs > were removed when we added the following to devfsd.conf: > LOOKUP \*$ IGNORE > > Before the following line in the default config: > LOOKUP .* MODLOAD > > I think that this should be part of the default config file. This sounds to me like it's a script problem. For bash-v1.x I have: allow_null_glob_expansion= and for bash-v2.x I have: shopt -s nullglob Why not just fix the scripts? A trailing '*' might be used in a filename, so I'd prefer not to break that. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Thu Feb 14 11:55:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1EJtro31594 for devfs-outgoing; Thu, 14 Feb 2002 11:55:53 -0800 Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1EJtk931590 for ; Thu, 14 Feb 2002 11:55:47 -0800 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id g1EIthd10386; Thu, 14 Feb 2002 19:55:44 +0100 (MET) Received: from MOWD019A.mow.siemens.ru ([139.24.18.3]) by mail1.siemens.de (8.11.6/8.11.6) with ESMTP id g1EIthp09515; Thu, 14 Feb 2002 19:55:43 +0100 (MET) Received: by mowd019a.mow.siemens.ru with Internet Mail Service (5.5.2653.19) id <17LBJAC4>; Thu, 14 Feb 2002 21:59:19 +0300 Received: from [149.202.201.201] (149.202.201.201 [149.202.201.201]) by MOWD019A.mow.siemens.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 17LBJACT; Thu, 14 Feb 2002 21:59:17 +0300 From: Borsenkow Andrej To: Juan Quintela Cc: Richard Gooch , "'Thierry Vignaud'" , Mandrake kernel list , "'devfs mailing list'" , "'Frederic Lepied'" Subject: Re: [kernel] char/raw.c devfs support In-Reply-To: References: <000601c1b56b$241be2e0$21c9ca95@mow.siemens.ru> <200202141750.g1EHo2G12220@vindaloo.ras.ucalgary.ca> Content-Type: text/plain; charset=KOI8-R X-Mailer: Evolution/1.0.21mdk Date: 14 Feb 2002 21:55:34 +0300 Message-Id: <1013712941.3522.12.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g1EJtl931591 Sender: owner-devfs@oss.sgi.com Precedence: bulk On , 2002-02-14 at 21:08, Juan Quintela wrote: > > Other thing that is perhaps a bug in our setup is that we are storing > /dev/log in /lib/dev-state, and probably we shouldn't(this was Andrej > discovery), but that is a different story, i.e. I think that: > No it won't help if I understand how initlog/minilogd are working. If they use /dev/log (and string shows /dev/log as available) then when devfsd is started /dev/log has already been created. It is trivial to prevent restoring it - just do ^log$ IGNORE - but I am not sure if it really helps. The main problem being I still do not know how to reliably reproduce it. -andrej From owner-devfs@oss.sgi.com Thu Feb 14 18:14:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1F2EUR04613 for devfs-outgoing; Thu, 14 Feb 2002 18:14:30 -0800 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 g1F2EN904603 for ; Thu, 14 Feb 2002 18:14:23 -0800 Received: from lyta.coker.com.au (localhost [127.0.0.1]) by tsv.sws.net.au (Postfix) with ESMTP id A587A9265F; Fri, 15 Feb 2002 12:14:20 +1100 (EST) Received: from there (lyta [127.0.0.1]) by lyta.coker.com.au (Postfix) with SMTP id 3C352C699; Fri, 15 Feb 2002 12:15:18 +1100 (EST) Content-Type: text/plain; charset="iso-8859-1" From: Russell Coker Reply-To: Russell Coker To: Richard Gooch Subject: Re: modprobe /dev/* Date: Fri, 15 Feb 2002 12:15:17 +1100 X-Mailer: KMail [version 1.3.2] Cc: devfs@oss.sgi.com, kaos@ocs.com.au References: <20020214131017.D2E62C73D@lyta.coker.com.au> <200202141812.g1EICuX12721@vindaloo.ras.ucalgary.ca> In-Reply-To: <200202141812.g1EICuX12721@vindaloo.ras.ucalgary.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020215011518.3C352C699@lyta.coker.com.au> Sender: owner-devfs@oss.sgi.com Precedence: bulk On Fri, 15 Feb 2002 05:12, Richard Gooch wrote: > > At linux.conf.au Keith and I were looking into devfs module loading > > issues. > > > > We noticed that the distribution he was running (some RPM distribution) > > had a lot of scripts with code like the following: > > > > for n in /dev/dsp* ; do > > ... > > done > > > > This results in `modprobe "/dev/dsp*"` being run once for the for line > > and then a second time in the body of the loop. > > > > We discovered that a significant number of useless modprobe runs > > were removed when we added the following to devfsd.conf: > > LOOKUP \*$ IGNORE > > > > Before the following line in the default config: > > LOOKUP .* MODLOAD > > > > I think that this should be part of the default config file. > > This sounds to me like it's a script problem. For bash-v1.x I have: > allow_null_glob_expansion= > > and for bash-v2.x I have: > shopt -s nullglob So that means one modprobe invocation instead of two. Also "ls /dev/foo*" will result in modprobe being called when (IMHO) it shouldn't. > Why not just fix the scripts? A trailing '*' might be used in a > filename, so I'd prefer not to break that. Why would someone want to put a '*' character into a devfs file name? I have never heard of any version of Unix using '*' or '?' characters in file names for /dev, why would someone want to start such foolishness now? -- 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 Thu Feb 14 18:19:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1F2J2f04769 for devfs-outgoing; Thu, 14 Feb 2002 18:19:02 -0800 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 g1F2Iv904766 for ; Thu, 14 Feb 2002 18:18:57 -0800 Received: from lyta.coker.com.au (localhost [127.0.0.1]) by tsv.sws.net.au (Postfix) with ESMTP id 2D5CD9265F; Fri, 15 Feb 2002 12:18:55 +1100 (EST) Received: from there (lyta [127.0.0.1]) by lyta.coker.com.au (Postfix) with SMTP id 3486FC94E; Fri, 15 Feb 2002 12:20:06 +1100 (EST) Content-Type: text/plain; charset="iso-8859-1" From: Russell Coker Reply-To: Russell Coker To: Richard Gooch Subject: Re: stracing devfsd Date: Fri, 15 Feb 2002 12:20:05 +1100 X-Mailer: KMail [version 1.3.2] Cc: Borsenkow Andrej , "'devfs mailing list'" References: <000301c1b566$e241a890$21c9ca95@mow.siemens.ru> <20020214153404.F0114C5B8@lyta.coker.com.au> <200202141741.g1EHfko12085@vindaloo.ras.ucalgary.ca> In-Reply-To: <200202141741.g1EHfko12085@vindaloo.ras.ucalgary.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020215012006.3486FC94E@lyta.coker.com.au> Sender: owner-devfs@oss.sgi.com Precedence: bulk On Fri, 15 Feb 2002 04:41, Richard Gooch wrote: > > When you attach to it the devfsd process will think that it has been sent > > a SIGHUP and will reload it's config (which involves simulating events > > for all active devices). > > > > I think this is a bug, but haven't felt inclined to submit a patch > > as stracing devfsd isn't something you often want to do and code > > bloat is undesired. > > True, but it's actually quite cheap to fix this. Since I've already > got a SIGHUP handler, I can set a flag there and test for it in > do_servicing(). If I get an EINTR from sig!=SIGHUP, I'll just ignore > it. > > Sound reasonable? Yes. > > Also while on this topic, don't run gdb on devfsd from within X. > > The X server opens new devices if you try to change virtual consoles > > and often at other times opens device files. If devfsd is blocked > > then the kernel will block all open() calls for /dev, this can > > result in a system deadlock that can only be killed by a SAK. > > Ouch. Yes. Everyone who does any sort of debugging of system processes like devfsd should have SAK enabled. Otherwise a hard reset would be required. -- 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 Thu Feb 14 18:28:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1F2Si604874 for devfs-outgoing; Thu, 14 Feb 2002 18:28:44 -0800 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 g1F2Sc904871 for ; Thu, 14 Feb 2002 18:28:38 -0800 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id g1F1SJD19770; Thu, 14 Feb 2002 18:28:19 -0700 Date: Thu, 14 Feb 2002 18:28:19 -0700 Message-Id: <200202150128.g1F1SJD19770@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Russell Coker Cc: devfs@oss.sgi.com, kaos@ocs.com.au Subject: Re: modprobe /dev/* In-Reply-To: <20020215011518.3C352C699@lyta.coker.com.au> References: <20020214131017.D2E62C73D@lyta.coker.com.au> <200202141812.g1EICuX12721@vindaloo.ras.ucalgary.ca> <20020215011518.3C352C699@lyta.coker.com.au> Sender: owner-devfs@oss.sgi.com Precedence: bulk Russell Coker writes: > On Fri, 15 Feb 2002 05:12, Richard Gooch wrote: > > > At linux.conf.au Keith and I were looking into devfs module loading > > > issues. > > > > > > We noticed that the distribution he was running (some RPM distribution) > > > had a lot of scripts with code like the following: > > > > > > for n in /dev/dsp* ; do > > > ... > > > done > > > > > > This results in `modprobe "/dev/dsp*"` being run once for the for line > > > and then a second time in the body of the loop. > > > > > > We discovered that a significant number of useless modprobe runs > > > were removed when we added the following to devfsd.conf: > > > LOOKUP \*$ IGNORE > > > > > > Before the following line in the default config: > > > LOOKUP .* MODLOAD > > > > > > I think that this should be part of the default config file. > > > > This sounds to me like it's a script problem. For bash-v1.x I have: > > allow_null_glob_expansion= > > > > and for bash-v2.x I have: > > shopt -s nullglob > > So that means one modprobe invocation instead of two. No, it means none, since the shell will do a directory read to expand /dev/dsp* and will get no entries. Thus no LOOKUP events. > Also "ls /dev/foo*" will result in modprobe being called when (IMHO) > it shouldn't. Not with null globbing. > > Why not just fix the scripts? A trailing '*' might be used in a > > filename, so I'd prefer not to break that. > > Why would someone want to put a '*' character into a devfs file > name? I have never heard of any version of Unix using '*' or '?' > characters in file names for /dev, why would someone want to start > such foolishness now? I just prefer to avoid imposing policy if I don't have to. And since this seems to be a problem with the scripts... Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Sat Feb 16 07:12:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1GFCIg28557 for devfs-outgoing; Sat, 16 Feb 2002 07:12:18 -0800 Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1GFCA928553 for ; Sat, 16 Feb 2002 07:12:11 -0800 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id g1GEC7p05359; Sat, 16 Feb 2002 15:12:07 +0100 (MET) Received: from MOWD019A.mow.siemens.ru ([139.24.18.3]) by mail1.siemens.de (8.11.6/8.11.6) with ESMTP id g1GEC7p03556; Sat, 16 Feb 2002 15:12:07 +0100 (MET) Received: by mowd019a.mow.siemens.ru with Internet Mail Service (5.5.2653.19) id ; Sat, 16 Feb 2002 17:15:46 +0300 Received: from [149.202.201.201] (149.202.201.201 [149.202.201.201]) by MOWD019A.mow.siemens.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FA3WY21G; Sat, 16 Feb 2002 17:15:42 +0300 From: Borsenkow Andrej To: Cooker list Cc: Kamil Toman , devfs mailing list Subject: Re: [Cooker] /dev/pts/* permissions (cannot use "talk") (devfs?) In-Reply-To: <20020216004808.GA3223@sarah.kolej.mff.cuni.cz> References: <20020216004808.GA3223@sarah.kolej.mff.cuni.cz> Content-Type: text/plain; charset=UTF-8 X-Mailer: Evolution/1.0.21mdk Date: 16 Feb 2002 17:11:45 +0300 Message-Id: <1013868723.2458.39.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g1GFCC928554 Sender: owner-devfs@oss.sgi.com Precedence: bulk On Сбт, 2002-02-16 at 03:48, Martin Mačok wrote: > Hi, > when I run rxvt/xterm/konsole/gnome-terminal, my pseudoterminals at > /dev/pts/* does not own group "tty" so I cannot use > % mesg y > mesg: error: tty device is not owned by group `tty' > > and users cannot "talk" to each other. > > When I log on text console, permission for /dev/vc/* are owned by > group tty so talk here works. > > Is it problem with devfs? pam? init? > Well, I am really confused here. - permissions for console (/dev/tty*) are (most probably) set either by mingetty or by login. Neither pam nor devfsd are responsible for them. - Mandrake by default is using devpts so you could specify group by adding gid=5 in /etc/fstab to /dev/pts line. You could also change modes from default 644 if you want - still devfs documentation tells us we should not use devpts with devfs; and I am not sure who wins. pty.c registers /dev/pts/? with current owner and 600 permissions; and here I have {pts/1}% ll /dev/pts итого 0 crw--w---- 1 bor bor 136, 0 Фев 16 16:11 0 crw------- 1 bor bor 136, 1 Фев 16 17:05 1 crw------- 1 bor bor 136, 2 Фев 16 17:03 2 crw------- 1 bor bor 136, 3 Фев 16 17:04 3 that looks like pts/0 got permissions from devpts and others from devfs because default mount for devpts here is 640 - and /etc/devfsd.conf tells us we must not fiddle with /dev/pt{s,y} permissions. So could anybody give ultimate answer on - should devpts be used in presence of devfs? - how to manage permissions of pts - i.e. why they cannot be managed by devfsd? -andrej From owner-devfs@oss.sgi.com Sat Feb 16 20:51:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1H4pkT04149 for devfs-outgoing; Sat, 16 Feb 2002 20:51:46 -0800 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 g1H4pf904145 for ; Sat, 16 Feb 2002 20:51:41 -0800 Received: from lyta.coker.com.au (localhost [127.0.0.1]) by tsv.sws.net.au (Postfix) with ESMTP id A4B829265F; Sun, 17 Feb 2002 14:51:38 +1100 (EST) Received: from there (lyta [127.0.0.1]) by lyta.coker.com.au (Postfix) with SMTP id 3958890; Sun, 17 Feb 2002 14:52:52 +1100 (EST) Content-Type: text/plain; charset="utf-8" From: Russell Coker Reply-To: Russell Coker To: Borsenkow Andrej , Cooker list Subject: Re: [Cooker] /dev/pts/* permissions (cannot use "talk") (devfs?) Date: Sun, 17 Feb 2002 14:52:49 +1100 X-Mailer: KMail [version 1.3.2] Cc: Kamil Toman , devfs mailing list References: <20020216004808.GA3223@sarah.kolej.mff.cuni.cz> <1013868723.2458.39.camel@localhost.localdomain> In-Reply-To: <1013868723.2458.39.camel@localhost.localdomain> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020217035252.3958890@lyta.coker.com.au> Sender: owner-devfs@oss.sgi.com Precedence: bulk On Sun, 17 Feb 2002 01:11, Borsenkow Andrej wrote: > > when I run rxvt/xterm/konsole/gnome-terminal, my pseudoterminals at > > /dev/pts/* does not own group "tty" so I cannot use > > % mesg y > > mesg: error: tty device is not owned by group `tty' > > > > and users cannot "talk" to each other. > > > > When I log on text console, permission for /dev/vc/* are owned by > > group tty so talk here works. > > > > Is it problem with devfs? pam? init? > > Well, I am really confused here. > > - permissions for console (/dev/tty*) are (most probably) set either by > mingetty or by login. Neither pam nor devfsd are responsible for them. Here's an extract from the default devfsd.conf for Debian: # set the group to "tty" of the pseudo-tty device. This is necessary for # correct operation of mesg(1). REGISTER ^pts/.* PERMISSIONS -1.tty 0600 This allows "mesg" to work as expected and seems to be working well for all Debian devfsd users! -- 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 Feb 17 15:02:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1HN28m23454 for devfs-outgoing; Sun, 17 Feb 2002 15:02:08 -0800 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 g1HN1x923445 for ; Sun, 17 Feb 2002 15:02:00 -0800 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id g1HLqFq20730; Sun, 17 Feb 2002 14:52:15 -0700 Date: Sun, 17 Feb 2002 14:52:15 -0700 Message-Id: <200202172152.g1HLqFq20730@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Borsenkow Andrej Cc: Cooker list , Kamil Toman , devfs mailing list Subject: Re: [Cooker] /dev/pts/* permissions (cannot use "talk") (devfs?) In-Reply-To: <1013868723.2458.39.camel@localhost.localdomain> References: <20020216004808.GA3223@sarah.kolej.mff.cuni.cz> <1013868723.2458.39.camel@localhost.localdomain> Sender: owner-devfs@oss.sgi.com Precedence: bulk Borsenkow Andrej writes: > On Сбт, 2002-02-16 at 03:48, Martin Mačok wrote: > > Hi, > > when I run rxvt/xterm/konsole/gnome-terminal, my pseudoterminals at > > /dev/pts/* does not own group "tty" so I cannot use > > % mesg y > > mesg: error: tty device is not owned by group `tty' > > > > and users cannot "talk" to each other. > > > > When I log on text console, permission for /dev/vc/* are owned by > > group tty so talk here works. > > > > Is it problem with devfs? pam? init? > > > > Well, I am really confused here. > > - permissions for console (/dev/tty*) are (most probably) set either by > mingetty or by login. Neither pam nor devfsd are responsible for them. > > - Mandrake by default is using devpts so you could specify group by > adding gid=5 in /etc/fstab to /dev/pts line. You could also change modes > from default 644 if you want > > - still devfs documentation tells us we should not use devpts with > devfs; and I am not sure who wins. pty.c registers /dev/pts/? with > current owner and 600 permissions; and here I have > > {pts/1}% ll /dev/pts > итого 0 > crw--w---- 1 bor bor 136, 0 Фев 16 16:11 0 > crw------- 1 bor bor 136, 1 Фев 16 17:05 1 > crw------- 1 bor bor 136, 2 Фев 16 17:03 2 > crw------- 1 bor bor 136, 3 Фев 16 17:04 3 > > that looks like pts/0 got permissions from devpts and others from devfs > because default mount for devpts here is 640 I doubt that. More likely some programme changed the permissions for pts/0 (perhaps xconsole or th Gnome equivalent?). > - and /etc/devfsd.conf tells us we must not fiddle with /dev/pt{s,y} > permissions. Well, it doesn't quite say that. What it says is that you don't want to have permissions persistence for /dev/pt{s,y} devices. That doesn't mean you can't or shouldn't have a PERMISSIONS action. > So could anybody give ultimate answer on > > - should devpts be used in presence of devfs? No. > - how to manage permissions of pts - i.e. why they cannot be managed by > devfsd? As Russell said in his follow-up, use a PERMISSIONS action on the REGISTER event. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Sun Feb 17 15:07:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1HN78623539 for devfs-outgoing; Sun, 17 Feb 2002 15:07:08 -0800 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 g1HN73923536 for ; Sun, 17 Feb 2002 15:07:03 -0800 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id g1HM6mH20932; Sun, 17 Feb 2002 15:06:48 -0700 Date: Sun, 17 Feb 2002 15:06:48 -0700 Message-Id: <200202172206.g1HM6mH20932@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Russell Coker Cc: Borsenkow Andrej , Cooker list , Kamil Toman , devfs mailing list Subject: Re: [Cooker] /dev/pts/* permissions (cannot use "talk") (devfs?) In-Reply-To: <20020217035252.3958890@lyta.coker.com.au> References: <20020216004808.GA3223@sarah.kolej.mff.cuni.cz> <1013868723.2458.39.camel@localhost.localdomain> <20020217035252.3958890@lyta.coker.com.au> Sender: owner-devfs@oss.sgi.com Precedence: bulk Russell Coker writes: > On Sun, 17 Feb 2002 01:11, Borsenkow Andrej wrote: > > > when I run rxvt/xterm/konsole/gnome-terminal, my pseudoterminals at > > > /dev/pts/* does not own group "tty" so I cannot use > > > % mesg y > > > mesg: error: tty device is not owned by group `tty' > > > > > > and users cannot "talk" to each other. > > > > > > When I log on text console, permission for /dev/vc/* are owned by > > > group tty so talk here works. > > > > > > Is it problem with devfs? pam? init? > > > > Well, I am really confused here. > > > > - permissions for console (/dev/tty*) are (most probably) set either by > > mingetty or by login. Neither pam nor devfsd are responsible for them. > > Here's an extract from the default devfsd.conf for Debian: > # set the group to "tty" of the pseudo-tty device. This is necessary for > # correct operation of mesg(1). > REGISTER ^pts/.* PERMISSIONS -1.tty 0600 > > This allows "mesg" to work as expected and seems to be working well for all > Debian devfsd users! Good idea. I've done something similar in my sample devfsd.conf file. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Sun Feb 17 19:17:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1I3Hij29326 for devfs-outgoing; Sun, 17 Feb 2002 19:17:44 -0800 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 g1I3HX929322 for ; Sun, 17 Feb 2002 19:17:33 -0800 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id g1I27vg23255; Sun, 17 Feb 2002 19:07:57 -0700 Date: Sun, 17 Feb 2002 19:07:57 -0700 Message-Id: <200202180207.g1I27vg23255@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Borsenkow Andrej Cc: "'Thierry Vignaud'" , "'Juan Quintela'" , kernel@mandrakesoft.com, "'devfs mailing list'" , "'Frederic Lepied'" Subject: RE: [kernel] char/raw.c devfs support In-Reply-To: <000601c1b56b$241be2e0$21c9ca95@mow.siemens.ru> References: <000201c1b564$7b15fc40$21c9ca95@mow.siemens.ru> <000601c1b56b$241be2e0$21c9ca95@mow.siemens.ru> Sender: owner-devfs@oss.sgi.com Precedence: bulk Borsenkow Andrej writes: > > > > /dev/log is saved in /lib/dev-state first time after clean start and > > restored upon starting devfsd. It means, /dev/log exists *immediately* > > and devfsd tries to do openlog() before real syslog is started early > in > > rc.sysinit. When syslog is started it tries to remove /dev/log: > > > > 2628 unlink("/dev/log") = -1 ENOENT (No such file or > > directory) > > 2628 socket(PF_UNIX, SOCK_DGRAM, 0) = 0 > > 2628 bind(0, {sin_family=AF_UNIX, path="/dev/log"}, 10) = 0 > > 2628 chmod("/dev/log", 0666) = 0 > > > > Any chance of deadlock here? Openlog does connect and send: > > > > 2678 connect(1, {sin_family=AF_UNIX, path="/dev/log"}, 16) = 0 > > 2678 send(1, "<13>Feb 14 17:26:06 bor: test", 29, 0) = 29 > > 2678 rt_sigaction(SIGPIPE, {SIG_DFL}, NULL, 8) = 0 > > 2678 close(1) = 0 > > > > which means /dev/log is not empty (whatever it means) when syslog > tries > > to remove it because nobody was there to consume message yet? > > Getting these straces I killed syslog and restarted it. As a result I > could not login anymore, all attempts just hung after accepting > password. Unfortunately, SysRq-T responded only with "show tasks" > explanation, but it did exactly that when system hung on startup. > > So it is very possibly related to /dev/log being created too > early. Of course system should not deadlock which means some kernel > problem. It may be possible to reproduce it this way - killing and > restarting syslog and waiting for some time (assuming some activity > with /dev/log). Agreed, the system shouldn't deadlock. And creating /dev/log early shouldn't matter either, since if devfsd restores /dev/log, then devfs won't be sending a CREATE event anyway, so that won't cause devfsd to open the syslog. Also, even if devfsd does try to open the syslog, if there isn't a syslogd running to listen to connections on /dev/log, then openlog(3) should fail and return immediately. At least, that's what I'd expect. Someone want to confirm this? Perhaps a good starting point would be to hack the devfsd code to print diagnostic messages when calling openlog(3) (before and after) to make sure that openlog(3) isn't hanging somehow. If openlog(3) *is* hanging, then I'd like to understand *why*. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Sun Feb 17 23:12:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1I7CI110847 for devfs-outgoing; Sun, 17 Feb 2002 23:12:18 -0800 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 g1I7CE910843 for ; Sun, 17 Feb 2002 23:12:14 -0800 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id g1I6C4L25410; Sun, 17 Feb 2002 23:12:04 -0700 Date: Sun, 17 Feb 2002 23:12:04 -0700 Message-Id: <200202180612.g1I6C4L25410@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: linux-kernel@vger.kernel.org, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: devfsd-v1.3.24 available Sender: owner-devfs@oss.sgi.com Precedence: bulk Hi, all. I've just released version 1.3.24 of my devfsd (devfs daemon) at: http://www.atnf.csiro.au/~rgooch/linux/ Tarball directly available from: ftp://ftp.??.kernel.org/pub/linux/daemons/devfsd/devfsd.tar.gz AND: ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/daemons/devfsd/devfsd.tar.gz This works with devfs-patch-v130, kernel 2.3.46 and devfs-patch-v99.7 (or later). The main changes are: - Do not re-read config file if signals other than SIGHUP are caught - Added sample configuration entries to devfsd.conf for PTY ownerships. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Sun Feb 17 23:23:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1I7N3Y11099 for devfs-outgoing; Sun, 17 Feb 2002 23:23:03 -0800 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 g1I7Mp911095 for ; Sun, 17 Feb 2002 23:22:51 -0800 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id g1I6Mkd25562; Sun, 17 Feb 2002 23:22:46 -0700 Date: Sun, 17 Feb 2002 23:22:46 -0700 Message-Id: <200202180622.g1I6Mkd25562@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Juan Quintela Cc: Borsenkow Andrej , "'Thierry Vignaud'" , kernel@mandrakesoft.com, "'devfs mailing list'" , "'Frederic Lepied'" Subject: Re: [kernel] char/raw.c devfs support In-Reply-To: References: <000601c1b56b$241be2e0$21c9ca95@mow.siemens.ru> <200202141750.g1EHo2G12220@vindaloo.ras.ucalgary.ca> Sender: owner-devfs@oss.sgi.com Precedence: bulk Juan Quintela writes: > >>>>> "richard" == Richard Gooch writes: > > > richard> Um, what do you mean you failed to explain it? > > 1) that I explain myself badly :( > > 2) that you didn't understand the problem from my explanation :( > > Here are the traces that I had at the moment: > > I still has that bug with 2.4.18-pre7, and it has this patch applied. > > stack traces again (in kernel land). > > p1: > schedule() > devfs_de_revalidate_wait() > cached_lookup() > lookup_hash() > sys_unlink() > system_call() > > p2: > > schedule() > wait_for_devfsd_finished() > devfs_lookup(() > lookup_hash() > unix_bind() > sys_bind() > sys_socketcall() > system_call() > > the thing that they are tring to create/remove is /dev/log. > > And devfsd is already running in that state: > > __schedule() > __down() > __down_failed() > __text_lock_namei() > > This has worked normally until now, it has beggining to fail yesterday. > > What the tasks are doing: > > the task does basically: > > unlink("/dev/log"); > bind("/dev/log") -> type AF_LOCAL, we have already did the socket() > listen() > if (fork) > exit(); > else { > stat(/dev/log); > > stat(/dev/log); (we need to make sure that nobody has changed the > link under our toes > exit(); > } > > As you can see, the user space does something that looks normal to do, > and the kernel handling that part looks strange. Well, I don't see what's strange about the kernel handling part. Devfs is enforcing serialisation, but that isn't supposed to cause deadlocks. > Other thing that is perhaps a bug in our setup is that we are storing > /dev/log in /lib/dev-state, and probably we shouldn't(this was Andrej > discovery), but that is a different story, i.e. I think that: I don't think that restoring /dev/log should cause this problem. I haven't seen a failure path that would cause this deadlock. > create unix socket > reboot > devfsd recreate socket > unlink socket > create socket again > stat the name of the socket > > should not hang devfsd. Agreed. > I hope that this time I has been clearer, I the info is not enough, I > will try to get an userspace trace of devfsd while this is happening, > but I don't have a good idea on how to do it yet. This is the key. So far I have not received *any* indication of what devfsd is doing. The kernel trace you provided seems incomplete (somewhere in the call stack I'd expect to see system_call(), and we don't). And I've not yet received strace output of devfsd. I've just released devfsd v1.3.24, which fixes the problem with devfsd re-reading the configuration file while being traced, so please go forth and trace it. If necessary, hack your boot scripts to trace devfsd. But somehow I've got to see what devfsd is trying to do, and the events that led up to it. At the moment, all I've been told is that devfsd is waiting on some resource, but no clue as to what resource. Note that the strace output could be quite large, so you might like to just send it to me, rather than spamming the list. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Mon Feb 18 07:22:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1IFMPb00761 for devfs-outgoing; Mon, 18 Feb 2002 07:22:25 -0800 Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1IFMJ900758 for ; Mon, 18 Feb 2002 07:22:19 -0800 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id g1IEMGp28732 for ; Mon, 18 Feb 2002 15:22:16 +0100 (MET) Received: from mowp002a.mowp.siemens.ru (mowp002a.mowp.siemens.ru [149.202.148.230]) by mail2.siemens.de (8.11.6/8.11.6) with ESMTP id g1IEMFg11052 for ; Mon, 18 Feb 2002 15:22:15 +0100 (MET) Received: by mowp002a.mowp.siemens.ru with Internet Mail Service (5.5.2653.19) id <16ZYPTH1>; Mon, 18 Feb 2002 17:25:10 +0300 Received: from mw1g17c (mw1g17c.mow.siemens.ru [149.202.201.33]) by MOWD019A.mow.siemens.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FA3WYNPK; Mon, 18 Feb 2002 17:25:51 +0300 From: Borsenkow Andrej To: "'devfs mailing list'" Cc: Robert.Fox@t-online.de Subject: Possible problem with devfs removable drives patch Date: Mon, 18 Feb 2002 17:25:37 +0300 Message-ID: <001d01c1b888$22bc3fb0$21c9ca95@mow.siemens.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <1014039780.22997.0.camel@foxbase> x-mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-devfs@oss.sgi.com Precedence: bulk Mandrake 2.4.17-18mdk based on 2.4.18-rc1 On first (?) bootup after install the following interesting message (error -17): PIIX4: chipset revision 1 PIIX4: not 100% native mode: will probe irqs later ide0: BM-DMA at 0x1840-0x1847, BIOS settings: hda:pio, hdb:pio ide1: BM-DMA at 0x1848-0x184f, BIOS settings: hdc:DMA, hdd:pio hda: LS-120 CSMO 05 UHD Floppy, ATAPI FLOPPY drive hdc: IBM-DTTA-371440, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hdc: 28229040 sectors (14453 MB) w/462KiB Cache, CHS=28005/16/63, UDMA(33) hda: No disk in drive hda: 123264kB, 963/8/32 CHS, 533 kBps, 512 sector size, 720 rpm devfs_register(disc): could not append to parent, err: -17 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Partition check: /dev/ide/host0/bus1/target0/lun0: [PTBL] [1757/255/63] p3 < p5 p6 p7 p8 > /lib/dev-state does not contain any manual entries, so it looks like some internal kernel problem. Besides as I understood it was the first boot after installation. Full logs are available. Robert, I hope you give permissions to ask you in case of any additional information needed? > > > See my stuff.tar.bz2 attachment on previous post - that contains: > > > > > > > Oh yes, sorry. > > > > Was it the very first boot after install? What is in /lib/dev-state? (ls > > -lR /lib/dev-state) > > > > -andrej > > > > Per your request: > > From owner-devfs@oss.sgi.com Mon Feb 18 12:32:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1IKW0j09520 for devfs-outgoing; Mon, 18 Feb 2002 12:32:00 -0800 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 g1IKVs909517 for ; Mon, 18 Feb 2002 12:31:54 -0800 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id g1IJMIs03173; Mon, 18 Feb 2002 12:22:18 -0700 Date: Mon, 18 Feb 2002 12:22:18 -0700 Message-Id: <200202181922.g1IJMIs03173@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Borsenkow Andrej Cc: "'devfs mailing list'" , Robert.Fox@t-online.de Subject: Re: Possible problem with devfs removable drives patch In-Reply-To: <001d01c1b888$22bc3fb0$21c9ca95@mow.siemens.ru> References: <1014039780.22997.0.camel@foxbase> <001d01c1b888$22bc3fb0$21c9ca95@mow.siemens.ru> Sender: owner-devfs@oss.sgi.com Precedence: bulk Borsenkow Andrej writes: > Mandrake 2.4.17-18mdk based on 2.4.18-rc1 > > On first (?) bootup after install the following interesting message > (error -17): > > PIIX4: chipset revision 1 > PIIX4: not 100% native mode: will probe irqs later > ide0: BM-DMA at 0x1840-0x1847, BIOS settings: hda:pio, hdb:pio > ide1: BM-DMA at 0x1848-0x184f, BIOS settings: hdc:DMA, hdd:pio > hda: LS-120 CSMO 05 UHD Floppy, ATAPI FLOPPY drive > hdc: IBM-DTTA-371440, ATA DISK drive > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > ide1 at 0x170-0x177,0x376 on irq 15 > hdc: 28229040 sectors (14453 MB) w/462KiB Cache, CHS=28005/16/63, > UDMA(33) > hda: No disk in drive > hda: 123264kB, 963/8/32 CHS, 533 kBps, 512 sector size, 720 rpm > devfs_register(disc): could not append to parent, err: -17 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Odd. This should never happen. If you look at the code for devfs_register_disc(), you will see the very first line: if (dev->part[minor].de) return; which prevents duplicate registrations. The only way I can see this failing is if the "disc" entry for a different device is registered, but *the parent directory names are the same*. You can test this by putting a debugging line two lines after the call to devfs_generate_path() thus: printk ("Constructed: \"%s\"", dirname + 3 + pos); and then send me the kernel messages between the PIIX4: message and the error message you highlighted. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Mon Feb 18 15:22:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1INMu101261 for devfs-outgoing; Mon, 18 Feb 2002 15:22:56 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1INMS901256 for ; Mon, 18 Feb 2002 15:22:28 -0800 Received: from zzz.zzz (CompactServ-SUrNet.ll.surnet.ru [195.54.9.58]) 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 OAA09252 for ; Mon, 18 Feb 2002 14:22:10 -0800 (PST) mail_from (zzz@cd-club.ru) Date: Tue, 19 Feb 2002 03:16:16 +0500 From: Denis Zaitsev To: Richard Gooch Cc: devfs@oss.sgi.com Subject: [PATCH] a little strings-aware code change Message-ID: <20020219031616.E1639@zzz.zzz.zzz> References: <200202180612.g1I6C4L25410@vindaloo.ras.ucalgary.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-devfs@oss.sgi.com Precedence: bulk This little patch does nothing with the functionality of devfsd, but with the C code. There are a number of constructions like: [PFXLEN = strlen(prefix);] if (strncmp(str, prefix, PFXLEN) == 0) do_something_with(str + PFXLEN); It is not the best way to do such a things. The idea is to implement the special function, which will test the string for some prefix and return the address of a place of the string after that prefix or NULL in case of an absence of the success. The construction above becomes better: if (ptr= strtry(str, prefix)) do_something_with(ptr); And the new function itself is more lightweight than alone strncmp, and just much more effective than in a couple. It is good again. So, all the idea seems to be healthy. I've called this function "strtry", as it tries its arg for the given prefix. Richard, please, apply this patch, if you find it useful. It is against devfsd-1.3.22. By the way, I've arranged the strrchr (devname, '/') + 1 stuff, so this thing to be done once instead of multiply times in the original. diff -dpruN devfsd-1.3.22.orig/GNUmakefile devfsd-1.3.22/GNUmakefile --- devfsd-1.3.22.orig/GNUmakefile Tue Jan 15 09:09:29 2002 +++ devfsd-1.3.22/GNUmakefile Sun Feb 17 22:03:11 2002 @@ -58,4 +58,5 @@ distclean: clean # Dependencies: made by hand -devfsd.o: devfsd.h version.h +devfsd.o: devfsd.h strtry.h version.h +compat_name.o: strtry.h diff -dpruN devfsd-1.3.22.orig/compat_name.c devfsd-1.3.22/compat_name.c --- devfsd-1.3.22.orig/compat_name.c Mon Jan 21 02:05:57 2002 +++ devfsd-1.3.22/compat_name.c Sun Feb 17 22:34:04 2002 @@ -71,6 +71,7 @@ # include # include #endif +#include "strtry.h" #ifndef IDE6_MAJOR /* In case we're building with an ancient kernel */ # define IDE6_MAJOR 88 @@ -137,35 +138,31 @@ const char *get_old_name (const char *de */ { const char *compat_name = NULL; - char *ptr; + char *ptr, *rsl = strrchr (devname, '/') + 1;/* right slash + 1 */ struct translate_struct *trans; for (trans = translate_table; trans->match != NULL; ++trans) - { - size_t len = strlen (trans->match); - - if (strncmp (devname, trans->match, len) == 0) + if (ptr = strtry (devname, trans->match)) { - if (trans->format == NULL) return (devname + len); - sprintf (buffer, trans->format, devname + len); + if (trans->format == NULL) return (ptr); + sprintf (buffer, trans->format, ptr); return (buffer); } - } - if (strncmp (devname, "sbp/", 4) == 0) + if (strtry (devname, "sbp/")) { sprintf (buffer, "sbpcd%u", minor); compat_name = buffer; } - else if (strncmp (devname, "scsi/", 5) == 0) + else if (strtry (devname, "scsi/")) { /* All SCSI devices */ if (strcmp (devname + namelen - 7, "generic") == 0) { sprintf (buffer, "sg%u", minor); compat_name = buffer; } - else if (strncmp (ptr = (strrchr (devname, '/') + 1), "mt", 2) == 0) + else if (ptr = strtry (rsl, "mt")) { - char mode = ptr[2]; + char mode = *ptr; if (mode == 'n') mode = '\0'; sprintf (buffer, "nst%u%c", minor & 0x1f, mode); @@ -179,15 +176,15 @@ const char *get_old_name (const char *de } else if (strcmp (devname + namelen - 4, "disc") == 0) compat_name = write_old_sd_name (buffer, major, minor, ""); - else if (strncmp (ptr = (strrchr (devname, '/') + 1), "part", 4) == 0) - compat_name = write_old_sd_name (buffer, major, minor, ptr + 4); + else if (ptr = strtry (rsl, "part")) + compat_name = write_old_sd_name (buffer, major, minor, ptr); return (compat_name); } - else if (strncmp (devname, "ide/host", 8) == 0) + else if (strtry (devname, "ide/host")) { /* All IDE devices */ - if (strncmp (ptr = (strrchr (devname, '/') + 1), "mt", 2) == 0) + if (ptr = strtry (rsl, "mt")) { - sprintf (buffer, "%sht%d", ptr + 2, minor & 0x7f); + sprintf (buffer, "%sht%d", ptr, minor & 0x7f); compat_name = buffer; } else if (strcmp (devname + namelen - 4, "disc") == 0) @@ -196,10 +193,10 @@ const char *get_old_name (const char *de get_old_ide_name (major, minor) ); compat_name = buffer; } - else if (strncmp (ptr = (strrchr (devname, '/') + 1), "part", 4) == 0) + else if (ptr = strtry (rsl, "part")) { sprintf (buffer, "hd%c%s", - get_old_ide_name (major, minor), ptr + 4); + get_old_ide_name (major, minor), ptr); compat_name = buffer; } else if (strcmp (devname + namelen - 2, "cd") == 0) @@ -210,20 +207,20 @@ const char *get_old_name (const char *de } return (compat_name); } - else if (strncmp (devname, "vcc/", 4) == 0) + else if (ptr = strtry (devname, "vcc/")) { - sprintf (buffer, "vcs%s", devname + 4); + sprintf (buffer, "vcs%s", ptr); if (buffer[3] == '0') buffer[3] = '\0'; compat_name = buffer; } - else if (strncmp (devname, "pty/", 4) == 0) + else if (ptr = strtry (devname, "pty/")) { - int index = atoi (devname + 5); + int index = atoi (ptr + 1); const char *pty1 = "pqrstuvwxyzabcde"; const char *pty2 = "0123456789abcdef"; sprintf (buffer, "%cty%c%c", - (devname[4] == 'm') ? 'p' : 't', + (*ptr == 'm') ? 'p' : 't', pty1[index >> 4], pty2[index & 0x0f]); compat_name = buffer; } diff -dpruN devfsd-1.3.22.orig/devfsd.c devfsd-1.3.22/devfsd.c --- devfsd-1.3.22.orig/devfsd.c Mon Jan 21 02:07:31 2002 +++ devfsd-1.3.22/devfsd.c Sun Feb 17 21:58:18 2002 @@ -273,6 +273,7 @@ #include #include #include "devfsd.h" +#include "strtry.h" #include "version.h" #ifndef RTLD_DEFAULT /* Libc 5 doesn't define it, but it works */ @@ -1416,7 +1417,7 @@ static void action_compat (const struct { const char *compat_name = NULL; const char *dest_name = info->devname; - char *ptr; + char *ptr, *rsl = strrchr (info->devname, '/') + 1;/* right slash + 1 */ char compat_buf[STRING_LENGTH], dest_buf[STRING_LENGTH]; static char function_name[] = "action_compat"; @@ -1430,22 +1431,21 @@ static void action_compat (const struct break; case AC_MKNEWCOMPAT: case AC_RMNEWCOMPAT: - if (strncmp (info->devname, "scsi/", 5) == 0) + if (ptr = strtry (info->devname, "scsi/")) { int mode, host, bus, target, lun; - sscanf (info->devname + 5, "host%d/bus%d/target%d/lun%d/", + sscanf (ptr, "host%d/bus%d/target%d/lun%d/", &host, &bus, &target, &lun); compat_name = compat_buf; snprintf (dest_buf, sizeof (dest_buf), "../%s", info->devname); dest_name = dest_buf; - if (strncmp (ptr = (strrchr (info->devname, '/') + 1), "mt", 2) - == 0) + if (ptr = strtry (rsl, "mt")) { char rewind = info->devname[info->namelen - 1]; if (rewind != 'n') rewind = '\0'; - switch (ptr[2]) + switch (*ptr) { default: mode = 0; @@ -1472,36 +1472,33 @@ static void action_compat (const struct else if (strcmp (info->devname + info->namelen - 4, "disc") == 0) sprintf (compat_buf, "sd/c%db%dt%du%d", host, bus, target, lun); - else if (strncmp (ptr = (strrchr (info->devname, '/') + 1), "part", - 4) == 0) + else if (ptr = strtry (rsl, "part")) sprintf ( compat_buf, "sd/c%db%dt%du%dp%d", - host, bus, target, lun, atoi (ptr + 4) ); + host, bus, target, lun, atoi (ptr) ); else compat_name = NULL; } - else if (strncmp (info->devname, "ide/host", 8) == 0) + else if (ptr = strtry (info->devname, "ide/host")) { int host, bus, target, lun; - sscanf (info->devname + 4, "host%d/bus%d/target%d/lun%d/", + sscanf (ptr, "%d/bus%d/target%d/lun%d/", &host, &bus, &target, &lun); compat_name = compat_buf; - snprintf (dest_buf, sizeof (dest_buf), "../%s", info->devname + 4); + snprintf (dest_buf, sizeof (dest_buf), "../%s", ptr - 4); dest_name = dest_buf; if (strcmp (info->devname + info->namelen - 4, "disc") == 0) sprintf (compat_buf, "ide/hd/c%db%dt%du%d", host, bus, target, lun); - else if (strncmp (ptr = (strrchr (info->devname, '/') + 1), "part", - 4) == 0) + else if (ptr = strtry (rsl, "part")) sprintf ( compat_buf, "ide/hd/c%db%dt%du%dp%d", - host, bus, target, lun, atoi (ptr + 4) ); + host, bus, target, lun, atoi (ptr) ); else if (strcmp (info->devname + info->namelen - 2, "cd") == 0) sprintf (compat_buf, "ide/cd/c%db%dt%du%d", host, bus, target,lun); - else if (strncmp (ptr = (strrchr (info->devname, '/') + 1), "mt", - 2) == 0) + else if (ptr = strtry (rsl, "mt")) snprintf (compat_buf, sizeof (compat_buf), "ide/mt/c%db%dt%du%d%s", - host, bus, target, lun, ptr + 2); + host, bus, target, lun, ptr); else compat_name = NULL; } break; diff -dpruN devfsd-1.3.22.orig/strtry.h devfsd-1.3.22/strtry.h --- devfsd-1.3.22.orig/strtry.h Thu Jan 1 05:00:00 1970 +++ devfsd-1.3.22/strtry.h Sun Feb 17 21:38:10 2002 @@ -0,0 +1,11 @@ +/* + Tries if a string begins from some prefix. Returns an address of a + char after that prefix or NULL. +*/ +extern inline +char *strtry(const char *s, const char *try) +{ + char c; + do if (!(c= *try++)) return (char*)s; + while (*s++ == c); return NULL; +} From owner-devfs@oss.sgi.com Mon Feb 18 22:53:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1J6r6r08365 for devfs-outgoing; Mon, 18 Feb 2002 22:53:06 -0800 Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1J6qt908361 for ; Mon, 18 Feb 2002 22:52:55 -0800 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id g1J5qrp12998 for ; Tue, 19 Feb 2002 06:52:53 +0100 (MET) Received: from mowp002a.mowp.siemens.ru (mowp002a.mowp.siemens.ru [149.202.148.230]) by mail2.siemens.de (8.11.6/8.11.6) with ESMTP id g1J5qqg16420 for ; Tue, 19 Feb 2002 06:52:52 +0100 (MET) Received: by mowp002a.mowp.siemens.ru with Internet Mail Service (5.5.2653.19) id <16ZYPT5M>; Tue, 19 Feb 2002 08:55:48 +0300 Received: from mw1g17c (mw1g17c.mow.siemens.ru [149.202.201.33]) by MOWD019A.mow.siemens.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FG4GH301; Tue, 19 Feb 2002 08:56:32 +0300 From: Borsenkow Andrej To: "'Richard Gooch'" Cc: "'devfs mailing list'" , Robert.Fox@t-online.de Subject: RE: Possible problem with devfs removable drives patch Date: Tue, 19 Feb 2002 08:56:05 +0300 Message-ID: <000001c1b90a$218af190$21c9ca95@mow.siemens.ru> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_01C1B923.46D9B030" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <200202181922.g1IJMIs03173@vindaloo.ras.ucalgary.ca> x-mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-devfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C1B923.46D9B030 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > > Odd. This should never happen. If you look at the code for > devfs_register_disc(), you will see the very first line: > if (dev->part[minor].de) return; > > which prevents duplicate registrations. The only way I can see this > failing is if the "disc" entry for a different device is registered, > but *the parent directory names are the same*. You can test this by > putting a debugging line two lines after the call to > devfs_generate_path() thus: > printk ("Constructed: \"%s\"", dirname + 3 + pos); > > and then send me the kernel messages between the PIIX4: message and > the error message you highlighted. You mean attached patch? Robert could you try it? -andrej ------=_NextPart_000_0001_01C1B923.46D9B030 Content-Type: application/octet-stream; name="check.c.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="check.c.diff" --- linux-2.4.17-18mdk/fs/partitions/check.c.orig Thu Feb 14 20:55:18 = 2002=0A= +++ linux-2.4.17-18mdk/fs/partitions/check.c Mon Feb 18 23:17:56 = 2002=0A= @@ -310,6 +310,7 @@=0A= pos =3D devfs_generate_path (dir, dirname + 3, sizeof dirname-3);=0A= if (pos < 0) return;=0A= strncpy (dirname + pos, "../", 3);=0A= + printk ("Constructed: \"%s\"", dirname + 3 + pos);=0A= }=0A= else {=0A= /* Unaware driver: construct "real" directory */=0A= ------=_NextPart_000_0001_01C1B923.46D9B030-- From owner-devfs@oss.sgi.com Mon Feb 18 23:17:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1J7H9T08731 for devfs-outgoing; Mon, 18 Feb 2002 23:17:09 -0800 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 g1J7H5908727 for ; Mon, 18 Feb 2002 23:17:05 -0800 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id g1J697G11167; Mon, 18 Feb 2002 23:09:07 -0700 Date: Mon, 18 Feb 2002 23:09:07 -0700 Message-Id: <200202190609.g1J697G11167@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Borsenkow Andrej Cc: "'devfs mailing list'" , Robert.Fox@t-online.de Subject: RE: Possible problem with devfs removable drives patch In-Reply-To: <000001c1b90a$218af190$21c9ca95@mow.siemens.ru> References: <200202181922.g1IJMIs03173@vindaloo.ras.ucalgary.ca> <000001c1b90a$218af190$21c9ca95@mow.siemens.ru> Sender: owner-devfs@oss.sgi.com Precedence: bulk Borsenkow Andrej writes: > This is a multi-part message in MIME format. > > Odd. This should never happen. If you look at the code for > > devfs_register_disc(), you will see the very first line: > > if (dev->part[minor].de) return; > > > > which prevents duplicate registrations. The only way I can see this > > failing is if the "disc" entry for a different device is registered, > > but *the parent directory names are the same*. You can test this by > > putting a debugging line two lines after the call to > > devfs_generate_path() thus: > > printk ("Constructed: \"%s\"", dirname + 3 + pos); > > > > and then send me the kernel messages between the PIIX4: message and > > the error message you highlighted. > > You mean attached patch? Robert could you try it? Yes, that patch is correct. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Fri Feb 22 00:33:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1M8XVX25290 for devfs-outgoing; Fri, 22 Feb 2002 00:33:31 -0800 Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1M8XL925287 for ; Fri, 22 Feb 2002 00:33:22 -0800 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id g1M7XGp08565 for ; Fri, 22 Feb 2002 08:33:16 +0100 (MET) Received: from mowp002a.mowp.siemens.ru (mowp002a.mowp.siemens.ru [149.202.148.230]) by mail3.siemens.de (8.11.6/8.11.6) with ESMTP id g1M7XEk18078 for ; Fri, 22 Feb 2002 08:33:15 +0100 (MET) Received: by mowp002a.mowp.siemens.ru with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Feb 2002 10:36:15 +0300 Received: from mw1g17c (mw1g17c.mow.siemens.ru [149.202.201.33]) by MOWD019A.mow.siemens.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FMZ9AJ0D; Fri, 22 Feb 2002 10:37:00 +0300 From: Borsenkow Andrej To: "'Richard Gooch'" Cc: "'devfs mailing list'" , Robert.Fox@t-online.de, "'Paul Bristow'" , kernel@mandrakesoft.com Subject: RE: Possible problem with devfs removable drives patch Date: Fri, 22 Feb 2002 10:36:29 +0300 Message-ID: <003301c1bb73$a4973290$21c9ca95@mow.siemens.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 x-mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <200202181922.g1IJMIs03173@vindaloo.ras.ucalgary.ca> Sender: owner-devfs@oss.sgi.com Precedence: bulk > > Borsenkow Andrej writes: > > Mandrake 2.4.17-18mdk based on 2.4.18-rc1 > > > > On first (?) bootup after install the following interesting message > > (error -17): > > > > PIIX4: chipset revision 1 > > PIIX4: not 100% native mode: will probe irqs later > > ide0: BM-DMA at 0x1840-0x1847, BIOS settings: hda:pio, hdb:pio > > ide1: BM-DMA at 0x1848-0x184f, BIOS settings: hdc:DMA, hdd:pio > > hda: LS-120 CSMO 05 UHD Floppy, ATAPI FLOPPY drive > > hdc: IBM-DTTA-371440, ATA DISK drive > > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > > ide1 at 0x170-0x177,0x376 on irq 15 > > hdc: 28229040 sectors (14453 MB) w/462KiB Cache, CHS=28005/16/63, > > UDMA(33) > > hda: No disk in drive > > hda: 123264kB, 963/8/32 CHS, 533 kBps, 512 sector size, 720 rpm > > devfs_register(disc): could not append to parent, err: -17 > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Odd. This should never happen. If you look at the code for > devfs_register_disc(), you will see the very first line: > if (dev->part[minor].de) return; > > which prevents duplicate registrations. I am sorry. Mandrake is using patch from Paul (that has been announced here as well, see another thread "Removeable Media, partitions and devfs?", patch is quite old actually. idefloppy_setup registers "disc" itself: /* * Driver initialization. */ static void idefloppy_setup (ide_drive_t *drive, idefloppy_floppy_t *floppy) { ... /* Always register drive with devfs */ floppy->de = devfs_register (drive->de, "disc", DEVFS_FL_REMOVABLE, major, minor, S_IFBLK | S_IRUGO | S_IWUGO, ide_fops, NULL); /* Create ide/fd entry in devfs */ idefloppy_devfs_handle = devfs_mk_dir(ide_devfs_handle,"fd",NULL); sprintf (fname, "c%db%dt%du%d", ^^^^^^^^^^^^^ Is not this a devfsd task? It looks like handle for ..../disc never makes it way into gendisk at this point. Is there newer patch? Paul, you probably should not create compat links in driver. Robert, sorry, had to do closer look but really had no time :( -andrej From owner-devfs@oss.sgi.com Fri Feb 22 00:40:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1M8eNd25393 for devfs-outgoing; Fri, 22 Feb 2002 00:40:23 -0800 Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1M8eJ925390 for ; Fri, 22 Feb 2002 00:40:19 -0800 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id g1M7eHd25858 for ; Fri, 22 Feb 2002 08:40:18 +0100 (MET) Received: from mowp002a.mowp.siemens.ru (mowp002a.mowp.siemens.ru [149.202.148.230]) by mail3.siemens.de (8.11.6/8.11.6) with ESMTP id g1M7eGk21810 for ; Fri, 22 Feb 2002 08:40:16 +0100 (MET) Received: by mowp002a.mowp.siemens.ru with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Feb 2002 10:43:16 +0300 Received: from mw1g17c (mw1g17c.mow.siemens.ru [149.202.201.33]) by MOWD019A.mow.siemens.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FMZ9AKA5; Fri, 22 Feb 2002 10:43:50 +0300 From: Borsenkow Andrej To: "'devfs mailing list'" Subject: Why removables revalidation works at all? Date: Fri, 22 Feb 2002 10:43:20 +0300 Message-ID: <003401c1bb74$995e7770$21c9ca95@mow.siemens.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 x-mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-devfs@oss.sgi.com Precedence: bulk I am sorry if this is stupid question but if it should not work if I understand devfs properly ... I mean these dd's in devfsd. What happens is User accesses /dev/sda4 | devfs lookup calls devfsd with LOOKUP | devfsd runs dd if=/dev/sda | |-----------------------+ | | devfsd returns to devfs devfs calls devfsd with REGISTER | | devfs repeats lookup devfsd creates /dev/sda4 | devfs returns /dev/sda4? So to my eyes there are two independent threads with obvious race condition here. There is no way known to me to synchronize them. It assumes second threads completes BEFORE devfs does second lookup. Is it really garanteed? -andrej From owner-devfs@oss.sgi.com Fri Feb 22 01:00:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1M90h526013 for devfs-outgoing; Fri, 22 Feb 2002 01:00:43 -0800 Received: from mailout10.sul.t-online.com (mailout10.sul.t-online.com [194.25.134.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1M90W926004 for ; Fri, 22 Feb 2002 01:00:33 -0800 Received: from fwd10.sul.t-online.de by mailout10.sul.t-online.com with smtp id 16eATy-00034R-01; Fri, 22 Feb 2002 08:51:06 +0100 Received: from foxbase (520063212430-0001@[217.85.44.185]) by fwd10.sul.t-online.com with esmtp id 16eATq-0VMOp6C; Fri, 22 Feb 2002 08:50:58 +0100 Subject: RE: Possible problem with devfs removable drives patch From: Robert.Fox@t-online.de (Robert Fox) To: Borsenkow Andrej Cc: "'Richard Gooch'" , "'devfs mailing list'" , "'Paul Bristow'" , kernel@mandrakesoft.com In-Reply-To: <003301c1bb73$a4973290$21c9ca95@mow.siemens.ru> References: <003301c1bb73$a4973290$21c9ca95@mow.siemens.ru> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.21mdk Date: 22 Feb 2002 08:51:11 +0100 Message-Id: <1014364286.3704.4.camel@foxbase> Mime-Version: 1.0 X-Sender: 520063212430-0001@t-dialin.net Sender: owner-devfs@oss.sgi.com Precedence: bulk So if I understand this correctly, there is an offending patch here and it's not a problem with Richard's code. That would mean I don't need to download the 2.4.18-rc2 kernel (as Richard suggested) and recompile it as refernece (without all the Mandrake patches) Thanks Andrej - you saved me some considerable time here! I guess I'll wait until someone says it's fixed and then test it . . . Have a nice weekend all! - Robert On Fri, 2002-02-22 at 08:36, Borsenkow Andrej wrote: > > > > Borsenkow Andrej writes: > > > Mandrake 2.4.17-18mdk based on 2.4.18-rc1 > > > > > > On first (?) bootup after install the following interesting message > > > (error -17): > > > > > > PIIX4: chipset revision 1 > > > PIIX4: not 100% native mode: will probe irqs later > > > ide0: BM-DMA at 0x1840-0x1847, BIOS settings: hda:pio, hdb:pio > > > ide1: BM-DMA at 0x1848-0x184f, BIOS settings: hdc:DMA, hdd:pio > > > hda: LS-120 CSMO 05 UHD Floppy, ATAPI FLOPPY drive > > > hdc: IBM-DTTA-371440, ATA DISK drive > > > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > > > ide1 at 0x170-0x177,0x376 on irq 15 > > > hdc: 28229040 sectors (14453 MB) w/462KiB Cache, CHS=28005/16/63, > > > UDMA(33) > > > hda: No disk in drive > > > hda: 123264kB, 963/8/32 CHS, 533 kBps, 512 sector size, 720 rpm > > > devfs_register(disc): could not append to parent, err: -17 > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > Odd. This should never happen. If you look at the code for > > devfs_register_disc(), you will see the very first line: > > if (dev->part[minor].de) return; > > > > which prevents duplicate registrations. > > I am sorry. Mandrake is using patch from Paul (that has been announced > here as well, see another thread "Removeable Media, partitions and > devfs?", patch is quite old actually. > > idefloppy_setup registers "disc" itself: > > /* > * Driver initialization. > */ > static void idefloppy_setup (ide_drive_t *drive, idefloppy_floppy_t > *floppy) > { > ... > /* Always register drive with devfs */ > floppy->de = devfs_register (drive->de, "disc", > DEVFS_FL_REMOVABLE, > major, minor, > S_IFBLK | S_IRUGO | S_IWUGO, > ide_fops, NULL); > /* Create ide/fd entry in devfs */ > idefloppy_devfs_handle = > devfs_mk_dir(ide_devfs_handle,"fd",NULL); > > sprintf (fname, "c%db%dt%du%d", > ^^^^^^^^^^^^^ > Is not this a devfsd task? > > It looks like handle for ..../disc never makes it way into gendisk at > this point. > > Is there newer patch? Paul, you probably should not create compat links > in driver. > > Robert, sorry, had to do closer look but really had no time :( > > -andrej From owner-devfs@oss.sgi.com Fri Feb 22 09:32:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1MHW4I15941 for devfs-outgoing; Fri, 22 Feb 2002 09:32:04 -0800 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 g1MHVp915938 for ; Fri, 22 Feb 2002 09:31:51 -0800 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id g1MGOto02062; Fri, 22 Feb 2002 09:24:55 -0700 Date: Fri, 22 Feb 2002 09:24:55 -0700 Message-Id: <200202221624.g1MGOto02062@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Borsenkow Andrej Cc: "'devfs mailing list'" , Robert.Fox@t-online.de, "'Paul Bristow'" , kernel@mandrakesoft.com Subject: RE: Possible problem with devfs removable drives patch In-Reply-To: <003301c1bb73$a4973290$21c9ca95@mow.siemens.ru> References: <200202181922.g1IJMIs03173@vindaloo.ras.ucalgary.ca> <003301c1bb73$a4973290$21c9ca95@mow.siemens.ru> Sender: owner-devfs@oss.sgi.com Precedence: bulk Borsenkow Andrej writes: > > > > Borsenkow Andrej writes: > > > Mandrake 2.4.17-18mdk based on 2.4.18-rc1 > > > > > > On first (?) bootup after install the following interesting message > > > (error -17): > > > > > > PIIX4: chipset revision 1 > > > PIIX4: not 100% native mode: will probe irqs later > > > ide0: BM-DMA at 0x1840-0x1847, BIOS settings: hda:pio, hdb:pio > > > ide1: BM-DMA at 0x1848-0x184f, BIOS settings: hdc:DMA, hdd:pio > > > hda: LS-120 CSMO 05 UHD Floppy, ATAPI FLOPPY drive > > > hdc: IBM-DTTA-371440, ATA DISK drive > > > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > > > ide1 at 0x170-0x177,0x376 on irq 15 > > > hdc: 28229040 sectors (14453 MB) w/462KiB Cache, CHS=28005/16/63, > > > UDMA(33) > > > hda: No disk in drive > > > hda: 123264kB, 963/8/32 CHS, 533 kBps, 512 sector size, 720 rpm > > > devfs_register(disc): could not append to parent, err: -17 > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > Odd. This should never happen. If you look at the code for > > devfs_register_disc(), you will see the very first line: > > if (dev->part[minor].de) return; > > > > which prevents duplicate registrations. > > I am sorry. Mandrake is using patch from Paul (that has been announced > here as well, see another thread "Removeable Media, partitions and > devfs?", patch is quite old actually. > > idefloppy_setup registers "disc" itself: > > /* > * Driver initialization. > */ > static void idefloppy_setup (ide_drive_t *drive, idefloppy_floppy_t > *floppy) > { > ... > /* Always register drive with devfs */ > floppy->de = devfs_register (drive->de, "disc", > DEVFS_FL_REMOVABLE, > major, minor, > S_IFBLK | S_IRUGO | S_IWUGO, > ide_fops, NULL); FUCK, FUCK, FUCK!!! No wonder I couldn't figure out what was going on. That's a hack that should never have gone into a released kernel! I even posted the correct fix to the devfs list sometime last year when this was being discussed, and eventually made it's way into 2.4.18-rc1. > /* Create ide/fd entry in devfs */ > idefloppy_devfs_handle = > devfs_mk_dir(ide_devfs_handle,"fd",NULL); > > sprintf (fname, "c%db%dt%du%d", > ^^^^^^^^^^^^^ > Is not this a devfsd task? YES! No driver should ever do something like this. > It looks like handle for ..../disc never makes it way into gendisk at > this point. > > Is there newer patch? Paul, you probably should not create compat > links in driver. Indeed. Or any other driver. I don't care what private patches people write, and they're free to publish them (provided ugly hacks are marked as such). But distribution vendors shouldn't release such patches to unsuspecting users. It doesn't look good. Better management of patches is required, which includes co-ordinating with developers if something hasn't yet reached the mainline kernel. Don't just throw in a hack. > Robert, sorry, had to do closer look but really had no time :( To address Robert's immediate problem (the error message he sees): he can ignore it. The problem is not fatal and will not cause data corruption. The only problem is that /proc/partitions will not have a devfs name for his removable media. And he will get an error message at bootup, to remind him of the evils of random hacks. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Fri Feb 22 09:39:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1MHdtk16046 for devfs-outgoing; Fri, 22 Feb 2002 09:39:55 -0800 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 g1MHdo916043 for ; Fri, 22 Feb 2002 09:39:50 -0800 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id g1MGUJ102155; Fri, 22 Feb 2002 09:30:19 -0700 Date: Fri, 22 Feb 2002 09:30:19 -0700 Message-Id: <200202221630.g1MGUJ102155@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Borsenkow Andrej Cc: "'devfs mailing list'" Subject: Re: Why removables revalidation works at all? In-Reply-To: <003401c1bb74$995e7770$21c9ca95@mow.siemens.ru> References: <003401c1bb74$995e7770$21c9ca95@mow.siemens.ru> Sender: owner-devfs@oss.sgi.com Precedence: bulk Borsenkow Andrej writes: > I am sorry if this is stupid question but if it should not work if I > understand devfs properly ... I mean these dd's in devfsd. > > What happens is > > User accesses /dev/sda4 > | > devfs lookup calls devfsd with LOOKUP > | > devfsd runs dd if=/dev/sda > | > |-----------------------+ > | | > devfsd returns to devfs devfs calls devfsd with REGISTER > | | > devfs repeats lookup devfsd creates /dev/sda4 > | > devfs returns /dev/sda4? > > So to my eyes there are two independent threads with obvious race > condition here. There is no way known to me to synchronize them. It > assumes second threads completes BEFORE devfs does second lookup. Is > it really garanteed? If I understand your question: you're wondering about races between devfsd and it's child dd process. There are no such races, because devfsd will wait for the child process to finish. Devfsd is explicitely single-threaded (i.e. it waits for children to finish) to avoid any such problems. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Fri Feb 22 09:51:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1MHpm616176 for devfs-outgoing; Fri, 22 Feb 2002 09:51:48 -0800 Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1MHpf916173 for ; Fri, 22 Feb 2002 09:51:42 -0800 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id g1MGped20636 for ; Fri, 22 Feb 2002 17:51:40 +0100 (MET) Received: from mowp002a.mowp.siemens.ru (mowp002a.mowp.siemens.ru [149.202.148.230]) by mail3.siemens.de (8.11.6/8.11.6) with ESMTP id g1MGpdk03130 for ; Fri, 22 Feb 2002 17:51:39 +0100 (MET) Received: by mowp002a.mowp.siemens.ru with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Feb 2002 19:54:40 +0300 Received: from mw1g17c (mw1g17c.mow.siemens.ru [149.202.201.33]) by MOWD019A.mow.siemens.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FMZ9A3A4; Fri, 22 Feb 2002 19:55:25 +0300 From: Borsenkow Andrej To: "'Richard Gooch'" Cc: "'devfs mailing list'" Subject: RE: Why removables revalidation works at all? Date: Fri, 22 Feb 2002 19:55:00 +0300 Message-ID: <008f01c1bbc1$aaaa3c10$21c9ca95@mow.siemens.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 x-mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <200202221630.g1MGUJ102155@vindaloo.ras.ucalgary.ca> Sender: owner-devfs@oss.sgi.com Precedence: bulk > > Borsenkow Andrej writes: > > I am sorry if this is stupid question but if it should not work if I > > understand devfs properly ... I mean these dd's in devfsd. > > > > What happens is > > > > User accesses /dev/sda4 > > | > > devfs lookup calls devfsd with LOOKUP > > | > > devfsd runs dd if=/dev/sda > > | > > |-----------------------+ > > | | > > devfsd returns to devfs devfs calls devfsd with REGISTER > > | | > > devfs repeats lookup devfsd creates /dev/sda4 > > | > > devfs returns /dev/sda4? > > > > So to my eyes there are two independent threads with obvious race > > condition here. There is no way known to me to synchronize them. It > > assumes second threads completes BEFORE devfs does second lookup. Is > > it really garanteed? > > If I understand your question: you're wondering about races between > devfsd and it's child dd process. There are no such races, because > devfsd will wait for the child process to finish. Devfsd is > explicitely single-threaded (i.e. it waits for children to finish) to > avoid any such problems. > Not quite. If it is single threaded the thread looks like: User lookup /dev/sda4 waits | devfs calls devfsd with LOOKUP /dev/sda4 | devfsd calls dd | dd returns | devfsd acknowledges LOOKUP | devfs repeats lookup /dev/sda4 - but it does not yet exist? | devfs returns error to user | devfs calls devfsd with REGISTER .../part4 which is now irrelevant Please, bear with me. I'd like to be sure I understand how it works and that it is not just an accident. -andrej From owner-devfs@oss.sgi.com Fri Feb 22 10:49:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1MInUn17376 for devfs-outgoing; Fri, 22 Feb 2002 10:49:30 -0800 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 g1MInK917369 for ; Fri, 22 Feb 2002 10:49:21 -0800 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id g1MHjst04040; Fri, 22 Feb 2002 10:45:54 -0700 Date: Fri, 22 Feb 2002 10:45:54 -0700 Message-Id: <200202221745.g1MHjst04040@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Borsenkow Andrej Cc: "'devfs mailing list'" Subject: RE: Why removables revalidation works at all? In-Reply-To: <008f01c1bbc1$aaaa3c10$21c9ca95@mow.siemens.ru> References: <200202221630.g1MGUJ102155@vindaloo.ras.ucalgary.ca> <008f01c1bbc1$aaaa3c10$21c9ca95@mow.siemens.ru> Sender: owner-devfs@oss.sgi.com Precedence: bulk Borsenkow Andrej writes: > > > > Borsenkow Andrej writes: > > > I am sorry if this is stupid question but if it should not work if I > > > understand devfs properly ... I mean these dd's in devfsd. > > > > > > What happens is > > > > > > User accesses /dev/sda4 > > > | > > > devfs lookup calls devfsd with LOOKUP > > > | > > > devfsd runs dd if=/dev/sda > > > | > > > |-----------------------+ > > > | | > > > devfsd returns to devfs devfs calls devfsd with REGISTER > > > | | > > > devfs repeats lookup devfsd creates /dev/sda4 > > > | > > > devfs returns /dev/sda4? > > > > > > So to my eyes there are two independent threads with obvious race > > > condition here. There is no way known to me to synchronize them. It > > > assumes second threads completes BEFORE devfs does second lookup. Is > > > it really garanteed? > > > > If I understand your question: you're wondering about races between > > devfsd and it's child dd process. There are no such races, because > > devfsd will wait for the child process to finish. Devfsd is > > explicitely single-threaded (i.e. it waits for children to finish) to > > avoid any such problems. > > > > Not quite. If it is single threaded the thread looks like: > > User lookup /dev/sda4 waits > | > devfs calls devfsd with LOOKUP /dev/sda4 > | > devfsd calls dd > | Insert here: dd does open (/dev/sda, ...) Block driver initiates a media revalidation devfs_register (dir, "part4", ...) is called REGISTER event queued to devfsd dd closes device > dd returns > | > devfsd acknowledges LOOKUP > | devfsd receives REGISTER on "part4" devfsd makes symlink /dev/sda4 devfsd goes back to sleep (no more events to process) > devfs repeats lookup /dev/sda4 - but it does not yet exist? It does now. So devfs returns success to user. > Please, bear with me. I'd like to be sure I understand how it works and > that it is not just an accident. Clear now? Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Sat Feb 23 09:29:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1NHT1308949 for devfs-outgoing; Sat, 23 Feb 2002 09:29:01 -0800 Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1NHSq908946 for ; Sat, 23 Feb 2002 09:28:53 -0800 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id g1NGSnp10373; Sat, 23 Feb 2002 17:28:49 +0100 (MET) Received: from MOWD019A.mow.siemens.ru ([139.24.18.3]) by mail2.siemens.de (8.11.6/8.11.6) with ESMTP id g1NGSmg26974; Sat, 23 Feb 2002 17:28:48 +0100 (MET) Received: by mowd019a.mow.siemens.ru with Internet Mail Service (5.5.2653.19) id ; Sat, 23 Feb 2002 19:32:40 +0300 Received: from [149.202.201.201] (149.202.201.201 [149.202.201.201]) by MOWD019A.mow.siemens.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id F363XWN8; Sat, 23 Feb 2002 19:32:36 +0300 From: Borsenkow Andrej To: Richard Gooch Cc: Cooker list , Kamil Toman , devfs mailing list Subject: Re: [Cooker] /dev/pts/* permissions (cannot use "talk") (devfs?) In-Reply-To: <200202172152.g1HLqFq20730@vindaloo.ras.ucalgary.ca> References: <20020216004808.GA3223@sarah.kolej.mff.cuni.cz> <1013868723.2458.39.camel@localhost.localdomain> <200202172152.g1HLqFq20730@vindaloo.ras.ucalgary.ca> Content-Type: text/plain; charset=KOI8-R Message-Id: <1014062319.5396.5.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution/1.0.21mdk Date: 23 Feb 2002 19:28:35 +0300 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g1NHSs908947 Sender: owner-devfs@oss.sgi.com Precedence: bulk On , 2002-02-18 at 00:52, Richard Gooch wrote: > > - still devfs documentation tells us we should not use devpts with > > devfs; and I am not sure who wins. pty.c registers /dev/pts/? with > > current owner and 600 permissions; and here I have > > > > {pts/1}% ll /dev/pts > > и'ого 0 > > crw--w---- 1 bor bor 136, 0 ЁЁ 16 16:11 0 > > crw------- 1 bor bor 136, 1 ЁЁ 16 17:05 1 > > crw------- 1 bor bor 136, 2 ЁЁ 16 17:03 2 > > crw------- 1 bor bor 136, 3 ЁЁ 16 17:04 3 > > > > that looks like pts/0 got permissions from devpts and others from devfs > > because default mount for devpts here is 640 > > I doubt that. More likely some programme changed the permissions for > pts/0 (perhaps xconsole or th Gnome equivalent?). > I booted without mounted devpts and all of them have the same permissions: {pts/2}% LANGUAGE=en LC_TIME=en ll /dev/pts total 0 crw------- 1 bor bor 136, 0 Jan 1 1970 0 crw------- 1 bor bor 136, 1 Feb 18 22:51 1 crw------- 1 bor bor 136, 2 Feb 18 22:55 2 may be there are different ways to open pty and they take different paths. But this imply that we really should not use devpts due to possiblilty of permissions not being applied. > > - and /etc/devfsd.conf tells us we must not fiddle with /dev/pt{s,y} > > permissions. > > Well, it doesn't quite say that. What it says is that you don't want > to have permissions persistence for /dev/pt{s,y} devices. That doesn't > mean you can't or shouldn't have a PERMISSIONS action. > > > So could anybody give ultimate answer on > > > > - should devpts be used in presence of devfs? > > No. > > > - how to manage permissions of pts - i.e. why they cannot be managed by > > devfsd? > > As Russell said in his follow-up, use a PERMISSIONS action on the > REGISTER event. > > Regards, > > Richard.... > Permanent: rgooch@atnf.csiro.au > Current: rgooch@ras.ucalgary.ca > From owner-devfs@oss.sgi.com Sat Feb 23 10:47:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1NIleM09905 for devfs-outgoing; Sat, 23 Feb 2002 10:47:40 -0800 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 g1NIlY909902 for ; Sat, 23 Feb 2002 10:47:34 -0800 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id g1NHbwM15148; Sat, 23 Feb 2002 10:37:58 -0700 Date: Sat, 23 Feb 2002 10:37:58 -0700 Message-Id: <200202231737.g1NHbwM15148@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Borsenkow Andrej Cc: Cooker list , Kamil Toman , devfs mailing list Subject: Re: [Cooker] /dev/pts/* permissions (cannot use "talk") (devfs?) In-Reply-To: <1014062319.5396.5.camel@localhost.localdomain> References: <20020216004808.GA3223@sarah.kolej.mff.cuni.cz> <1013868723.2458.39.camel@localhost.localdomain> <200202172152.g1HLqFq20730@vindaloo.ras.ucalgary.ca> <1014062319.5396.5.camel@localhost.localdomain> Sender: owner-devfs@oss.sgi.com Precedence: bulk Borsenkow Andrej writes: > On , 2002-02-18 at 00:52, Richard Gooch wrote: > > > - still devfs documentation tells us we should not use devpts with > > > devfs; and I am not sure who wins. pty.c registers /dev/pts/? with > > > current owner and 600 permissions; and here I have > > > > > > {pts/1}% ll /dev/pts > > > и'ого 0 > > > crw--w---- 1 bor bor 136, 0 ЁЁ 16 16:11 0 > > > crw------- 1 bor bor 136, 1 ЁЁ 16 17:05 1 > > > crw------- 1 bor bor 136, 2 ЁЁ 16 17:03 2 > > > crw------- 1 bor bor 136, 3 ЁЁ 16 17:04 3 > > > > > > that looks like pts/0 got permissions from devpts and others from devfs > > > because default mount for devpts here is 640 > > > > I doubt that. More likely some programme changed the permissions for > > pts/0 (perhaps xconsole or th Gnome equivalent?). > > I booted without mounted devpts and all of them have the same > permissions: > > {pts/2}% LANGUAGE=en LC_TIME=en ll /dev/pts > total 0 > crw------- 1 bor bor 136, 0 Jan 1 1970 0 > crw------- 1 bor bor 136, 1 Feb 18 22:51 1 > crw------- 1 bor bor 136, 2 Feb 18 22:55 2 Interesting. > may be there are different ways to open pty and they take different > paths. Could be. If so, it's most likely to be in the glibc PTY allocation code. It wouldn't surprise me, considering how much bloated shit is already in glibc. I know that they had hard-wired Unix98 PTY allocation to devpts at one point, and needed a patch to support devfs as well (which was added). Instead of their pointless hard-wiring, they could have just dropped that code and it would work automatically irrespective of the FS type. > But this imply that we really should not use devpts due to > possiblilty of permissions not being applied. Looks like it. Sigh. It would be nice if someone could do some stracing to figure out what was being done behind the covers. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Sat Feb 23 11:03:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1NJ3gM10361 for devfs-outgoing; Sat, 23 Feb 2002 11:03:42 -0800 Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1NJ3Y910358 for ; Sat, 23 Feb 2002 11:03:35 -0800 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id g1NI3Xd21799; Sat, 23 Feb 2002 19:03:33 +0100 (MET) Received: from MOWD019A.mow.siemens.ru ([139.24.18.3]) by mail2.siemens.de (8.11.6/8.11.6) with ESMTP id g1NI3Wg10787; Sat, 23 Feb 2002 19:03:32 +0100 (MET) Received: by mowd019a.mow.siemens.ru with Internet Mail Service (5.5.2653.19) id ; Sat, 23 Feb 2002 21:07:25 +0300 Received: from [149.202.201.201] (149.202.201.201 [149.202.201.201]) by MOWD019A.mow.siemens.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id F363XWPZ; Sat, 23 Feb 2002 21:07:18 +0300 From: Borsenkow Andrej To: Richard Gooch Cc: Cooker list , Kamil Toman , devfs mailing list Subject: Re: [Cooker] /dev/pts/* permissions (cannot use "talk") (devfs?) In-Reply-To: <200202231737.g1NHbwM15148@vindaloo.ras.ucalgary.ca> References: <20020216004808.GA3223@sarah.kolej.mff.cuni.cz> <1013868723.2458.39.camel@localhost.localdomain> <200202172152.g1HLqFq20730@vindaloo.ras.ucalgary.ca> <1014062319.5396.5.camel@localhost.localdomain> <200202231737.g1NHbwM15148@vindaloo.ras.ucalgary.ca> Content-Type: text/plain; charset=KOI8-R X-Mailer: Evolution/1.0.21mdk Date: 23 Feb 2002 21:03:18 +0300 Message-Id: <1014487405.20958.4.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g1NJ3Z910359 Sender: owner-devfs@oss.sgi.com Precedence: bulk On , 2002-02-23 at 20:37, Richard Gooch wrote: > Borsenkow Andrej writes: > > > > > > > > {pts/1}% ll /dev/pts > > > > и'ого 0 > > > > crw--w---- 1 bor bor 136, 0 ЁЁ 16 16:11 0 > > > > crw------- 1 bor bor 136, 1 ЁЁ 16 17:05 1 > > > > crw------- 1 bor bor 136, 2 ЁЁ 16 17:03 2 > > > > crw------- 1 bor bor 136, 3 ЁЁ 16 17:04 3 > > > > > > > > that looks like pts/0 got permissions from devpts and others from devfs > > > > because default mount for devpts here is 640 > > > > > > I doubt that. More likely some programme changed the permissions for > > > pts/0 (perhaps xconsole or th Gnome equivalent?). > > > > I booted without mounted devpts and all of them have the same > > permissions: > > > > {pts/2}% LANGUAGE=en LC_TIME=en ll /dev/pts > > total 0 > > crw------- 1 bor bor 136, 0 Jan 1 1970 0 > > crw------- 1 bor bor 136, 1 Feb 18 22:51 1 > > crw------- 1 bor bor 136, 2 Feb 18 22:55 2 > > Interesting. > > > may be there are different ways to open pty and they take different > > paths. > > Could be. If so, it's most likely to be in the glibc PTY allocation > code. It wouldn't surprise me, considering how much bloated shit is > already in glibc. I know that they had hard-wired Unix98 PTY > allocation to devpts at one point, and needed a patch to support devfs > as well (which was added). Instead of their pointless hard-wiring, > they could have just dropped that code and it would work automatically > irrespective of the FS type. > > > But this imply that we really should not use devpts due to > > possiblilty of permissions not being applied. > > Looks like it. Sigh. It would be nice if someone could do some > stracing to figure out what was being done behind the covers. > Ouch. Sorry, it lingered in unsent messages, I forgot to remove it. To close the theme, permissions are alike both with and without devpts (at least using kernel and glibc shipped by current Mandrake cooker). In the very first case I presume permissions were modified by some process. It means that devfsd.conf mods will work and the only drawback is user confusion if they will try to modify permissions via devpts mount options (because it seems to be completely ignored). -andrej From owner-devfs@oss.sgi.com Sun Feb 24 13:02:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1OL2aX05859 for devfs-outgoing; Sun, 24 Feb 2002 13:02:36 -0800 Received: from lakemtao01.cox.net (mtao1.east.cox.net [68.1.17.244]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1OL2R905853 for ; Sun, 24 Feb 2002 13:02:27 -0800 Received: from there ([68.4.109.77]) by lakemtao01.cox.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020224200218.SPSV3264.lakemtao01.cox.net@there> for ; Sun, 24 Feb 2002 15:02:18 -0500 Content-Type: text/plain; charset="iso-8859-1" From: Harry Mangalam Reply-To: hjm@tacgi.com To: devfs@oss.sgi.com Subject: uncorrectable devfs cdrom mismapping Date: Sun, 24 Feb 2002 15:01:54 -0800 X-Mailer: KMail [version 1.2.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020224200218.SPSV3264.lakemtao01.cox.net@there> Sender: owner-devfs@oss.sgi.com Precedence: bulk Hi All, Apologies for what may be a newbie question, but I'm trying to correct (?) a problem with a Mandrake 8.1 installation on an IBM THinkpad a22p. I seem to remember that the CD player worked fine upon initial install but then quit at some point. After a lot of feeling in the dark, I figured out that it was a devfs distro and that somehow my cdrom had been mis-mapped from /dev/cdrom -> cdroms/cdrom0 to /dev/cdrom -> ../cdroms/cdrom0 (altho /dev/cdrom1 -> cdroms/cdrom1 in the correct way) It may have been me that was responsible for this, but certainly don't remember doing this directly.. At any rate, I can't get it to point back to the correct link, either by deleting the link and re-establishing it, or by deleting and changing the similar files that exist in /lib/dev-state. Is there some magic trick to doing this? Also, having found this list via google, I haven't found the subscriber address either so until I do, I'd appreciate a direct reply as well as to the list. -- Cheers, Harry Harry J Mangalam - 949 856 2847 (v&f) - hjm@tacgi.com (primary) <> From owner-devfs@oss.sgi.com Sun Feb 24 13:35:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1OLZ7a06332 for devfs-outgoing; Sun, 24 Feb 2002 13:35:07 -0800 Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1OLYv906328 for ; Sun, 24 Feb 2002 13:34:57 -0800 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id g1OKYtp23581 for ; Sun, 24 Feb 2002 21:34:55 +0100 (MET) Received: from MOWD019A.mow.siemens.ru ([139.24.18.3]) by mail2.siemens.de (8.11.6/8.11.6) with ESMTP id g1OKYsg10895 for ; Sun, 24 Feb 2002 21:34:54 +0100 (MET) Received: by mowd019a.mow.siemens.ru with Internet Mail Service (5.5.2653.19) id ; Sun, 24 Feb 2002 23:38:49 +0300 Received: from [149.202.201.201] (149.202.201.201 [149.202.201.201]) by MOWD019A.mow.siemens.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id F363XX23; Sun, 24 Feb 2002 23:38:41 +0300 From: Borsenkow Andrej To: hjm@tacgi.com Cc: devfs mailing list Subject: Re: uncorrectable devfs cdrom mismapping In-Reply-To: <20020224200218.SPSV3264.lakemtao01.cox.net@there> References: <20020224200218.SPSV3264.lakemtao01.cox.net@there> Content-Type: text/plain; charset=KOI8-R X-Mailer: Evolution/1.0.21mdk Date: 24 Feb 2002 23:34:40 +0300 Message-Id: <1014582886.20903.16.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g1OLZ1906329 Sender: owner-devfs@oss.sgi.com Precedence: bulk On , 2002-02-25 at 02:01, Harry Mangalam wrote: > > Hi All, > > Apologies for what may be a newbie question, but I'm trying to correct (?) > a problem with a Mandrake 8.1 installation on an IBM THinkpad a22p. I > seem to remember that the CD player worked fine upon initial install but > then quit at some point. > > After a lot of feeling in the dark, I figured out that it was a devfs > distro and that somehow my cdrom had been mis-mapped from > > /dev/cdrom -> cdroms/cdrom0 > > to > > /dev/cdrom -> ../cdroms/cdrom0 > Use 8.2beta3 {pts/3}% LC_TIME=en rpm -q --changelog devfsd | less ... * Thu Oct 11 2001 Thierry Vignaud 1.3.18-17mdk - fix cdrom link (fergal) or edit /etc/devfsd.conf in obvious way. But I strongly urge you to update. devfs in 8.1 was no the best possible idea (although it has been good testbed ... but do not tell it innocent users outa there :-) -andrej > (altho /dev/cdrom1 -> cdroms/cdrom1 in the correct way) > > It may have been me that was responsible for this, but certainly don't > remember doing this directly.. > > At any rate, I can't get it to point back to the correct link, either by > deleting the link and re-establishing it, or by deleting and changing the > similar files that exist in /lib/dev-state. > > Is there some magic trick to doing this? > > Also, having found this list via google, I haven't found the subscriber > address either so until I do, I'd appreciate a direct reply as well as to > the list. > > -- > Cheers, Harry > Harry J Mangalam - 949 856 2847 (v&f) - hjm@tacgi.com (primary) > <> > From owner-devfs@oss.sgi.com Mon Feb 25 09:35:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1PHZ9M22017 for devfs-outgoing; Mon, 25 Feb 2002 09:35:09 -0800 Received: from zzz.zzz ([212.57.170.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1PHYq921986 for ; Mon, 25 Feb 2002 09:34:55 -0800 Date: Mon, 25 Feb 2002 20:42:12 +0500 From: Denis Zaitsev To: rgooch@ras.ucalgary.ca Cc: devfs@oss.sgi.com Subject: Re: [PATCH] a little strings-aware code change Message-ID: <20020225204212.B5954@natasha.zzz.zzz> References: <200202180612.g1I6C4L25410@vindaloo.ras.ucalgary.ca> <20020219030003.D1639@zzz.zzz.zzz> <200202191840.g1JIeKt18971@vindaloo.ras.ucalgary.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200202191840.g1JIeKt18971@vindaloo.ras.ucalgary.ca>; from rgooch@ras.ucalgary.ca on Tue, Feb 19, 2002 at 11:40:20AM -0700 Sender: owner-devfs@oss.sgi.com Precedence: bulk Ok, I'm sorry for such a delay... On Tue, Feb 19, 2002 at 11:40:20AM -0700, Richard Gooch wrote: > Denis Zaitsev writes: > > This little patch does nothing with the functionality of devfsd, but > > with the C code. There are a number of constructions like: > > > > [PFXLEN = strlen(prefix);] > > if (strncmp(str, prefix, PFXLEN) == 0) > > do_something_with(str + PFXLEN); > > > > It is not the best way to do such a things. The idea is to implement > > the special function, which will test the string for some prefix and > > return the address of a place of the string after that prefix or NULL > > in case of an absence of the success. The construction above becomes > > better: > > > > if (ptr= strtry(str, prefix)) > > do_something_with(ptr); > > > > And the new function itself is more lightweight than alone strncmp, > > and just much more effective than in a couple. It > > is good again. So, all the idea seems to be healthy. I call this > > function "strtry", as it tries its arg for the given prefix. > > Apart from not really liking this approach, you've made the strtry() > function inlined. Any saving you might make with removing code from > the callers is probably more than lost due to all the extra inlined > code. > > Did you compare the sizes of the stripped binary to see what the > effect of your patch is? > Yes, of course, I did. The new binary is 672 bytes smaller...) But it's not the answer for your question, because I compile devfsd with all the string functions inlined. And the difference includes all the throwned out strrchr's calls. And I haven't done any "pure" measurements. But I think, they aren't really needed. strtry should be inlined, because it is very small - something like 14 inline bytes on x86, plus, say 5 bytes for loading the prefix's addr into the reg. At the same time, the outlined call for strncmp takes: call itself - 5 bytes, stack cleanup - 3 bytes, stack loading - something like 2 + 1 + 6 bytes - i.e. it's generally just equal for the inlined strtry. So, inlined strtry is better than outlined strncmp even without the cons of a inline size... And strtry's cycle is more effective, than strncmp's one, but I've already written about. And when strncmp is used in the couple with strlen, than strtry is more than twice faster, as it scans the prefix only once vs. twice. And strtry's stuff looks good in C (as for me, of course). So, that are the reasons, why strtry is "a good choice"... > > Richard, please, apply this patch, if you find it useful. It is > > against devfsd-1.3.22. By the way, I've arranged the > > strrchr (devname, '/') + 1 > > stuff, so this thing to be done once instead of multiply times in the > > original. > > But you've inserted calls to strrchr in cases where it's not really > needed. > Yes, I agree, I was thinking about this... Probably, just another special function will be healthy here, as that fragment of code is repeated often. If you don't reject the whole idea about strtry, I will remove these changes from the patch. > BTW: linux-kernel isn't the right place to discuss devfsd > development. The right place is devfs@oss.sgi.com (I've set Reply-To: > to do this). > I know, It just ... happened. I got some letter for you from devfs mailing list and hooked the addresses from there. And when my letter was in the "delivering" I realized that it's linux-kernel's address there. I stopped the process, but it seems that one copy had already been delivered. Then I cure the address, and either you should be mailed twice or the kernel list once. From owner-devfs@oss.sgi.com Tue Feb 26 04:35:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1QCZut13931 for devfs-outgoing; Tue, 26 Feb 2002 04:35:56 -0800 Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1QCZs913926 for ; Tue, 26 Feb 2002 04:35:54 -0800 Received: from fwd02.sul.t-online.de by mailout06.sul.t-online.com with smtp id 16fffQ-00012c-06; Tue, 26 Feb 2002 12:21:08 +0100 Received: from localhost (520061743426-0001@[62.226.14.79]) by fmrl02.sul.t-online.com with esmtp id 16fff9-0RlfCyC; Tue, 26 Feb 2002 12:20:51 +0100 Received: from aurel32 by localhost with local (Exim 3.34 #1 (Debian)) id 16fff7-00012o-00 for ; Tue, 26 Feb 2002 12:20:49 +0100 Content-Type: text/plain; charset="iso-8859-15" From: Aurelien Jarno To: devfs@oss.sgi.com Subject: devfs & /var/lock Date: Tue, 26 Feb 2002 12:20:48 +0100 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: X-Sender: 520061743426-0001@t-dialin.net Sender: owner-devfs@oss.sgi.com Precedence: bulk Hello, I am currently writing a small application using the serial port. To respect standards, my application create a file in /var/lock, for example /var/lock/LCK..ttyS0 What is the standard when using devfs and devices in /dev/tts ? /var/lock/LCK..tts0 ? Aurelien Janro From owner-devfs@oss.sgi.com Tue Feb 26 08:42:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1QGgaH25328 for devfs-outgoing; Tue, 26 Feb 2002 08:42:36 -0800 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 g1QGgW925325 for ; Tue, 26 Feb 2002 08:42:32 -0800 Received: from lyta.coker.com.au (localhost [127.0.0.1]) by tsv.sws.net.au (Postfix) with ESMTP id 68B3F92673; Wed, 27 Feb 2002 02:42:29 +1100 (EST) Received: from there (lyta [127.0.0.1]) by lyta.coker.com.au (Postfix) with SMTP id 1C04CF667; Tue, 26 Feb 2002 16:42:24 +0100 (CET) Content-Type: text/plain; charset="iso-8859-15" From: Russell Coker Reply-To: Russell Coker To: Aurelien Jarno , devfs@oss.sgi.com Subject: Re: devfs & /var/lock Date: Tue, 26 Feb 2002 16:31:21 +0100 X-Mailer: KMail [version 1.3.2] References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020226154224.1C04CF667@lyta.coker.com.au> Sender: owner-devfs@oss.sgi.com Precedence: bulk On Tue, 26 Feb 2002 12:20, Aurelien Jarno wrote: > I am currently writing a small application using the serial port. To > respect standards, my application create a file in /var/lock, for example > /var/lock/LCK..ttyS0 > > What is the standard when using devfs and devices in /dev/tts ? > /var/lock/LCK..tts0 ? Most code is using /var/lock/LCK..0, which will work OK as long as only serial ports are locked. We need something better though. Maybe /var/lock/...tts.0 (and as a general rule make it /var/lock/...ZZ where ZZ is the device name with /dev/ stripped off and all '/' characters replaced by '.' characters)? -- Signatures >4 lines are rude. If you send email to me or to a mailing list that I am subscribed to which has >4 lines of legalistic junk at the end then you are specifically authorizing me to do whatever I wish with the message (the sig won't be read). From owner-devfs@oss.sgi.com Tue Feb 26 10:01:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1QI1eg29364 for devfs-outgoing; Tue, 26 Feb 2002 10:01:40 -0800 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 g1QI1Z929361 for ; Tue, 26 Feb 2002 10:01:35 -0800 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id g1QH17j23033; Tue, 26 Feb 2002 10:01:07 -0700 Date: Tue, 26 Feb 2002 10:01:07 -0700 Message-Id: <200202261701.g1QH17j23033@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Russell Coker Cc: Aurelien Jarno , devfs@oss.sgi.com Subject: Re: devfs & /var/lock In-Reply-To: <20020226154224.1C04CF667@lyta.coker.com.au> References: <20020226154224.1C04CF667@lyta.coker.com.au> Sender: owner-devfs@oss.sgi.com Precedence: bulk Russell Coker writes: > On Tue, 26 Feb 2002 12:20, Aurelien Jarno wrote: > > I am currently writing a small application using the serial port. To > > respect standards, my application create a file in /var/lock, for example > > /var/lock/LCK..ttyS0 > > > > What is the standard when using devfs and devices in /dev/tts ? > > /var/lock/LCK..tts0 ? > > Most code is using /var/lock/LCK..0, which will work OK as long as > only serial ports are locked. We need something better though. > Maybe /var/lock/...tts.0 (and as a general rule make it > /var/lock/...ZZ where ZZ is the device name with /dev/ stripped off > and all '/' characters replaced by '.' characters)? Why not use '!', just like emacs does? > Signatures >4 lines are rude. If you send email to me or to a mailing list > that I am subscribed to which has >4 lines of legalistic junk at the end > then you are specifically authorizing me to do whatever I wish with the > message (the sig won't be read). Are you really automatically discarding the .sig? Can you do that reliably? If so, you could bounce the messages, if you want to be really mean... Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Tue Feb 26 11:42:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1QJgrk00770 for devfs-outgoing; Tue, 26 Feb 2002 11:42:53 -0800 Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g1QJgn900767 for ; Tue, 26 Feb 2002 11:42:49 -0800 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id g1QIgld20694; Tue, 26 Feb 2002 19:42:47 +0100 (MET) Received: from MOWD019A.mow.siemens.ru ([139.24.18.3]) by mail2.siemens.de (8.11.6/8.11.6) with ESMTP id g1QIgkg25243; Tue, 26 Feb 2002 19:42:46 +0100 (MET) Received: by mowd019a.mow.siemens.ru with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Feb 2002 21:46:44 +0300 Received: from [149.202.201.201] (149.202.201.201 [149.202.201.201]) by MOWD019A.mow.siemens.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id F363X9ZN; Tue, 26 Feb 2002 21:46:39 +0300 From: Borsenkow Andrej To: Russell Coker Cc: Aurelien Jarno , devfs mailing list Subject: Re: devfs & /var/lock In-Reply-To: <20020226154224.1C04CF667@lyta.coker.com.au> References: <20020226154224.1C04CF667@lyta.coker.com.au> Content-Type: text/plain; charset=KOI8-R X-Mailer: Evolution/1.0.21mdk Date: 26 Feb 2002 21:42:33 +0300 Message-Id: <1014748960.3329.13.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g1QJgo900768 Sender: owner-devfs@oss.sgi.com Precedence: bulk On , 2002-02-26 at 18:31, Russell Coker wrote: > On Tue, 26 Feb 2002 12:20, Aurelien Jarno wrote: > > I am currently writing a small application using the serial port. To > > respect standards, my application create a file in /var/lock, for example > > /var/lock/LCK..ttyS0 > > > > What is the standard when using devfs and devices in /dev/tts ? > > /var/lock/LCK..tts0 ? > > Most code is using /var/lock/LCK..0, which will work OK as long as only > serial ports are locked. We need something better though. Maybe > /var/lock/...tts.0 (and as a general rule make it /var/lock/...ZZ where ZZ is > the device name with /dev/ stripped off and all '/' characters replaced by > '.' characters)? > SVR4 used (is using) device number to build lock file name which was IMHO much better as it did not depend on any name and was immune to symlinks. So it would be something like LCK.4.64 be the name ttyS0, tts/0 or modem as long as they point to the same device -andrej From owner-devfs@oss.sgi.com Tue Feb 26 16:31:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g1R0V6D20584 for devfs-outgoing; Tue, 26 Feb 2002 16:31:06 -0800 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 g1R0Uv920576 for ; Tue, 26 Feb 2002 16:30:57 -0800 Received: from lyta.coker.com.au (localhost [127.0.0.1]) by tsv.sws.net.au (Postfix) with ESMTP id 97F8792672; Wed, 27 Feb 2002 10:30:43 +1100 (EST) Received: from there (lyta [127.0.0.1]) by lyta.coker.com.au (Postfix) with SMTP id D43D4F695; Wed, 27 Feb 2002 00:30:24 +0100 (CET) Content-Type: text/plain; charset="iso-8859-1" From: Russell Coker Reply-To: Russell Coker To: Richard Gooch Subject: Re: devfs & /var/lock Date: Wed, 27 Feb 2002 00:30:24 +0100 X-Mailer: KMail [version 1.3.2] Cc: devfs@oss.sgi.com References: <20020226154224.1C04CF667@lyta.coker.com.au> <200202261701.g1QH17j23033@vindaloo.ras.ucalgary.ca> In-Reply-To: <200202261701.g1QH17j23033@vindaloo.ras.ucalgary.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020226233024.D43D4F695@lyta.coker.com.au> Sender: owner-devfs@oss.sgi.com Precedence: bulk On Tue, 26 Feb 2002 18:01, Richard Gooch wrote: > > > I am currently writing a small application using the serial port. To > > > respect standards, my application create a file in /var/lock, for > > > example /var/lock/LCK..ttyS0 > > > > > > What is the standard when using devfs and devices in /dev/tts ? > > > /var/lock/LCK..tts0 ? > > > > Most code is using /var/lock/LCK..0, which will work OK as long as > > only serial ports are locked. We need something better though. > > Maybe /var/lock/...tts.0 (and as a general rule make it > > /var/lock/...ZZ where ZZ is the device name with /dev/ stripped off > > and all '/' characters replaced by '.' characters)? > > Why not use '!', just like emacs does? No reason. We have to choose something, and I guess that using a '!' is as good as anything. > > Signatures >4 lines are rude. If you send email to me or to a mailing > > list that I am subscribed to which has >4 lines of legalistic junk at the > > end then you are specifically authorizing me to do whatever I wish with > > the message (the sig won't be read). > > Are you really automatically discarding the .sig? Can you do that No, I just look at the start and if it's legalistic and long then I ignore it. > reliably? If so, you could bounce the messages, if you want to be > really mean... No. Bouncing such messages does not do anything. I've tried configuring my mail server to bounce messages from domains that put such sigs on but it does no good. An idiot lawyer from one of those companies could argue that my sig is unenforcable (it probably is), in which case their sig is unenforcable too and there's no point in adding it. But if their sig is enforcable then mine is too. So if someone wants their long legalistic sig to be considered as enforcable then they have to refrain from posting to mailing lists where I post. I started using this sig when a user was posting incoherant and off-topic messages to a list that I'm on while using a long legalistic sig. Other methods gave no result, so on that user's first post after seeing my new sig I replied to the user (and CC'd the postmaster at the domain) thanking them for granting me full rights to do whatever I like with their message without regard to their sig. I never heard from them again (on the list or in private mail). I know that I was being a bit of a bastard, but they challenged me to make them stop using that overly long sig and I did so. This sig works! -- Signatures >4 lines are rude. If you send email to me or to a mailing list that I am subscribed to which has >4 lines of legalistic junk at the end then you are specifically authorizing me to do whatever I wish with the message (the sig won't be read).