From owner-devfs@oss.sgi.com Fri Jun 1 08:31:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f51FVhD29208 for devfs-outgoing; Fri, 1 Jun 2001 08:31:43 -0700 Received: from mobilix.ras.ucalgary.ca (h-207-228-73-44.gen.cadvision.com [207.228.73.44]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f51FVfh29203 for ; Fri, 1 Jun 2001 08:31:42 -0700 Received: (from rgooch@localhost) by mobilix.ras.ucalgary.ca (8.10.0/8.10.0) id f51FUP610493; Fri, 1 Jun 2001 09:30:25 -0600 Date: Fri, 1 Jun 2001 09:30:25 -0600 Message-Id: <200106011530.f51FUP610493@mobilix.ras.ucalgary.ca> From: Richard Gooch To: linux-kernel@vger.kernel.org, devfs-announce-list@mobilix.ras.ucalgary.ca Subject: [PATCH] devfs v178 available Sender: owner-devfs@oss.sgi.com Precedence: bulk Hi, all. Version 178 of my devfs patch is now available from: http://www.atnf.csiro.au/~rgooch/linux/kernel-patches.html The devfs FAQ is also available here. Patch directly available from: ftp://ftp.??.kernel.org/pub/linux/kernel/people/rgooch/v2.4/devfs-patch-current.gz AND: ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/kernel-patches/v2.4/devfs-patch-current.gz This is against 2.4.5. Highlights of this release: - Fixed handling of inverted options in Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Fri Jun 1 14:02:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f51L2I813370 for devfs-outgoing; Fri, 1 Jun 2001 14:02:18 -0700 Received: from sender.ngi.de (sender.ngi.de [212.79.47.18]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f51L2Fh13355 for ; Fri, 1 Jun 2001 14:02:16 -0700 Received: from hnvr-3e36dcd6.pool.mediaWays.net (hnvr-3e36dcd6.pool.mediaWays.net [62.54.220.214]) by sender.ngi.de (Postfix) with ESMTP id C5F0496D44 for ; Fri, 1 Jun 2001 22:48:33 +0200 (CEST) Date: Fri, 01 Jun 2001 23:02:14 +0200 From: Sebastian Ude To: devfs@oss.sgi.com Subject: ude@handshake.de Reply-To: ude@handshake.de X-Mailer: Spruce 0.7.6 for X11 w/smtpio 0.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20010601204833.C5F0496D44@sender.ngi.de> Sender: owner-devfs@oss.sgi.com Precedence: bulk I applied the devfs 178 patch (which was released today), and now module autoloading does not work for me at all (it worked before with the vanilla 2.4.5 Kernel / devfs 176). I also tried the 177 patch, and I got the same behaviour. First of all some information about my current setup: Kernel configuration: CONFIG_DEVFS_FS=y CONFIG_DEVFS_MOUNT is not set CONFIG_DEVFS_DEBUG=y Boot options: devfs=mount,dmod,dreg,dunreg,dimknod,dilookup devfsd version: 1.3.11 devfs configuration: I used the devfsd.conf that came with devfsd 1.3.11. I only added these two lines in order to change the rights of the audio devices after the ALSA modules have been loaded: REGISTER sound/.* PERMISSIONS root.audio 660 REGISTER snd/.* PERMISSIONS root.audio 660 I did not change anything else. The line LOOKUP .* MODLOAD is present ! devfsd is started with "/dev" as the only option. So let's see what happens if I try to access my first SCSI CD-ROM device (/dev/sr0). With plain kernel 2.4.5 / devfs 176, the sr_mod module was loaded automatically, and the devices were created. No problem at all. With version 177 / 178, it seems like nothing happens. The sr_mod module is not loaded automatically, and the applications complain about the missing /dev/sr0 device file. Here are the syslog messages I get with the debugging options mentioned above: devfs: lookup(sr0): dentry: c1761440 by: "mount" devfs: lookup(sr0): dentry: c1761440 by: "mount" If i start devfsd with "-d -t 0", it tells me the following: Entry: "/sr0"(len=4) lookup mode: 0 uid: 0 gid: 100 Entry: "/sr0"(len=4) lookup mode: 0 uid: 0 gid: 100 Of course everything works when I insert the sr_mod kernel module manually: syslog: devfs: devfs_mk_dir(cdroms): de: c1dac860 new devfs: devfs_register(cd): de: c1dacd60 new devfs: devfs_do_symlink(cdrom0) devfs: lookup(sr0): dentry: c0397860 by: "devfsd" devfs: devfs_do_symlink(sr0) devfs: lookup(sr): dentry: c03978e0 by: "devfsd devfs: lookup(sr): dentry: c03978e0 by: "devfsd" devfs: lookup(c0b0t5u0): dentry: c0397960 by: "devfsd" devfs: devfs_do_symlink(c0b0t5u0) devfsd: Entry: "scsi/host0/bus0/target5/lun0/cd"(len=31) registered mode: 60666 uid: 0 gid: 0 Entry: "cdroms/cdrom0"(len=13) registered mode: 120555 uid: 0 gid: 0 As i said it worked with the same setup and devfs 176. And the problem is not limited to the sr driver ! As I said above, module autoloading does not work at all ... For example, I have the same problem with my ALSA sound modules since the upgrade. Any ideas ? PS: I am not subscribed to the list, but there is no need to answer me directly. Just post to the list ... I will check out the archives regulary. From owner-devfs@oss.sgi.com Fri Jun 1 14:04:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f51L42313743 for devfs-outgoing; Fri, 1 Jun 2001 14:04:02 -0700 Received: from sender.ngi.de (sender.ngi.de [212.79.47.18]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f51L40h13740 for ; Fri, 1 Jun 2001 14:04:00 -0700 Received: from hnvr-3e36dccd.pool.mediaWays.net (hnvr-3e36dccd.pool.mediaWays.net [62.54.220.205]) by sender.ngi.de (Postfix) with ESMTP id 460C696D2C for ; Fri, 1 Jun 2001 22:50:20 +0200 (CEST) Date: Fri, 01 Jun 2001 23:04:01 +0200 From: Sebastian Ude To: devfs@oss.sgi.com Subject: module autoloading problem with 177 / 178 Reply-To: ude@handshake.de X-Mailer: Spruce 0.7.6 for X11 w/smtpio 0.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20010601205020.460C696D2C@sender.ngi.de> Sender: owner-devfs@oss.sgi.com Precedence: bulk I applied the devfs 178 patch (which was released today), and now module autoloading does not work for me at all (it worked before with the vanilla 2.4.5 Kernel / devfs 176). I also tried the 177 patch, and I got the same behaviour. First of all some information about my current setup: Kernel configuration: CONFIG_DEVFS_FS=y CONFIG_DEVFS_MOUNT is not set CONFIG_DEVFS_DEBUG=y Boot options: devfs=mount,dmod,dreg,dunreg,dimknod,dilookup devfsd version: 1.3.11 devfs configuration: I used the devfsd.conf that came with devfsd 1.3.11. I only added these two lines in order to change the rights of the audio devices after the ALSA modules have been loaded: REGISTER sound/.* PERMISSIONS root.audio 660 REGISTER snd/.* PERMISSIONS root.audio 660 I did not change anything else. The line LOOKUP .* MODLOAD is present ! devfsd is started with "/dev" as the only option. So let's see what happens if I try to access my first SCSI CD-ROM device (/dev/sr0). With plain kernel 2.4.5 / devfs 176, the sr_mod module was loaded automatically, and the devices were created. No problem at all. With version 177 / 178, it seems like nothing happens. The sr_mod module is not loaded automatically, and the applications complain about the missing /dev/sr0 device file. Here are the syslog messages I get with the debugging options mentioned above: devfs: lookup(sr0): dentry: c1761440 by: "mount" devfs: lookup(sr0): dentry: c1761440 by: "mount" If i start devfsd with "-d -t 0", it tells me the following: Entry: "/sr0"(len=4) lookup mode: 0 uid: 0 gid: 100 Entry: "/sr0"(len=4) lookup mode: 0 uid: 0 gid: 100 Of course everything works when I insert the sr_mod kernel module manually: syslog: devfs: devfs_mk_dir(cdroms): de: c1dac860 new devfs: devfs_register(cd): de: c1dacd60 new devfs: devfs_do_symlink(cdrom0) devfs: lookup(sr0): dentry: c0397860 by: "devfsd" devfs: devfs_do_symlink(sr0) devfs: lookup(sr): dentry: c03978e0 by: "devfsd devfs: lookup(sr): dentry: c03978e0 by: "devfsd" devfs: lookup(c0b0t5u0): dentry: c0397960 by: "devfsd" devfs: devfs_do_symlink(c0b0t5u0) devfsd: Entry: "scsi/host0/bus0/target5/lun0/cd"(len=31) registered mode: 60666 uid: 0 gid: 0 Entry: "cdroms/cdrom0"(len=13) registered mode: 120555 uid: 0 gid: 0 As i said it worked with the same setup and devfs 176. And the problem is not limited to the sr driver ! As I said above, module autoloading does not work at all ... For example, I have the same problem with my ALSA sound modules since the upgrade. Any ideas ? PS: I am not subscribed to the list, but there is no need to answer me directly. Just post to the list ... I will check out the archives regulary. From owner-devfs@oss.sgi.com Sat Jun 2 00:03:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f5273Im21992 for devfs-outgoing; Sat, 2 Jun 2001 00:03:18 -0700 Received: from sender.ngi.de (sender.ngi.de [212.79.47.18]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f5273Gh21980 for ; Sat, 2 Jun 2001 00:03:17 -0700 Received: from hnvr-3e36d666.pool.mediaWays.net (hnvr-3e36d666.pool.mediaWays.net [62.54.214.102]) by sender.ngi.de (Postfix) with ESMTP id EF66296D3C for ; Sat, 2 Jun 2001 08:49:28 +0200 (CEST) Date: Sat, 02 Jun 2001 09:03:16 +0200 From: Sebastian Ude To: devfs@oss.sgi.com Subject: Re: module autoloading problem with 177 / 178 Reply-To: ude@handshake.de X-Mailer: Spruce 0.7.6 for X11 w/smtpio 0.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20010602064928.EF66296D3C@sender.ngi.de> Sender: owner-devfs@oss.sgi.com Precedence: bulk Sebastian Ude wrote: >I applied the devfs 178 patch (which was released today), and now >module autoloading does not work for me at all (it worked before with >the vanilla 2.4.5 Kernel / devfs 176). >I also tried the 177 patch, and I got the same behaviour. [...] >Of course everything works when I insert the sr_mod kernel module >manually: [...] >As i said it worked with the same setup and devfs 176. >And the problem is not limited to the sr driver ! >As I said above, module autoloading does not work at all ... For >example, I have the same problem with my ALSA sound modules since >the upgrade. I found a solution for the problem. I had to change my aliases in the modules.conf, for example "/dev/snd" to "/dev//snd" and it worked again. Yep, this is no typo, I had to use two // instead of one. Strange thing ... can somebody please explain this to me ? Why does it only work with "alias /dev//[devname]" but not with "alias /dev/[devname" with 177 / 178 ??? From owner-devfs@oss.sgi.com Sat Jun 2 09:38:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f52Gc5X17463 for devfs-outgoing; Sat, 2 Jun 2001 09:38:05 -0700 Received: from mobilix.ras.ucalgary.ca (h-207-228-73-44.gen.cadvision.com [207.228.73.44]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f52Gc4h17460 for ; Sat, 2 Jun 2001 09:38:04 -0700 Received: (from rgooch@localhost) by mobilix.ras.ucalgary.ca (8.10.0/8.10.0) id f52GNVg01003; Sat, 2 Jun 2001 10:23:31 -0600 Date: Sat, 2 Jun 2001 10:23:31 -0600 Message-Id: <200106021623.f52GNVg01003@mobilix.ras.ucalgary.ca> From: Richard Gooch To: ude@handshake.de Cc: devfs@oss.sgi.com Subject: Re: module autoloading problem with 177 / 178 In-Reply-To: <20010602064928.EF66296D3C@sender.ngi.de> References: <20010602064928.EF66296D3C@sender.ngi.de> Sender: owner-devfs@oss.sgi.com Precedence: bulk Sebastian Ude writes: > > > > Sebastian Ude wrote: > > >I applied the devfs 178 patch (which was released today), and now > >module autoloading does not work for me at all (it worked before with > >the vanilla 2.4.5 Kernel / devfs 176). > > >I also tried the 177 patch, and I got the same behaviour. > > [...] > > >Of course everything works when I insert the sr_mod kernel module > >manually: > > [...] > > >As i said it worked with the same setup and devfs 176. > >And the problem is not limited to the sr driver ! > >As I said above, module autoloading does not work at all ... For > >example, I have the same problem with my ALSA sound modules since > >the upgrade. > > I found a solution for the problem. > > I had to change my aliases in the modules.conf, for example "/dev/snd" to > "/dev//snd" and it worked again. > Yep, this is no typo, I had to use two // instead of one. > > Strange thing ... can somebody please explain this to me ? > Why does it only work with "alias /dev//[devname]" but not with "alias > /dev/[devname" with 177 / 178 ??? Yeah, I know. It's a bug in the devfs code that I introduced. I'll be putting out a new patch to fix this. Probably not until after the weekend, when we get power back in our building at work. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Mon Jun 4 22:51:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f555pAh16160 for devfs-outgoing; Mon, 4 Jun 2001 22:51:10 -0700 Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f555p9h16151 for ; Mon, 4 Jun 2001 22:51:09 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id f555on731916; Mon, 4 Jun 2001 23:50:49 -0600 Date: Mon, 4 Jun 2001 23:50:49 -0600 Message-Id: <200106050550.f555on731916@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: linux-kernel@vger.kernel.org, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: [PATCH] devfs v179 available Sender: owner-devfs@oss.sgi.com Precedence: bulk Hi, all. Version 179 of my devfs patch is now available from: http://www.atnf.csiro.au/~rgooch/linux/kernel-patches.html The devfs FAQ is also available here. Patch directly available from: ftp://ftp.??.kernel.org/pub/linux/kernel/people/rgooch/v2.4/devfs-patch-current.gz AND: ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/kernel-patches/v2.4/devfs-patch-current.gz This is against 2.4.5. Highlights of this release: - Adjusted to account for fix Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Tue Jun 5 16:36:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f55Nalc23746 for devfs-outgoing; Tue, 5 Jun 2001 16:36:47 -0700 Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f55Najh23743 for ; Tue, 5 Jun 2001 16:36:45 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id f55Nac808436; Tue, 5 Jun 2001 17:36:38 -0600 Date: Tue, 5 Jun 2001 17:36:38 -0600 Message-Id: <200106052336.f55Nac808436@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: ude@handshake.de Cc: devfs@oss.sgi.com Subject: Re: module autoloading problem with 177 / 178 In-Reply-To: <20010601205020.460C696D2C@sender.ngi.de> References: <20010601205020.460C696D2C@sender.ngi.de> Sender: owner-devfs@oss.sgi.com Precedence: bulk Sebastian Ude writes: > > I applied the devfs 178 patch (which was released today), and now > module autoloading does not work for me at all (it worked before > with the vanilla 2.4.5 Kernel / devfs 176). In case it wasn't obvious, patch v179 fixes this. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Mon Jun 11 09:51:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BGpLH12010 for devfs-outgoing; Mon, 11 Jun 2001 09:51:21 -0700 Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BGpKV12007 for ; Mon, 11 Jun 2001 09:51:20 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id f5BGnQN25832; Mon, 11 Jun 2001 10:49:26 -0600 Date: Mon, 11 Jun 2001 10:49:26 -0600 Message-Id: <200106111649.f5BGnQN25832@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: linux-kernel@vger.kernel.org, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: [PATCH] devfs v180 available Sender: owner-devfs@oss.sgi.com Precedence: bulk Hi, all. Version 180 of my devfs patch is now available from: http://www.atnf.csiro.au/~rgooch/linux/kernel-patches.html The devfs FAQ is also available here. Patch directly available from: ftp://ftp.??.kernel.org/pub/linux/kernel/people/rgooch/v2.4/devfs-patch-current.gz AND: ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/kernel-patches/v2.4/devfs-patch-current.gz This is against 2.4.5. Highlights of this release: - Fixed !CONFIG_DEVFS_FS stub declaration of Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Thu Jun 14 15:01:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5EM1V705850 for devfs-outgoing; Thu, 14 Jun 2001 15:01:31 -0700 Received: from mail.labsysgrp.com (phnx1-blk2-hfc-0251-d1db10f1.rdc1.az.coxatwork.com [209.219.16.241]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5EM1Rk05844 for ; Thu, 14 Jun 2001 15:01:28 -0700 Received: from jeeves.kpf.internal ([192.168.170.1]) by mail.labsysgrp.com with esmtp (Exim 3.22 #2) id 15AfB1-0001zR-00 for devfs@oss.sgi.com; Thu, 14 Jun 2001 15:01:21 -0700 Received: from [192.168.170.101] (helo=labsysgrp.com) by jeeves.kpf.internal with esmtp (Exim 3.22 #3) id 15AdRq-0002O3-00 for devfs@oss.sgi.com; Thu, 14 Jun 2001 13:10:34 -0700 Message-ID: <3B2856F9.DBEC6502@labsysgrp.com> Date: Thu, 14 Jun 2001 13:17:29 +0700 From: "Kevin P. Fleming" Organization: LSG, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.6-pre3 i686) X-Accept-Language: en MIME-Version: 1.0 To: devfs@oss.sgi.com Subject: [PATCH] devfsd-1.3.11 old compatibility names Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-devfs@oss.sgi.com Precedence: bulk The attached patch is against devfsd-1.3.11 (downloaded today). The problem it fixes can best be explained by example... I use the Universal TUN/TAP network device driver, and it registers a "misc" character device called "net/tun". The devfs core registers this device as /dev/misc/net/tun, and this is fine. When devfsd gets the event for this registration, it creates a symlink at /dev/net/tun, but the link points to "misc/net/tun", so it does not work as the link not located at /dev. The patch adds a "../" prefix to the symlink destination path for every "/" character in the compatibility name about to be added. Works fine for me... --- cut here --- --- devfsd/devfsd.c Tue Feb 6 13:13:19 2001 +++ devfsd-new/devfsd.c Fri Jun 15 02:38:19 2001 @@ -1253,6 +1253,7 @@ { const char *compat_name = NULL; const char *dest_name = info->devname; + const char *compat_ptr; char *ptr; char compat_buf[STRING_LENGTH], dest_buf[STRING_LENGTH]; static char function_name[] = "action_compat"; @@ -1264,6 +1265,17 @@ case AC_RMOLDCOMPAT: compat_name = get_old_name (info->devname, info->namelen, compat_buf, info->major, info->minor); + if (compat_name != NULL) { + /* If the compat_name has leading directories, the dest_name will need leading ".." to match */ + dest_buf[0] = '\0'; + for (compat_ptr = compat_name; *compat_ptr != '\0'; compat_ptr++) { + if (*compat_ptr == '/') { + strcat(dest_buf, "../"); + } + } + strcat(dest_buf, info->devname); + dest_name = dest_buf; + } break; case AC_MKNEWCOMPAT: case AC_RMNEWCOMPAT: From owner-devfs@oss.sgi.com Sun Jun 17 23:01:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5I61uD02942 for devfs-outgoing; Sun, 17 Jun 2001 23:01:56 -0700 Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5I61jV02939 for ; Sun, 17 Jun 2001 23:01:50 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id f5I613D29992; Mon, 18 Jun 2001 00:01:03 -0600 Date: Mon, 18 Jun 2001 00:01:03 -0600 Message-Id: <200106180601.f5I613D29992@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: linux-kernel@vger.kernel.org, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: [PATCH] devfs v181 available Sender: owner-devfs@oss.sgi.com Precedence: bulk Hi, all. Version 181 of my devfs patch is now available from: http://www.atnf.csiro.au/~rgooch/linux/kernel-patches.html The devfs FAQ is also available here. Patch directly available from: ftp://ftp.??.kernel.org/pub/linux/kernel/people/rgooch/v2.4/devfs-patch-current.gz AND: ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/kernel-patches/v2.4/devfs-patch-current.gz This is against 2.4.6-pre3. Highlights of this release: - Answered question posed by Al Viro and removed his comments from - Moved setting of registered flag after other fields are changed - Fixed race between and - Global VFS changes added bogus BKL to devfsd_close(): removed - Widened locking in and - Replaced stack usage with kmalloc - Simplified locking in and fixed memory leak Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Sun Jun 17 23:40:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5I6eVt03448 for devfs-outgoing; Sun, 17 Jun 2001 23:40:31 -0700 Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5I6eUV03445 for ; Sun, 17 Jun 2001 23:40:30 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id f5I6eLS30459; Mon, 18 Jun 2001 00:40:21 -0600 Date: Mon, 18 Jun 2001 00:40:21 -0600 Message-Id: <200106180640.f5I6eLS30459@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Alexander Viro Cc: linux-kernel@vger.kernel.org, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: Re: [PATCH] devfs v181 available In-Reply-To: References: <200106180601.f5I613D29992@vindaloo.ras.ucalgary.ca> Sender: owner-devfs@oss.sgi.com Precedence: bulk Alexander Viro writes: > > > On Mon, 18 Jun 2001, Richard Gooch wrote: > > > - Widened locking in and > > No, you hadn't. Both vfs_readlink() and vfs_follow_link() are blocking > functions, so BKL is worthless there. Huh? The BKL will protect against other operations which might cause the devfs entry to be unregistered, where those other operations also grab the BKL. So, it's an improvement. Sure, some operations may cause unregistration without grabbing the BKL, but that's orthogonal (and requires more extensive changes). If this "widening" is of no use, then what use are the existing grabs of the BKL in those functions? You're the one who added them in the first place. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Mon Jun 18 08:16:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IFGST11651 for devfs-outgoing; Mon, 18 Jun 2001 08:16:28 -0700 Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IFGPV11648 for ; Mon, 18 Jun 2001 08:16:25 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id f5IFFcA00598; Mon, 18 Jun 2001 09:15:38 -0600 Date: Mon, 18 Jun 2001 09:15:38 -0600 Message-Id: <200106181515.f5IFFcA00598@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Alexander Viro Cc: linux-kernel@vger.kernel.org, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: Re: [PATCH] devfs v181 available In-Reply-To: References: <200106180640.f5I6eLS30459@vindaloo.ras.ucalgary.ca> Sender: owner-devfs@oss.sgi.com Precedence: bulk Alexander Viro writes: > On Mon, 18 Jun 2001, Richard Gooch wrote: > > Alexander Viro writes: > > > On Mon, 18 Jun 2001, Richard Gooch wrote: > > > > - Widened locking in and > > > > > > No, you hadn't. Both vfs_readlink() and vfs_follow_link() are blocking > > > functions, so BKL is worthless there. > > > > Huh? The BKL will protect against other operations which might cause > > the devfs entry to be unregistered, where those other operations also > > grab the BKL. So, it's an improvement. > > BKL is released as soon as you block. You _do_ regain it when you get > the next timeslice, but in the meanwhile anything could happen. > > > Sure, some operations may cause unregistration without grabbing the > > Irrelevant. BKL provides an exclusion only on non-blocking areas. Yeah, I know all that. > > BKL, but that's orthogonal (and requires more extensive changes). If > > this "widening" is of no use, then what use are the existing grabs of > > the BKL in those functions? You're the one who added them in the first > > place. > > _Moved_ them there from the callers of these functions. And AFAICS > you do need BKL for get_devfs_entry_...(); otherwise relocation of > the table will be able to screw you inside of that function. Now, it > will merrily screw you anyway in a lot of places, but that's another > story. OK, so it was another global change. > BTW, free advice: when you are checking some condition treat the > result as something that can expire. And don't rely on it past the > moment when it might expired. E.g. in case of de->registered result > expires as soon as you do unlock_kernel() _or_ do anything that > might block. Yeah, I know. Fear not: I'll be adding proper locks (spinlocks and semaphores) to the code, continuing the work I started this weekend. I don't like the BKL anyway (too coarse grained), and hope to see it removed entirely one day. Question: assuming data fed to vfs_follow_link() is "safe", does it need the BKL? I can see that vfs_readlink() obviously doesn't need it. From reading Documentation/filesystems/Locking I suspect it doesn't need the BKL, but the way I read it says "follow_link() method does not *have* the BKL already". But that doesn't explicitely say whether vfs_follow_link() needs it. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Mon Jun 18 11:53:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5IIrPp20388 for devfs-outgoing; Mon, 18 Jun 2001 11:53:25 -0700 Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5IIrLV20385 for ; Mon, 18 Jun 2001 11:53:21 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id f5IIr6u02682; Mon, 18 Jun 2001 12:53:06 -0600 Date: Mon, 18 Jun 2001 12:53:06 -0600 Message-Id: <200106181853.f5IIr6u02682@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Alexander Viro Cc: linux-kernel@vger.kernel.org, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: Re: [PATCH] devfs v181 available In-Reply-To: References: <200106181515.f5IFFcA00598@vindaloo.ras.ucalgary.ca> Sender: owner-devfs@oss.sgi.com Precedence: bulk Alexander Viro writes: > > > On Mon, 18 Jun 2001, Richard Gooch wrote: > > > > Irrelevant. BKL provides an exclusion only on non-blocking areas. > > > > Yeah, I know all that. > > So what the hell are you talking about? Never mind. We seem to be talking at cross purposes. We both know how the BKL works and the implications, so there's not much point beating our heads trying to communicate redundant information :-) > > > _Moved_ them there from the callers of these functions. And AFAICS > > > you do need BKL for get_devfs_entry_...(); otherwise relocation of > > > the table will be able to screw you inside of that function. Now, it > > > will merrily screw you anyway in a lot of places, but that's another > > > story. > > > > OK, so it was another global change. > > Moving BKL into the ->readlink() and ->follow_link()? Sure, it was a global > change. About a year ago. > > > Question: assuming data fed to vfs_follow_link() is "safe", does it > ^^^^^^^^ > > need the BKL? I can see that vfs_readlink() obviously doesn't need > > it. From reading Documentation/filesystems/Locking I suspect it > > doesn't need the BKL, but the way I read it says "follow_link() method > > does not *have* the BKL already". But that doesn't explicitely say > > whether vfs_follow_link() needs it. > > vfs_follow_link() doesn't need it. Moreover, if data fed to it is > unsafe without BKL, you are screwed even if you take BKL. So > assumption above is bogus - you _never_ need BKL on that call. OK, you didn't see what I was driving at. If I had said "if my data is protected by a semaphore, do I still need the BKL for vfs_follow_link()" I guess it would have been clearer. Anyway, you've answered my question, thanks. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Fri Jun 22 08:13:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5MFDqT06572 for devfs-outgoing; Fri, 22 Jun 2001 08:13:52 -0700 Received: from nova.botz.org (adsl-63-207-97-74.dsl.snfc21.pacbell.net [63.207.97.74]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5MFDoV06569 for ; Fri, 22 Jun 2001 08:13:50 -0700 Received: from localhost (jbotz@localhost) by nova.botz.org (8.11.2/8.11.2) with ESMTP id f5MFDjV03760 for ; Fri, 22 Jun 2001 08:13:45 -0700 Message-Id: <200106221513.f5MFDjV03760@nova.botz.org> X-Mailer: exmh version 2.4 05/15/2001 with nmh-1.0.4 To: devfs@oss.sgi.com Subject: devfs and module 'post-install' commands Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 22 Jun 2001 08:13:45 -0700 From: Jurgen Botz Sender: owner-devfs@oss.sgi.com Precedence: bulk I just discovered an interesting little problem... on my RH 7.1 system which I have configured to use devfs I've always had the problem that I'd lose my mixer settings after the sound module got auto-unloaded and later auto-loaded when something tried to play a sound. Now RedHat has the following in modules.conf that's supposed to prevent this: post-install sound-slot-0 /bin/aumix-minimal -f /etc/.aumixrc -L pre-remove sound-slot-0 /bin/aumix-minimal -f /etc/.aumixrc -S I finally spent some time investigating this and found that the that aumix-minimal wants to open /dev/mixer, but /dev/mixer is a symlink to /dev/sound/mixer which devfsd creates. Well, the problem is that when the post-install command runs devfsd hasn't had a chance to do this yet! It isn't just timing... inserting a delay in the post-install command above doesn't help. Apparently the event doesn't get sent to devfsd until after all the post-install commands have run? Is that right, Richard? Anyway, the simple solution is to explicitly tell aumix to use the real devfs device name i.e. post-install sound-slot-0 /bin/aumix-minimal -d /dev/sound/mixer -f /etc/.aumixrc -L This solution should work for most other cases where a post-install command is needed since any program to do something with a device should have an option for specifying the name. I thought I should mention it on the list in case someone else gets bitten by this... --jurgen From owner-devfs@oss.sgi.com Fri Jun 22 09:23:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5MGNbT08406 for devfs-outgoing; Fri, 22 Jun 2001 09:23:37 -0700 Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5MGNYV08403 for ; Fri, 22 Jun 2001 09:23:34 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id f5MGNPp23955; Fri, 22 Jun 2001 10:23:25 -0600 Date: Fri, 22 Jun 2001 10:23:25 -0600 Message-Id: <200106221623.f5MGNPp23955@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Jurgen Botz Cc: devfs@oss.sgi.com Subject: Re: devfs and module 'post-install' commands In-Reply-To: <200106221513.f5MFDjV03760@nova.botz.org> References: <200106221513.f5MFDjV03760@nova.botz.org> Sender: owner-devfs@oss.sgi.com Precedence: bulk Jurgen Botz writes: > I just discovered an interesting little problem... on my RH 7.1 system > which I have configured to use devfs I've always had the problem that > I'd lose my mixer settings after the sound module got auto-unloaded > and later auto-loaded when something tried to play a sound. Now > RedHat has the following in modules.conf that's supposed to prevent > this: > > post-install sound-slot-0 /bin/aumix-minimal -f /etc/.aumixrc -L > pre-remove sound-slot-0 /bin/aumix-minimal -f /etc/.aumixrc -S > > I finally spent some time investigating this and found that the > that aumix-minimal wants to open /dev/mixer, but /dev/mixer is > a symlink to /dev/sound/mixer which devfsd creates. Well, the > problem is that when the post-install command runs devfsd hasn't > had a chance to do this yet! It isn't just timing... inserting > a delay in the post-install command above doesn't help. > Apparently the event doesn't get sent to devfsd until after > all the post-install commands have run? Is that right, Richard? Correct. Since devfsd is single-threaded, it has to wait for all actions for an event to finish processing before it can grab the next event from the queue. Threading devfsd is something I really don't want to do. It would complicate the user-space and kernel-space code considerably, and lead to subtle bugs (more subtle than the interaction you've noticed). > Anyway, the simple solution is to explicitly tell aumix to use the > real devfs device name i.e. > > post-install sound-slot-0 /bin/aumix-minimal -d /dev/sound/mixer -f > /etc/.aumixrc -L I'd say this is the right solution. > This solution should work for most other cases where a post-install > command is needed since any program to do something with a device > should have an option for specifying the name. I thought I should > mention it on the list in case someone else gets bitten by this... Thanks. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Sun Jun 24 00:54:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5O7sab26108 for devfs-outgoing; Sun, 24 Jun 2001 00:54:36 -0700 Received: from legba.tvnet.hu (legba.tvnet.hu [195.38.96.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5O7sZV26103 for ; Sun, 24 Jun 2001 00:54:35 -0700 Received: from dumballah.tvnet.hu (zeus.city.tvnet.hu [195.38.100.182]) by legba.tvnet.hu (8.9.3+Sun/8.9.3) with ESMTP id JAA08207 for ; Sun, 24 Jun 2001 09:54:33 +0200 (MEST) Message-ID: <3B359D18.9060709@dumballah.tvnet.hu> Date: Sun, 24 Jun 2001 09:56:08 +0200 From: Sipos Ferenc User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.6-pre5-xfs i686; en-US; rv:0.9.1) Gecko/20010608 X-Accept-Language: en-us MIME-Version: 1.0 To: devfs@oss.sgi.com Subject: raw devices Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-devfs@oss.sgi.com Precedence: bulk Hi! How can raw devices be created under devfs? There is no /dev/rawctl device in the compatibility mode, perhaps the naming scheme has changed. What has to be compiled into the kernel for raw devices? I'd like to link my dvd drive as a raw device. Thx for any help in advance. Paco From owner-devfs@oss.sgi.com Wed Jun 27 08:31:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5RFV9r16218 for devfs-outgoing; Wed, 27 Jun 2001 08:31:09 -0700 Received: from odin.oce.srci.oce.int ([208.187.172.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5RFV7V16215 for ; Wed, 27 Jun 2001 08:31:07 -0700 Received: from srci.iwpsd.org (widmers.oce.srci.oce.int [10.2.1.34]) by odin.oce.srci.oce.int; Wed, 27 Jun 2001 09:30:45 -0600 Message-ID: <3B39FBCA.8010004@srci.iwpsd.org> Date: Wed, 27 Jun 2001 09:29:14 -0600 From: "Joshua M. Schmidlkofer" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.1+) Gecko/20010625 X-Accept-Language: en-us MIME-Version: 1.0 To: devfs@oss.sgi.com Subject: Strange behaviour under RedHat 7.1, Vanilla 2.4.5 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-devfs@oss.sgi.com Precedence: bulk Redhat 7.1, ext2 fs's AMD k6-2, 230Meg, 20 gig HD Vanilla 2.4.5 Kernel Alsa, and Nvidia drivers devfsd 1.3.11 For the first time since I started using devfs in the 2.2.x release kernels, I am experiencing problems that seem to be related to it. I don't know if I have misconfig'd something, but out of about 10 machines, one, my home machine is now having issues w/devfs. After I boot, everything runs ok, and I login to a console term, it's ok. As soon as the first PTY is used, everything goes to hell in a handbasket. /dev stops responding, and any process seeking, opening, or closing any devices in /dev is immediatly hung. Sometimes after hours the system will recover. I have had reports of 'Unable to remove vc/xx - file not found', in my syslog, occasionally I will also see something related to 'pts/x'. [This error is not verbatim, I apologize, It is at home, and I have not been able to get a peice of mail out yet. *sigh* Plus the keyboard died on my FW [argh]]. Also, IF the system comes back, then an 'ls' in the 'dev/pts' directory finds something like 'm0' - 'm255', or maybe 'b0' - 'b255'. It has only comeback twice since this all started. I have two kernels, one I believe DOES have the devpts filesystem option, the other does not. However, in any case that does not seem to make a difference. The only changes that I have recently made was adding some options to my devfsd.conf to change default ownership on alsa & oss-compatibility devices. This is a precursor, if it would be usefull, i can post my .config, devfsd.conf, etc. If I can get the system to remain stable for long enough, I will remove the rule, and see if it affects the system. I have also noticed wierdness w/devfsd. It does not always behave according to what I would expect, and sometimes I think that I must be using the rules incorrectly in the config file. I hope this is not too vague. thanks, Joshua From owner-devfs@oss.sgi.com Wed Jun 27 22:48:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5S5mf825646 for devfs-outgoing; Wed, 27 Jun 2001 22:48:41 -0700 Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5S5mdV25643 for ; Wed, 27 Jun 2001 22:48:39 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id f5S5mNX03812; Wed, 27 Jun 2001 23:48:23 -0600 Date: Wed, 27 Jun 2001 23:48:23 -0600 Message-Id: <200106280548.f5S5mNX03812@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: "Joshua M. Schmidlkofer" Cc: devfs@oss.sgi.com Subject: Re: Strange behaviour under RedHat 7.1, Vanilla 2.4.5 In-Reply-To: <3B39FBCA.8010004@srci.iwpsd.org> References: <3B39FBCA.8010004@srci.iwpsd.org> Sender: owner-devfs@oss.sgi.com Precedence: bulk Joshua M. Schmidlkofer writes: > Redhat 7.1, ext2 fs's > AMD k6-2, 230Meg, 20 gig HD > Vanilla 2.4.5 Kernel > Alsa, and Nvidia drivers > devfsd 1.3.11 > > For the first time since I started using devfs in the 2.2.x release > kernels, I am experiencing problems that seem to be related to it. I > don't know if I have misconfig'd something, but out of about 10 > machines, one, my home machine is now having issues w/devfs. After I > boot, everything runs ok, and I login to a console term, it's ok. As > soon as the first PTY is used, everything goes to hell in a handbasket. > /dev stops responding, and any process seeking, opening, or closing > any devices in /dev is immediatly hung. Sometimes after hours the > system will recover. I have had reports of 'Unable to remove vc/xx - > file not found', in my syslog, occasionally I will also see something > related to 'pts/x'. [This error is not verbatim, I apologize, It is at > home, and I have not been able to get a peice of mail out yet. *sigh* > Plus the keyboard died on my FW [argh]]. > > Also, IF the system comes back, then an 'ls' in the 'dev/pts' directory > finds something like 'm0' - 'm255', or maybe 'b0' - 'b255'. It has > only comeback twice since this all started. > > I have two kernels, one I believe DOES have the devpts filesystem > option, the other does not. However, in any case that does not seem to > make a difference. > > The only changes that I have recently made was adding some options to my > devfsd.conf to change default ownership on alsa & oss-compatibility > devices. This is a precursor, if it would be usefull, i can post my > .config, devfsd.conf, etc. If I can get the system to remain stable for > long enough, I will remove the rule, and see if it affects the system. > > I have also noticed wierdness w/devfsd. It does not always behave > according to what I would expect, and sometimes I think that I must be > using the rules incorrectly in the config file. > > I hope this is not too vague. Erm, well, actually, it is. Config files would be useful. In any case, I'm away for holidays for 2.5 weeks, so if no-one else can help you by then, repost your message. Stuff sent before that will probably hit the bit-bucket. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Thu Jun 28 06:49:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5SDnN325918 for devfs-outgoing; Thu, 28 Jun 2001 06:49:23 -0700 Received: from odin.oce.srci.oce.int ([208.187.172.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5SDnLV25912 for ; Thu, 28 Jun 2001 06:49:21 -0700 Received: from srci.iwpsd.org (widmers.oce.srci.oce.int [10.2.1.34]) by odin.oce.srci.oce.int; Thu, 28 Jun 2001 07:49:14 -0600 Message-ID: <3B3B357C.3050204@srci.iwpsd.org> Date: Thu, 28 Jun 2001 07:47:40 -0600 From: "Joshua M. Schmidlkofer" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.1+) Gecko/20010627 X-Accept-Language: en-us MIME-Version: 1.0 To: Richard Gooch , devfs Subject: Re: Strange behaviour under RedHat 7.1, Vanilla 2.4.5 References: <3B39FBCA.8010004@srci.iwpsd.org> <200106280548.f5S5mNX03812@vindaloo.ras.ucalgary.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-devfs@oss.sgi.com Precedence: bulk > > >Erm, well, actually, it is. Config files would be useful. > >In any case, I'm away for holidays for 2.5 weeks, so if no-one else >can help you by then, repost your message. Stuff sent before that will >probably hit the bit-bucket. > > Regards, > > Richard.... >Permanent: rgooch@atnf.csiro.au >Current: rgooch@ras.ucalgary.ca > I patched up to devfs 1.80, and everything is working much better. I am convinced that there is just general wierdness w/2.4.5, besides devfs issues. Also, the whole system got a speed boost from this upgrade ????. I tried it [180] out on several other machines, and had similar results. Especially: Connections via ssh init'd faster [i.e once you successfully authenticate..] The extremelly noticable change, was opening new terminals under X. rxvt, xterm, konsole, gnome-terminal - all opened with... unexpected quickness after the change to 180. I have no evidence to back this up. I have 2 or three systems using devfs + devpts. And 5 or 6 using devfs + a "CREATE... PERMISSIONS" rule for /dev//pts/.* in devfsd.conf. On the 2 systems w/devfs + devpts, they are running fine, and the devfs only systems are getting better w/devfs180. On the system I was writing about, I killed the rule affecting pts/, and the system at least functioned after that. If you still want a config, I will send it. I will include more information about my problem if I have cause to post again. thanks, Joshua >