From owner-devfs@oss.sgi.com Wed Apr 12 23:33:05 2000 Received: by oss.sgi.com id ; Wed, 12 Apr 2000 23:32:56 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:1666 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Wed, 12 Apr 2000 23:32:41 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e3D6WLl05952; Thu, 13 Apr 2000 00:32:21 -0600 Date: Thu, 13 Apr 2000 00:32:21 -0600 Message-Id: <200004130632.e3D6WLl05952@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Martin Costabel Cc: devfs@oss.sgi.com Subject: Re: Some basic problems with devfs In-Reply-To: <38D56BBC.3F4B01F6@wanadoo.fr> References: <200003151742.JAA17128@nova.botz.org> <38D56BBC.3F4B01F6@wanadoo.fr> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Martin Costabel writes: > Hi, > > I have only recently started to use kernels with devfs enabled, and I > have some newbie questions. I don't know if this list is the right place > to ask them, but this is already my first question: > > Is there a faq or howto for devfs, other than the far too short and > technical kernel source filesystems/devfs/README? By wading through > thousands of linux-kernel messages, I found some informations, so I am > now starting "devfsd /dev" at the beginning of rc.sysinit, and I have > learned from Doug Gilbert's page at > http://www.torque.net/sg/devfs_scsi.html how to open some security holes > so that I can login as root or start X as non-root. FAQ under construction. > But a couple of things still don't work, in particular my printer, > floppy, cd, and gpm, and this leads to 3 different questions: > > 1. My printer uses /dev/ttyS1, and when I used devfs for the first time > with kernel 2.3.51, there was no such device. Instead of ttyS0-3 there > was only a /dev/ttyS with major 4, minor 64. 3 days ago, I booted with a > kernel 2.3.52, and suddenly the devices ttyS0 and ttyS1 (which > correspond to the 2 serial ports I have) were back. Printing worked. Now > yesterday I booted with 2.3.99-pre2, and I was back to square one: no > ttyS1, only a ttyS. All 3 kernels used basically the same config options > and the same kernel command line, and devfsd was started automatically > in the same way. Where does this difference come from and how can I make > sure that devfsd creates ttyS0 and ttyS1 as, according to README, it is > supposed to do? Where does devfsd get its list of devices from? How does > it decide which ones to create? The devices are created by the drivers, not by devfsd. Devfsd will only create compatibility symlinks (no real device nodes). > 2. There is no /dev/floppy nor fd0 or whatever. ToDo mentions that > swim3 is not yet supported. I have a Pmac 6400, and swim3 is its > floppy controller. Is there any way to use this floppy with devfs? Hack the code. > How hard is it to add devfs support to drivers/block/swim3.c? Should be fairly easy. > 3. Gpm doesn't start because /dev/mouse is missing. Normally, this > is a symlink to /dev/adbmouse. If I make such a link, it will > disappear upon reboot. Same problem with /dev/cdrom, /dev/modem and > many others that are created either by some programs or by myself > using mknod or symlinks. Is there a way to tell devfsd about such > things so that devfsd recreates them at reboot? The documentation on > devfsd (man devfsd) is too rudimentary to know. Does one have to use > the rc.devfs script and store these informations in some tar file? It's your choice. Probably editing your boot scripts is easier. Ultimately, having a /dev/mice or a /dev/mouse managed by the kernel might be better. Just like with /dev/cdroms. > Or is the recommended way after all to use 2 directories, /devfs for > devfs to play with, and /dev for the use of the rest of the kernel > with symlinks between the two? No. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Wed Apr 12 23:35:04 2000 Received: by oss.sgi.com id ; Wed, 12 Apr 2000 23:34:44 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:3202 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Wed, 12 Apr 2000 23:34:32 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e3D6YSL06073; Thu, 13 Apr 2000 00:34:28 -0600 Date: Thu, 13 Apr 2000 00:34:28 -0600 Message-Id: <200004130634.e3D6YSL06073@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Martin Costabel Cc: devfs@oss.sgi.com Subject: Re: Some basic problems with devfs In-Reply-To: <38D8A481.9E2D1CDA@wanadoo.fr> References: <200003151742.JAA17128@nova.botz.org> <38D56BBC.3F4B01F6@wanadoo.fr> <38D8A481.9E2D1CDA@wanadoo.fr> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Martin Costabel writes: > Nothing like answering your own questions (no one else volunteered) :-) > > Martin Costabel wrote: > > > 1. My printer uses /dev/ttyS1, and when I used devfs for the first time > > with kernel 2.3.51, there was no such device. Instead of ttyS0-3 there > > was only a /dev/ttyS with major 4, minor 64. 3 days ago, I booted with a > > kernel 2.3.52, and suddenly the devices ttyS0 and ttyS1 (which > > correspond to the 2 serial ports I have) were back. Printing worked. Now > > yesterday I booted with 2.3.99-pre2, and I was back to square one: no > > ttyS1, only a ttyS. All 3 kernels used basically the same config options > > and the same kernel command line, and devfsd was started automatically > > in the same way. Where does this difference come from and how can I make > > sure that devfsd creates ttyS0 and ttyS1 as, according to README, it is > > supposed to do? Where does devfsd get its list of devices from? How does > > it decide which ones to create? > > I got it working now. The problem was that I am using Macintosh > serial ports (compiled in with the MAC_SERIAL config option), and > drivers/macintosh/macserial.c was not yet devfs aware. I patched it > with some lines from drivers/char/serial.c, and I have now /dev/tts/ > and /dev/cua/ directories that were not there before. The 2.3.52 > kernel which worked also came from a different tree and apparently > had a patched version of the macserial.c file, too. Well, this is odd. I don't think my patch ever touched drivers/macintosh/macserial.c. Perhaps someone else did it and then removed it? Anyway, I'd like to see the patch so I can include it in the next devfs patch. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Wed Apr 12 23:58:55 2000 Received: by oss.sgi.com id ; Wed, 12 Apr 2000 23:58:45 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:8066 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Wed, 12 Apr 2000 23:58:21 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e3D6wHw06466; Thu, 13 Apr 2000 00:58:17 -0600 Date: Thu, 13 Apr 2000 00:58:17 -0600 Message-Id: <200004130658.e3D6wHw06466@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: tytso@mit.edu Cc: jurgen@botz.org, devfs@oss.sgi.com Subject: Re: ttyS1, S2, etc... In-Reply-To: <200003170543.AAA02886@trampoline.thunk.org> References: <200003161751.JAA24104@nova.botz.org> <200003170543.AAA02886@trampoline.thunk.org> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing [Apologies for the late response] tytso@mit.edu writes: > Date: Thu, 16 Mar 2000 09:51:18 -0800 > From: Jurgen Botz > > Richard Gooch wrote: > > In drivers/char/serial.c:register_serial() there are calls which > > create devfs entries. So the low-level serial driver should call > > register_serial() and everything should be fine. It certainly works > > for PCMCIA serial cards. Insert the card and the devfs entry magically > > appears. > > The problem is that ISA multiport serial cards don't appear to be > detected by the kernel at all and register_serial never gets called. > To use the ports you set the IO base and IRQ with setserial which > sets them in the driver with ioctls on the device. This bypasses > register_serial in the driver, too, so even if I create /dev/ttyS2 > and then do the setserial thing, /dev/tts/2 still doesn't appear > (but /dev/ttyS2 then works fine). Not that that would make a > difference for devfs, of course. > > Right. There are actually two parts to this problem. The first is that > when setserial calls TIOCSSERIAL to change the uart from "none" to > "non-none" and vice versa, tty_register_devfs() and > tty_unregister_devfs() needs to be called. I can fix this in the serial > driver fairly easily, and this will take care of the problem which you > reported. > > The second problem is how do you actually get setserial to set the port, > irq, and uart settings using only devfs in the first place. The issue > here is that you can't autodetect ISA multiport serial cards, at least > not those cards that don't have PNP support. The port and irq settings > either have to manually configured such as is the case for COM 1/2/3/4, > or the user has to manually set them using the setserial command. > > But, in a devfs only world, the device file doesn't appear until the > port is configured, but setserial needs the device file in order to > configure the port. There's no real way around this.... But is this a problem? If you configure devfsd to load the serial driver when you attempt a lookup of /dev/tts/0 (or whatever), then: # setserial /dev/tts/0 ... will just work. > That may not be worth the trouble to provide automatic devfs > support for the diminishing number of non-PNP ISA multiport > boards out there. Since I currently have to run an rc script > to configure the ports anyway, I might as well create the device > files there with mknod. > > Perhaps, but this isn't very satisfying; it's certainly very awkward > for users, and for people who were accustomed to things Just Working > (tm) in Linux 2.2, it's really, really, really ugly to tell them > that they have to manually mknod the device in devfs. However, > short of telling them (a) don't use devfs, or (b) hacking setserial > to automatically do the mknod if /dev/ttyS* is passed in and > /dev/ttyS* doesn't exist. Both aren't pretty solutions, though. Oh, definately there shouldn't be any need to mknod(2) in devfs. > I suppose we could shovel all of this dirt under the devfsd rug, and > make devfsd responsible for parsing some new serial configuration > file which then does the mknod and TIOCSERIAL ioctl. But that's not > that great of a solution either. No, I don't want devfsd to need intimate knowledge of device internals (I consider setserial part of the "internals"). Devfsd should only care about names, internally. > I'll need to think about this one some more. I'm not particularly > happy with any of these solutions. Richard, what do you think? I don't see why you can't just have devfsd load the module when you attempt a lookup of /dev/ttyS.* or whatever. Then the existing rc scripts which do: # setserial /dev/ttyS0 ... # setserial /dev/ttyS1 ... # setserial /dev/ttyS2 ... # setserial /dev/ttyS3 ... will just work. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Thu Apr 13 00:33:25 2000 Received: by oss.sgi.com id ; Thu, 13 Apr 2000 00:33:15 -0700 Received: from cm-24-142-61-146.cableco-op.ispchannel.com ([24.142.61.146]:9470 convert rfc822-to-8bit smtp "EHLO nova.botz.org") by oss.sgi.com with ESMTP id ; Thu, 13 Apr 2000 00:33:13 -0700 Received: from nova.botz.org (IDENT:jbotz@localhost [127.0.0.1]) by nova.botz.org (8.9.3/8.9.3) with ESMTP id AAA17540; Thu, 13 Apr 2000 00:32:50 -0700 Message-Id: <200004130732.AAA17540@nova.botz.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Richard Gooch Cc: tytso@mit.edu, devfs@oss.sgi.com Subject: Re: ttyS1, S2, etc... In-Reply-To: Your message of "Thu, 13 Apr 2000 00:58:17 MDT." <200004130658.e3D6wHw06466@vindaloo.ras.ucalgary.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8BIT Date: Thu, 13 Apr 2000 00:32:49 -0700 From: Jurgen Botz Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Richard Gooch wrote: > I don't see why you can't just have devfsd load the module when you > attempt a lookup of /dev/ttyS.* or whatever. Then the existing rc > scripts which do: > # setserial /dev/ttyS0 ... > # setserial /dev/ttyS1 ... > # setserial /dev/ttyS2 ... > # setserial /dev/ttyS3 ... Richard, you're missing the point. We aren't talking about the system board serial ports, we're talking about additional serial ports on dumb ISA multiport cards. Devfs will not create the devices for these because the driver, whether module or compiled-in, doesn't know they exist until serserial is called! You can currently compile the serial driver with options to be able to handle these cards, but the actual configuration (whether, how many, what IRQ, etc.) is not compiled in and can't be auto-sensed. So like I said originally, there's a chicken-and-egg problem... devfs can't create the device because it doesn't know the port exists, and setserial can't tell the driver that the port exists because there is no device on which to do the ioctls that are used to pass this info to the kernel. The point is that because these boards can't be auto-sensed we need to pass info to the kernel about the ports. Prior to devfs using ioctls on the devices made the most sense. Now, with devfs, the devices don't exist until we've talked to the kernel. So we need to find another way to pass the info to the kernel. module options and kernel command line are not a good solution because it's too much info if there are a lot of ports. - Jürgen From owner-devfs@oss.sgi.com Sat Apr 15 15:56:05 2000 Received: by oss.sgi.com id ; Sat, 15 Apr 2000 15:55:45 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:41091 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Sat, 15 Apr 2000 15:55:32 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e3FMtG425171; Sat, 15 Apr 2000 16:55:16 -0600 Date: Sat, 15 Apr 2000 16:55:16 -0600 Message-Id: <200004152255.e3FMtG425171@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Johannes Erdfelt Cc: devfs@oss.sgi.com Subject: Re: devfs and USB In-Reply-To: <20000413115522.W14581@valinux.com> References: <20000328144530.Z860@valinux.com> <200004130453.e3D4r9F04628@vindaloo.ras.ucalgary.ca> <20000413115522.W14581@valinux.com> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Hi, Johannes. I've also Cc'ed the devfs list, so interested parties can comment if they want. I'm assuming you won't mind. > > > What I would like to do is provide a write() function for the devfsd > > > pipe/device (/dev/.devfsd). And then allow device drivers (or in my > > > case, the USB subsystem) specify a flag while registering the device > > > that it would like devfsd to select a driver for it to use. > > > > > > When devfsd finishes it's logic and comes up with a driver, it > > > write()'s it back through the devfsd pipe/device and devfs will > > > store the information for the subsystem to retrieve. > > > > Why write back to the USB subsystem? Why not load the device driver > > directly? > > Well, you need to bind a driver to a device. You may have a dozen > drivers loaded, and 2 may be able to run the device correctly, but > one can run it better than the other. OK, I see now. > The issue of selecting a driver is complicated and best left to > userspace. Take a look at my example below. Yes, that's fair enough. > > Why do you want to overload devfs/devfsd? > > Since I wrote this email, I've changed my mind slightly. Some of what I said > above is not the best way of doing (like you've noticed). What i'm going to > say below will differ in some instances from what I said in the original > email. > > I don't want to overload devfs, I want to overload devfsd. The patch > implements exactly what I want do. But, I'll explain it quickly for > you here. OK, I'm a lot happier about hearing that. Changes to devfs for a specific driver subsystem are to be avoided. Strongly. [...] > We need a userspace daemon which tracks device insertion and removal > events and finds all of the appropriate information on the device > and chooses the correct driver to run the device. It then loads the > driver, if it's not loaded already. It then configures the device by > selecting the appropriate configuration and alternate setting. Then > it binds the driver to the device. This is all fine. > There's already a daemon which does this, devfsd. It already gets > informed of device insertion and removal and does things with that > information. I just want to be sure that you're not wanting to "hijack" the devfsd protocol. In other words, that it really does make sense to use devfsd rather than a new daemon (even if you don't modify the protocol). Just because it might be convenient (it's there, and it's easy to tap into), doesn't mean it should be used. On the other hand, it doesn't mean devfsd is the wrong approach, either. I just want to get a clear picture of what's going on. > This driver binding is done completely via ioctl()'s on the USB > device node, completely bypassing devfs (the kernel portion). The > current patch that I've sent makes no changes to devfs (the kernel > portion), only to devfsd (the user space portion). What exactly is this driver binding process? How does it work? > The example above is a quick example and gets much more complicated > when you factor in multiple interfaces and configurations, power > budgeting, bandwidth budgeting, etc. It's a complicated decisions > making process. That's fine. It's clear this needs to be done in user-space. > Another really quick example. I have a digital still camera. The > driver for this camera is in userspace in gphoto. We would like to > setup the permissions for the device to be accessable by a certain > group of users whenever the device is plugged in. However, the USB > id, which is what is used to create the device node for the USB > device, is arbitrary and can/will differ each time the user plugs in > the device. Why does the ID change? If you plug the same device into the same port, why does it change? Do you have unique sequence numbers or something? > We can use the same code to choose a driver, also track the device > and assign the correct permissions to it, no matter what it's device > node name of the moment is. Ah, I think the light begins to dawn. I noted how in your patch you were using the DEVFSD_NOTIFY_REGISTERED and DEVFSD_NOTIFY_UNREGISTERED events. I was thinking that you were just creating fake events (by trying to write to the /dev/.devfsd pipe yourself somehow) or by registering fake device entries. That's why I've been negative, as such a scheme would be a real abuse of devfs. Far cleaner to implement your own protocol and daemon. However, I'm now guessing that you register a real device entry (in other words, it's connected to a driver (in this case, the USB subsystem driver) and is the only way for user-space to talk to the device) in the USB subsystem, and you want devfsd to install the best driver and (somehow) attach that driver to the device entry. And you make the attachment using an ioctl(2) on the newly registered device driver. Furthermore, the attached device driver doesn't register a new device entry, the user must use the "generic" device entry created by the USB subsystem, except that it's not quite so generic once a driver gets attached. Is this a reasonable description of what happens and what you want to do? > Do you see this a good use for devfsd? Would you accept this feature > for inclusion into devfsd? If it's as I descibed just above, then it makes perfect sense to use devfsd. > I'm not asking for the particular patch I sent you to be included, > but rather for something like it. I can make changes to the patch, > or reimplment it if necessary. I have already changed my local copy > to use threads for instance. I'll implement part of what I'm planning for devfsd modularity so you can see how I want this done. I'll send a message to you and the devfs list when I've done this. Also, please subscribe to the devfs list by sending email to majordomo@oss.sgi.com and "subscribe devfs" in the body. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Sat Apr 15 16:33:05 2000 Received: by oss.sgi.com id ; Sat, 15 Apr 2000 16:32:55 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:45699 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Sat, 15 Apr 2000 16:32:40 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e3FNWOl25562; Sat, 15 Apr 2000 17:32:24 -0600 Date: Sat, 15 Apr 2000 17:32:24 -0600 Message-Id: <200004152332.e3FNWOl25562@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: "Dunlap, Randy" Cc: "'Michael H. Warfield'" , linux-kernel@vger.rutgers.edu, linux-usb@suse.com, devfs@oss.sgi.com Subject: RE: [linux-usb] DevFS and USB... In-Reply-To: References: Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Randy Dunlap writes: > Hi Mike, > > I haven't looked at it and I don't recall seeing > any email from anyone else on the linux-usb > mailing list who has looked at DevFS. > > I don't disagree with your (guesstimate) evaluation > of USB and DevFS. > > > Anyone even know what the USB hierarchy in the > > DevFS namespace should look like? > > I'm no expert (or even User yet) on DevFS. > My guess is simply /dev/usb/something. > Where would I look for some examples of other > devices/buses? > in linux/Documentation/filesystems/devfs/mk-devlinks > or ...................................../README ? The README. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Sat Apr 15 16:49:05 2000 Received: by oss.sgi.com id ; Sat, 15 Apr 2000 16:48:56 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:49027 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Sat, 15 Apr 2000 16:48:33 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e3FNmSD25778; Sat, 15 Apr 2000 17:48:28 -0600 Date: Sat, 15 Apr 2000 17:48:28 -0600 Message-Id: <200004152348.e3FNmSD25778@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: devfs@oss.sgi.com Subject: Re: Linux-2.3.51, and the pre-2.4 series.. In-Reply-To: <20000313085026.C2010@alcove.wittsend.com> References: <20000311112556.A8346@alcove.wittsend.com> <200003130145.MAA00687@mobilix.atnf.CSIRO.AU> <20000313085026.C2010@alcove.wittsend.com> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Michael H. Warfield writes: > > If there's problems with devfsd not putting in all the right > > compatibility symlinks, that's a bug that should be fixed. Send > > patches. I promise to intend to provide all compatibility links. I > > don't promise to be infallible (that incurs a surcharge). > > You need the following mappings to support the Computone device > driver names as described in devices.txt. > > /dev/ip2ipl[n] -> /dev/ip2/ipl[n] n = 0 - 3 > /dev/ip2stat[n] -> /dev/ip2/stat[n] n = 0 - 3 > /dev/ttyF[n] -> /dev/ttf/[n] n = 0 - 255 > /dev/cuf[n] -> /dev/cuf/[n] n = 0 - 255 > > (I followed the convention set by ttyS[n] -> tts/[n] and > cua[n] -> cua/[n]). I've just had a look at the driver, and I don't think it will create /dev/ttf/# entries. I think it will create /dev/ttf entries instead (i.e. all the same name). This is because of a change I made in devfs-patch-v155, which pushed the formatting into each TTY driver. Also, I don't see anywhere /dev/ip2/* being created. Has this been implemented? Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Sat Apr 15 22:02:36 2000 Received: by oss.sgi.com id ; Sat, 15 Apr 2000 22:02:26 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:31364 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Sat, 15 Apr 2000 22:02:06 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e3G50u929083; Sat, 15 Apr 2000 23:00:56 -0600 Date: Sat, 15 Apr 2000 23:00:56 -0600 Message-Id: <200004160500.e3G50u929083@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: linux-kernel@vger.rutgers.edu, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: [PATCH] devfs v162 available Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Hi, all. Version 162 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. This work has been sponsored by SGI. This is against 2.3.99-pre6-2. Highlights of this release: - Set inode->i_size to correct size for symlinks Thanks to Jeremy Fitzhardinge - Only give lookup() method to directories to comply with new VFS assumptions - Remove unnecessary tests in symlink methods - Don't kill existing block ops in - Restore auto-ownership for /dev/pty/m* Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Sat Apr 15 22:11:46 2000 Received: by oss.sgi.com id ; Sat, 15 Apr 2000 22:11:37 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:34692 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Sat, 15 Apr 2000 22:11:21 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e3G5ADo29273; Sat, 15 Apr 2000 23:10:13 -0600 Date: Sat, 15 Apr 2000 23:10:13 -0600 Message-Id: <200004160510.e3G5ADo29273@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: linux-kernel@vger.rutgers.edu, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: devfsd-v1.3.2 available Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Hi, all. I've just released version 1.3.2 of my devfsd (devfs daemon) at: http://www.atnf.csiro.au/~rgooch/linux/ This work has been sponsored by SGI. This works with devfs-patch-v130 and devfs-patch-v99.7 (or later). The main changes are: - bug fix with inclusion directives - support negative UID and GID in config file Thanks to Chris Richards - more efficient discarding of lookups on "/dev/log" and "/dev/initctl". Regards, Richard.... Old: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Sun Apr 16 00:11:26 2000 Received: by oss.sgi.com id ; Sun, 16 Apr 2000 00:11:07 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:51076 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Sun, 16 Apr 2000 00:10:40 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e3G7AaE30537; Sun, 16 Apr 2000 01:10:36 -0600 Date: Sun, 16 Apr 2000 01:10:36 -0600 Message-Id: <200004160710.e3G7AaE30537@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Johannes Erdfelt Cc: devfs@oss.sgi.com Subject: New devfsd to play with Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Hi, Johannes. I've just completed my first cut of the new, generic, shared object facility for devfsd. Take a look at the new "FUNCTION" action. This will allow you to run an arbitrary function in a shared object. I'm hoping that this will provide most (all?) of the functionality you need from devfsd. Comments welcome. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca begin 644 devfsd.tar.gz M'XL(`%UF^3@``^P[:W?BQI+Y:GY%A&S/##,^84!VR&#P`LYDSHR/ MCBRU0+&0=/7PXR:SOWVKNEM/P(;=3?;#7LXQ1OVHKG=75;<,=F<&QL$W?^4' M7C9/CH[@&P`X:;?H?[O9/.;/\M/$GN;)8#?.//75=?;!ZGNTLO"IG_=^#T-WX,(?\+[9:9ELW^DC5:*.V7+S?*O]5L M'7'YMXYPY%$;6PX/CXZ^@>9?@DWA\_]<_N\'H_Y@`N^$*`Z"&\LI]<:CL\&Y M>C88*MAQP$+]0*A)0W<=LU32;/O-GF@IE4KC][\HO=D41\I!+K`'SV=!8+E. MPRV5+--@)GQ0)B-EJ.)BI=[9L'M.$^KC-M0'#?S[KI+V5P\L1[_X2ZB8.$TRK'L3M5/:JPM,]_\3 M]E$<^.=;J@VQ*R>ZSVBDUF$4.E5H?7Z]:LZ"AGCNHFE+S3?@'-BKQ@[6U@!>+X[ M][4EX$_39PP"UPSO-9]UX-&-0-<<\!GY*]^Z0;:#%8+F&`>X[-)%Y_[(`6%C MY!C,)Q<)*)ME`*[)'\Y'5W#.'.9K-EQ&-[:E([HZQG@$IG08@\PGVPO60I`5"1"+O+=Q<;AA$`3,CN\9AX&CX.)C]/+Z: M07?T"3YV)Y/N:/:I@Z/#A8N][(X)6-;2LRT$C83YFA,^(OY"TLJD]S/.Z;X? M#`>S3T@&G`UF(V4ZA;/Q!+IPV9W,!KVK87<"EU>3R_%4:0!,&2'&.(0GV&QR M42$G#19JEAU(TC^A<`-$SS9@H=TQ%++.K#M$3@,=5>AY^7$HFNTZH^4$`W3L4:$];WOB6,<>? M%UUHMEN'KVMP->U*(G(Z#4OMD83C,TT7*@5LB10#R@Z$5_E)"QVSH0>6[S:T M2*H``\^EL`$TPZ!H"17A34F$83GX-=`/7.C.1FO?JO$Y6+\9?>&BW,AS3//G MT1)YCZ;N&,BF>0/!R=7J1AD"M&!]L2W*ARLHTYZ,NEH/+<0#C4^_%:X-]3QT M===&U.^LC-]]=HF7F26F(3E?Q\4\A.)[E#TYIRA`,DI\6T1>`!+G/V(_2GC) M_0E4[A=6ZA3(#^,L6K:Z+1)'*W2B/>ND/`@-8Y`&&K/FW)*B(^\O+8:>[KWO MNKK'*ZMK.B<,O4JDAY'/MH5TLJIB"_1X M0L?(.LM+)_28.&;#@0X(!]RHHY^!VRY7;.>WBJD^R M=2%@GN;SJ1PF`B/N2+8+?R,"LL!CNF5:&$MLNV2S/N[-Y)+"-,-'SR7;-!@: MZ3S5JJUI2`'&EFS.8U-./`9F_.@54\VUD3*,`:#/;#0,\L_4BIN,[-<]C&I((4XP"$=H2-VO"Z6S*^3+G80'J//I\W+-"#`TFROE@.E,F MNWGZ]M$*+>10T(QO+-O","D6>*((^6ZR?8L%?`,***"HH>/A>T`-[BR#N2]M MBI"Q%:5KV\P&?$8^%B>LN#WA(8X: MH#R0($A;?Z?=$M=?HF?SP8F6-[@^;6Z&JP;(;Q4[U8#YY-U.I:HCF,V43XGR M][86T-[7Z]:S#I7O0'TUX-EAA!U\6&(SF*"8/.$>2_.'KT4,0.-O()=97_ M0#4]6!@II^A9-W+T1K:Q2P_C#"B1Y\=N.BO=>L[4:[\8#`;IGO,'MK^1QE(#_/C25Z!F;; MFL,P*0("A3L`;3:[*<5)9M&^2SDC8`YY(\.??T8L8ES`".UWS#Q1U4,>N,ER M$449.P5)S2S[[C4/*+'@B48:%!&%%K.-@+0J$R!MO_%G:$(V42?Z_-O("P!# MKG(\HSY3TOCKV!]W'0A%:A.52] M0.O`;?R&55Y5$1KF[%%`%D1:4U9^4WI7,V7G]2ZZDWB]B!CU(.#QN%J&"4+A M<=O8WFA2J+&6.VRN$0RX&O0Y4>?XWW*XRTAE)+,7LJS>PD<*)6C,7G1?_/SI M/G`;M$U8VC)H,"/:.GMIU[N7,5H7%+0ST[1TBU35$((6205"6ROP=>(62P\Q MPH$H77]-XI0N+17D[&K4H\PB(S&JR;R(,YJWD6,%H=%8G&;:L,%R5YILZZ;8 MYE-"G6O3,;AG^2;OO@!^[GL%0(_!`270JZT!9L!KQC[2/KO2?*]9:P9;+K(P MWTRJYA2&FKI3',9C9W$NH9K!NKY;[%3#=3T\S%U!!N5;:,/$3BLLZ[,Y>\@W M,=]W"@(Q;,0XWW2K^4N-FK#-=.C$$X.28_6B^\MX`O)#Q?8!>BPM0)_)?J"B M4&391K(O:%2U$MHJM@8`4A>J-E`ZM0+QU:M\YTFN\W6^\U6V\W4SW_DZU]DJ MO9!'J*477B47$Z[*+[F]J=G$^A<@P_0JM* M=2!!=1=T$3XS;?1,Z%ONT_R&Y0(3A2*S56ZT5<3#H"$&?2\.V[YU9!?OD^[KD) MAO%9`6["2XUJ7#&M_'Q`"G?!-`/'K3*[VU,OEJ+%S2YVI%3@6XW@,EK"`0D1.7PLZ-!#$>42A)K#Y,GBU^T"#CJI3\X M)`JQU9#_Z_"&R#+P&;_%XYP_SNGQ:R\^)Q:,YGO= M$;Z,=S2O84F!GV;?:X^4!_"3A/2H@:R,5B&PY!;E:B(D4'D!55W3UHG1TC7; M5LW(204DD9/]`>+(#-6]^9W\Q'[@"AJ1B5#9IWDH9'I`9#%G%A1QDFJEO3V> MCH4Q*.&Z5'$N$B.U3]7=S-@LDK#/_U4[NW`+0Q[B4$R2J*(G'\FM5;645$<. M;5O\H#`$TM/.NF;FY$2[AMEY)F;6D;\%6+X=HJYX^"->2$2,J.JEO0UJF&WH M)*.R^A4_I+VK8DXX)!;^*I;O9-%>IT3[#GL(<]3/6:C&!6:5I!EK]W:R%ROB M1C>=21'+DY*,U.4!R.?I;#(8G:M#970^^_DZAT5.3R4&6:`IQ#O7,F"?GYFP MSA.JGA+*=SCE`7=0#&@2O@58VRF3,/%[4%:HQL9>^=4?[:9Y6BE@M74S'1#3R5'G>IL9EBDJUDQN5.=/+8TJY M"HD$'3#Q2QSI:S9'/.4-/X?>Y[FP2EEN`3H557DME4(:[H5,HU:8O7&RK,*J MW#]4ME36`@QIUQE[W!J2$%%N\%ISBSW@FF5Q`[)=S=AMR17+W'55Z5K^YE5S M_FM')O]/E^95H)WIS1FX`%6`3Q=S$N-856U1W)%JG7:+8(.<`/Z*L1)&)9+6 M=.@\&3I_;JB,:6@L_7QZL+`?Y*%PHKY`$AO2(5E;SSJL#?XJZZ-6&$%1GAH' M>6M<0.%G%0@1"P5N M<726)_P`4>7W,XK#.(L=-Q;>.SCK#J=*OCL?S:^,X6OPTK;*XWL:[#2-@R:U4=')R36W9#.&`[GVMFS'#3EI)Y;6.&.Q)8E'Y+VM=(4TO.BIQ:?$=S"97 M2IH>F/S$%J6B^NR.S`C59$TT+6I08A':I@M#"INX$'\V:+/F\B@?;5/-!M?Q M`+IH0E\WD1EWI)H5T>$+"93?LJ&KF.+6!'RNWUWCET%?(9WDTH\^K[73+W-^ M7>Z(TB6EI,1A>`OM:ARZK^29Y2M:Z%S!=&)[#''BQT#ZUJ-@RG M`X8*9Q@BUNX(WB%\6J8#/_[(GY.U>$X<^OK2XXC;=U[AF_:Y6:.2!L>G)ZAMKUZ\\I&HV-[7C)81+EF6GM+2JR(4)8^LC^>( M8^*=0-$7N+M")3.J2F6]YA/FH/"*7E*0S!X)OH$O922C'!-#.4L&=`V4R41D M@IOL1X@?/1`BRW>52KDAS!M9,U8G_?%H^(E$!E64>Q.>Q3.^4D-I"Z$GH:4X M;H<3K]=CBHB>490\!^.>>J[,1.63RIXU^#[QF5OR<"Z/!%?NI^R&V[<9O:T^ MD=XEX_,>!4WIVX)K2)L$T+R_TD10%)>WD7#II&.R-^NZO!TH;M;R&Y#26H@V M8H46H!Y#JCVR&)"^SI.UBZ:PBP0M1*%!08_U+U9P?45,8M!;(?0/NH(,;.F% MC[N@55#J/-/__+-HP:TJ-18$\>>?"+CR7"D?N9Y1O2?43K[X)=Y0B*]JIK>: M8]KO4O[+XPVB:!T/R\E+#71H7#QW?+ONEO?I%P>!KP,(Y;Y8?\4>R#L:,4K/ M<&,]Y`_\9*$>6`9[`GR&C1VA5CNQ_@G%OXS7C`\^OI5,>,;+Y[2FFE&P>,`F M,UWKL*;HL/K*^ZMS]:([_8"&6]PHG[=@X;G2RPSQ-8;U+FN%NKT\!8)0"HIG MS+;C\Y][!O2J";_5J2$15H,UJ!']I;@6RF!A&0;N#M*]57GL_*2O)M*57Y71 M3)+>W-)'QY2FMUIW<\YY@ZYFR@.\-,"C6FO.G0LN!97OTV"X$6AQ^8N':+D. M"N&#-*8F%DX9'<3#='#^\]4EQ!E^S)G\]+CW7;8:D&I5&IM7!#C4E12`")QV M9&`>K=V8F/64;^F4E#K6K#@--9^N(6STZA2>KPU-Y)(\5%L+G'N[+>'3&R[B M3I=`.?5=N6`H0U4U/E7(%UW3+9;'DBB$7%$T%GQ?O,Y#Y93XI0K\NN7OP`2N M>%OJQG4QF=)]RPL#;D'\J`7#!'K=J[2'"FI0SA5KR]KJ#,52*^%B;0T;N>+' MD7"B(83JA-F,3OECM`@+?6'9!G^SC5^@L@06F[W81!DJW:DBS?D_KI0K)6// MS[DNGV.0FC2_J;6M]Y*WN2NLDN[]-]3[:^EKS"7'@+.XC,PK)+Q> MLN'0(UM2V>;P(W_JM[[D!/MZY/NR=B`2?7Q&%UHL,V':CQWU4RI+D5;RRAHE M_]B*"I,6+9-1-3E#UA?7TKP>]14*_[<4O\L7/XD[*QK5SMVE'!FC<`H#DZ>L-0[9=Z.0[A7P^]`! MS0_MQ^1E$^`'-OPF3.9^(X>78BW63O=L"N#OY;MZ]'9:0[SW9P7\WF;NW3." M]'FBS*XFH^DUC-QPP=_/0C9G*XY>B!YEG]YP$WHJ#N-,+U.%Q&QDY=@SE^-Z MJ#JF2')3V93],N6V[X360"ZF2V3&RQ_\^A4-5$9C=(0TRT<5\1VT-'$E`RKX MI:)+0[!L;39<2-9S-KGSSGP*[>H:MTL:L[*F6$\>D6;2J(RO,3'<0]-$-M8@ MQT=48*\:VU7*(!0U7]")EBI="$D*EWM/%=8QJL$17&!>D5P8@3='RAT MU?A=@PWC2:0KX\.EMZH7>Z0MB)--VL!3Z3JTJ+CYPY?F#QVQ=TYO+8^8$[+` MH^""NW;NAT@/<2S525&G16^%:V>5_([X(72(?M-EBW<"=)6X@M86L37]+_+= MN=IF,ZUMQEQ+ZYO(2E$=XY!B&F+!4-#Y7^U]:UL;.=+H?L6_0F&&`(DQ=Y+` MD/R-2"1&5*R"_Y,JW,YQ'Y9\#)A1Z0!P,>_E^GO%?I[]:,J M/_A]C9ZLT]\;'Q4*T(H'FS!9\ABF'33GVDUS^Q@^?.9:MM5)J<*6M$OH09.- M68',K\^+H*4X&B+%7"A"S9^_IK14%.F34YE%U1FT"NI3MDLR-N#'5S@7"JAJ M98.R72=@Z#13SM+EA^;!HC3#JL-F6M1R(-9>QC7GTF@X&.#))2W&I8_4C]DZ MD.K_L!@A-GDO(8"V1#)VBE;_S"DB7\YMV*]`=&FB#O:/,&H3A[)WA.(>,I.G M^H'3X-T[=15>D48*[8-X#9J$T9_BE:1"#K-5))7/A==2^Z2H%^TY>GAT5M_[ MK:&JU7;=HPT'_OGA5[:051S;1O7TM\.=QM%Q[?".;605Q[2PLW]T6KLC<*HS M!N[^T='/Y\=W!,R5QO7X7?7P[9V[3)7&03ZI5<_N#)DJN88"U:X\*=Z9IPT\YMZ'8HPMP.[4]F[XM&G5`S>(07Q"-!YE*)]D&R*)\ MP-6\!+;(>^)L9=9A&E),\HB&2J"&.D8X5+=O(0G!XHA]HJ6%(4-4G&)9D?=+ MZ.7SYYDPH/$PK!A.6!7TC-G.?&14JP6E.[HTN M4*[UJDEC^12)D6H0QC&Y)MHPEB1.\K&2+N?QJ!E)+ML_<7JEGUO%.*4UME4` MY:P,Q/3=-M2)6(7+*Y"B4!5I#FYI4RWH:ED+S\X*\E51./NH_7?&T:T.O7+I MK-AK?!0=6L$18ZC1$87',R1TV.*D`,H&`EP\XTF*;Q=P'$D4Y`+E<>LBUC*: M10J7$-!I$SKFT9RGI"Z"MFVRWI%+[IBNR1E5HZ,OF"ZRE]Q>P>1%"Z_96LXJ MSL3\'&I?1#W52;)PM#$9`6(OZ[#2FB1;]W=T84&ORGM>O!0`4+"`-4+^#5:P MKZ]Z"?,@O,W%80=]H/E4<>$U!JLH#9P\:/#$Q%`H M,:B%N1<9TLQ*Z=7`4>5'=)$=A'1H/\7*#%RFR?T`N%\_5M,&\\]M]#K[*::(B)H]YD!OSQ=OD$[1.-5%S@!OT%.$\2D0PK;F7\^@$&].)NNGS\,1QQD8/+NT0 MJ&WD3K?4FO&KUAD)3^Q48<-W'`2*&,6W>%C(HP+XCZ:=6![&U6`W9=C6O'C* M\5+2?D61"L#[7F^;[H,X1`9!_@7%'%Q2/*[I%I%NH2,/V^RE#PO-+TZDD5*! M)AI7JC[N'CF+\(M;F<,A5"@2<-MO%YG/RBJ75:HCX_-@&-B!O`47>WR$#7.+ MP*.C&SZG-[H-@TS2)%.J/2?&4W>BFCS%C!!N[T8S'K$63_&M`+*G,G;%IO?L M=*U^>':2':WYJ4*Y%O!)E\G9O/VR:<7+O2W^[#G&_IH0N`(FC@R[W^G9W%QR M9*S'O#C_+&E#KW(@0*A@6:/B'$>R`9._$$!YC[4?2)#C!ABJ5.-3?3FC?.,+D)O;KX M)X7,&TXZH_+I>-*KV"YM&F)^R;/YUCXHMI:]T3-KW=OG/;[2JB^:4UC+P(AX MX*#O;4MZVI))0+4#A"I$_[((9?7:GHI5WU1\2#^DQW'4Q+3`_JD@C-G#D.T9 M0N&\/%'=P^[*I!?0@T`YEV`&2@Y&1Y27Y4T#JA@M.ED(,*A]E;(Y>K+M:]0] M:B6Y.`2%]JDLS**VT_ME$,2OZ!!2;9Y67H)^6)@>:M4 M,94^UZ7,H&F#T3&M$X&0]D$;A`Y0G0B$97JR`3DQIQ.!8S5Y4VE"TI&"5Z_I M::61D*G`F_9SK0]:SPT%U'ENEQ=N]*K1>WN"E=O!OEL`MK/IR70S9KN4*-M*7#S!YO<3%>2W M9BI:H_ZH_5%&[:)/;9:-Q!OWIO>`'D=>..S!C;T8)VQ#Z;F5>;\1TP%M25+C MM'.?=*Y&!SS?C,^@1T_%::.^=W`&VU!I2K$OS]',4_$O6;!XSRZ(3?B0#OV3 M+7<.]$03,TOK$:I:^&^93MHJ?,K&;UN5&=+/Z(ORXO5N]]C;LAZR>CKLMM37 M3I?327C'2N6\;Z":,72-TB?;PD&IM9B.[DTLW=?4+JJGQ2\ MVYEGPRK:U!X\O8>SI^UC8P%.Y[`WB>+VC7N7D^&0^6_G(-\D!BHVGJQ\=9/'AE$J*S2JEZH']5CP7 MZWYFB%C1HW+];*WY6Z4\;]?LW.]JAIY@"8;!#%F'3#CA$E*>-0I1M(03*5'$ MW&3@RR@3X@JK?UJ,Y98RX=F-GL`,GF).^25JU<"!\$5:=<+FM8H0QP-AB9Y1 M_!CK>`0RH6&88QC%FQ3?*>)+#YX`R.%+-=E>D&6]>WCN9*6H,%)7%.4\$YWK M1G884)BJ+GO;R[_U^_E+P!5J9=LX<5`OY*J3[_0JM!>K49BSVN3#K>@0,_44 MG;:6OK=(T?K/!2?G=^@=T+)1C)BQI.I_RB^;6OK2N[#ENH*$;4L8LKC31=DG MU_'`#U3Z"I@Q-U;"#==%N6>=VMNNRMB=4:VX7LQ/9<>IHN(6M@>#V=R63QSR MXEG,SB2SBA]HUR!;:IT`3$50'"U(40`H\P-!4P2A=0%-30K%VRAO_X^8GA:; M8CI15&2/QMAV'CG]]^7TBI,7I-)644RX\LL8 MKFQSW4+>?']9*1T&K$[&`N?^$[PP*$S221@R`^;7ZI@@$FGP:8(S7S.U('>@ M(7E>-M=F&0Q\;A1S11UH:_R48'VAM;H,@2TJ86:0TTF5*4R35&YKBJ8-[Q]Y M4HB]E[NBB6!]Q&$*0VJ.WADO[+/B:2/8M][/$N7JRW"VMZP_!1MW%N5 M8`O;<-P?_:#EA6T)0G^5U]7?I>NU M'O9F[0YC79MLK$&,U[3<9:RRRL,.N'V!/5J=K$?M"V]G5N^K,\G%P,;^R-Y` MZ69K9J@[1+?JW5=7Y"5ZV)V7=R"&ER8QC!II,^DB[/4LUR"9B_U>$@"8?^,/ M='!?$"_*T_)F/U^0K!]?G6]$UE>.AVMP`!G^YA`R!\+LXBPYZL^C43,%2&BT MQ\ZY8R.N*@_\`.;O*Q]5\(BT*)+WRFP?P,E21C"8'S'`;V>&,TT;-^*I6/J\ MW"X3E`D0I7I@C>MW=]J62?2CWJ'DIZ%-2I9X.:*)YW'L$HI[E^SZ_4T]7NYG M+-J'FWG_$&>2RW0&$S=B,\_%2GX27[2_#YU/M&ZA?]/-UN1K-GXH!L<77>)8 M7DS(_%M>2GIQ7QV*6W?8B>+@ZF&WHJN[].;*CYJ[=N8AZ6X-W8J[R1`'`:$I)6YT%QZ"0Z49+!JLXBYKWX5M?NN$ MLEDI3%/,MB?'+?4%.3*\HBWS@#9T@_IN;8EO(P.]8(IAX!8:X`XZE7F!F166 M?16:(RJL^"J$(RJL^BIT1E18\U7HCJBP[JOP:42%#5^%JQ$57O@J1",JO/15 M^/N("J]\%1)/A*8A%T\ MKJ3'E?2764FT0W'9O^!^5"C8/JZAQS7TEUE#7[L;%1L,F\T[F*RNFXE74]#K MN&O5(,\KP`:GT+.>FE:-;QU#O08OK4[*5M))^Q.FMZ>/FQ_KIMW M4`6A.P^KF`[26R]V\,2FVV^%GX6Z^V2$S2<['P%PRW@H,?A[G*3#ZYO/M_\( M+IHM]!3TE5W!LDO+*ZMKZQLO7KZBHNUIS=?]%IHFX*2):T]YQ#I&LC6F\BM* MKS<[F!6;8C:=U:6QB[_ST%`9P\P7T!'Y!`T\2^V/]X7=_XUND[3;_$04N+Q4 MB&35'.&%0^;$]+1IB;2'N"RS708PQM&SM/Q2NS53F@>Y*TZ-J45FF"G5D]:T MS36+3&?_FY#IC`/0J(5[LY^`:FH;*O-04M-A2[@I9QM8K;>5+!1OZ;&_6*+5<5.K*++525"HP2ZT6;/0J>VN. M2'`G!WS.M!8!H?`W8Q2^`$IGT&HG^<93QOI30OM3A?>G4$K1>($Q*%ULSK0N M9EH`%NCFU6$R>D!4%O/;AX)GGF6K.O=C9?OV M(ROP/G;9"Q>RO/&7Q?_64C;#M_I4GK?6?.FGW;%4L MGD,0;3'O#M]2^6W3B8!P$L9.*MXIIQJ]TP0/#/#CQ_/=9_U//X;Y^J6Z]M!+ M%4=]Z2[7T5-YW_-G:NC?MG*_WW'`O2S<<9/[``O7,]U_[N+]+I/_9TE'WV7U M-B?8;/\+5NT$;D-_\8F\LM5->17)Z&7)GDY_SMP:!IK,M]_J@LIR:7K,HWOS M870#L)IX.R8E-TPCT8K$33>]5->Q47>_S;/9SHQ#-'@5?`H;^CXL/;*RB3A] MB;0_5L67.O,J@(%(L-KC'Z-``)V8\:;,26]*E$9&-Z1]N?#0*^?8Y;5^6<[: M[BMWM,.^O/;+'-NXE`TSR:;@"`:N[L_<@G4M=W8+@TYLG,D%\OATNR%1RJV' M+2L+J3F2+8?^1@9*<`A$+D+"OFG'B6[8B^6MA?;-8SA-\56019R-3!(Z(J:M MV9`YZ(R"N6SH9AE.+X!IS*P[X1K^9&CJN0XOR@I:F=!\06V8PY;RS.QLH'=ZZC\VPYC5.1 MIZ:])-H2^J$F/*.817F2QM1K3633&+ML8Y=>ICK<25W%.UE*X@?).)P=32G&D;\T MC\/5,$Q-WK$1GUHV'2NZ4U-R%$NOS* M`<83-E%USI'JU.=,K),U3Q=9N>U3X.1D]2DMLUN?$GWGZ]MI'//DJM(X6OD; M,U+)TRTS!3-MH^^V;F3.2KJ;`PU\>Z8UCY'>S'EF(C'L@O0WTQ(=_M?,AI=E MEE;7?)A/Y^4Q-I9&+CW/=?AH\*52#.Z[OB.N@-5;`MO^/]A[^[FPZ^,6JY MYXKS;3/S M*@>&]&R08S6CM@4W+>B*G<$-S+8NYKO%-L\=AY*8,=6;I5OHQKXJ]:3L]QQW M#Z3B&\K75S#I:F;-.>_H.>]\RYR__:HY?UL\YYP.[UDG'OQI*I]]YDWJ[G98CE3[.@)5[8= M;"*-ACWU4MZR*EX:4ZEXM9H[$.U>C9@UO+R&[Y:2>+K'F0&])UUF889,Z+AJ1[<6N?K6NN,:J]&:P;]!NP%\@X>:&BW?B*>M09E M:SMH=6-:,N[%.E`;;Q3HQC`)47PK4K2`T@7.Z*2)*>F50469AJ!;O3!H"[P! M+)$"8VL@TS1I.,14PEB]Y]:Y$#'GJ,V&3E5AX@,1^\H!XP6"@AWV69],*@4_),ZWIRHB;;.R"%>,&&_/R M%+6V90J]F82/7B5BX8N&HDY4Y"4,7,&]>V'`QZ\IV0$`2B MVRE2J'O-@GG8[B5K7`@T1;2!E(7<1^3AM<84M',57B5A*J_+*HLEV_B*Z.GK M6\D*392JF!3WG=[JMW@`"Z\I2LT:4PRTHMOB*#,H5C\<58RO%+<3]ZMW'?== MA]XE,B&C;=I"W(CGVL)E[O/D[:"`*@^6;;\Q;&OT!62%MX&YBTF*_-A/[RAV7:U6;)*HC++D,KRGCHZC`#F`_P*ORL>TP6!/T@HQ1P\ M41<]R@9-99?(*>CRR2:Q*=F`K"*[D^=F\,(N:BC,P.21=29#VH3*%)?#HJN; MK[YYZ6256R[3/RO&8]F%1C,:W'Y-]CAS`E3R.$5*)NRR:DE..O:&#N.R(ELF M.\5A.O=[89T5IC#RP"$0SS$'(SG?&%88;5AN7D)Y.>2I9[*^C$;LBW\@)'OH-7TZ$Z9Q_OAZ+9@0-_M#N*;,E!L8O-O,Q, MM%\@R%D,SV2'?N\-SR7PIC#GD^3DS1I<2\A:,`.#*$FZ%_JRC4P,LTJZ[*JJ M!#C*J8F'S@PPQ\%PY7J$--<9Q70[H3-T\]3?/.^G4WUUX]Z4J?SH_+N"W9%L MW3")#&T0_B-(ZAIVN?U#/VQ^4Z#84G7E%B"RVS:X=?-^C9P!63D0F!1C0)>W M343Z5F:-!D9/YF.@'EGC*U3';'PC??WM\?/?\F&E9)'_J;Q\D#:6EY8VUM;$ MWX``7ZPLX[\K\(1^PV=E>7UM`]XLO=A8V5A97UH68GEU=67M;V+I07KC?(9X MS[00?XL[4=2\+"Z'OGQ#X&G?HT_?\5.!#7,'9(*XB\;CN9UYL?SJU!"S M#[I`'_8,$,('^"2YA/WG@@%A%7*;/)6]$'N8,IB<);=$V(7WL;@.8[H];44U M(B&61103E#G0>*'SL8@&Y/<+/;X5O2#-ZE8*<9`-58O]E\#W^5)I&*?R8AHF M87O8*Q,,*"W>U\_>'9V?B>KA;^)]]>2D>GCVVQ8Y)*/C$AI-"%;W:M#K`F@8 M6QSTTUL8`H$XJ)V@R\99]4U]OW[V&XQ$[-7/#FNGIV(/=,6J.*Z>G-5WSO>K M)^+X_.3X"!0&D'K8P90@C,!TFV8K1HWXV>1H`1T$3TY7Z<&.K?H[MDH+8N;N`ND(V4(:WZI?C;'95'O-RME ML?%B71P$(-Q7KV%:=X*KB[C;ZL#7@ZI86EE>?546YZ?5;!P6?<.&?XM3!&)? MDVE+A%O,P=_D^0]MN59M*-HTHPE(00HI24PA"#5BM&S:*;;-(K9_V` M@KD8B>K9X5Y9'%?$446\B3Z+%QL@*@X&?')9.:V\AV&L+*^`@E,%S@28ZP:Z MOU.*2T]-69"GEM<7JLE`K<1/BPX)EC_);2W]+17]X MI7_MDF>=_MGNP%<$OEL[W3FI'Z,G;`GGX4.[SFU\:!]G5S'A\@SD(,J8'Q]G MEO5RPL%%%(',V8R[@S0I@28*E(#L"^I?=_G>0#((]'K=#COY`0K"*_P*9-[* M;E-%"P$O_1(C0V3(H+O(VLE\1=138AJ"+)6('^2ONAM`4>6]'TEN]%59P.0!,+HWE ME+T$.?6']IO%81(O)G%SL8=$L[@;-8>(25K$BXS+I))^3J$O%>:Q%R%PF"YR M95B>)79%PZ&WAR#:(OSK+E]W2..T!D,\EWPJ:;8'8;,+U&PZ3^'@*UD%`!N4 MR-P%':;'91@*(+.OKD6G@9)>B-,$@G0,$W8-4#4IE!0IS!%/@S^XL3%KY,[# MML`N_4`->WA93H`41^]*^EW9F1<@2'2`1>J[5:ZQ%;::,\W@8$M]C!#H]6Z) MRF&BPUY;[4870?,3NJ%`G['?20A_70&W`EI.B`CID("QJ/R$#=*39PC*)H=+ M:IA&&([0I`9;82^XA5$"[KH]G`9U2D)X321AM20UIDSSPT%9T2U[@DJG$CDD M]IO+3RE:"$LI^9#HJ<).Z=,'*J6/()+;/A1&=1D(4)EH`5A)'DFTU1SH@XD* M<9"%5X"=0.RAO+![B:JCY*:NTDIO1U(G-%) MTG1N%A6=&,9J2VY)NZ8<.Y$?C:Z4\6*Z81YM_&9' M6Z43H%=KHBU_\(HX)X]E"FR"A[0#.5TJZ2ZAK$3\V>B-1'_0`_68<)!XD5"2 M2``VW5!I;Y$>"J!"`@J![Y-<+NAK0+]4030]:4JJT]#CHLB/KX8IDVEP^)K72;DB;8(.KND4>[& M@4B(:$3U=*=>9X@DED9]MS6YF(!-XY8($':B*Y(%\!>0RS"1O(T!!,A4R&=W M]H=9LK\![PYC7:W$U7")7?2"_B<)!G?.;@>X.3*.&NT/OEY@UTN?PMN;*,;5 MT>M%-TSS_PCC2"CI'3;^X"K$2T[PH(_.P9"OLZ3"D)@',02R>,I#=2GX>Z+1 MN!XLE#[-3I=*H&XWANV?&%NA'RT ME=%`8-ZP/*V87Y37`-U+1'`G]^J9[4JV_V:Z+V MZW'U\!3)Z0)[/Z_)DEE^=;]A=1:$I^`B0HTB_-P,!ZE4ZGBQ47];$4P:J"QL M+%E[UT]YM24VE:F9GOU8]:3!AEW:`0J1@,8SI$-I"2+8CFQ?'T<$[ M,C-6*6GXO"EIZ8![*;6TB[!$\3,H6JK-JR7/Y"6%(>69&UM?!K4`;99D&!I; M?F$[#3ZSDL/#H<@9H2)XJQ29)GX/XDY2J50^EGA#A,FAP/%J^/B2JQEO M[5N9$$K?J!4U`5M2`I(E<:OKP[;*`[W)F!VY7L&Z!XX%,C%#M]P(,AD>L-=N M`\4`B7P.+HZG%(+0'#^(Q*;&DWXPZ_2YT$PCC1(M-TF>+\-8> MH@B"I\ONN:>4G;,Z6*#D3E16$J:#Y)`LW(TZ,@@R(+B3R=EJ^:<:-IRH"8J[ MJC'LMJ@"NNB+^JZJ(R=1D!Z(0&7QCBS.CNJCRI_4]"+.4"BESQSJ&+B24TMG M;J]OZ!1:A2DADPQ4@5;G=88,;3I!BH\39?@B*92M2_;Y6`F*@F; M#\\QJ99,:H"?E8 M@!VOJ#ZQ?L652GH/0+T?N(+D3R2K7.BE@:@4TTC[%0(R3?#8=EJBY]-(TM/R M)1H`0#PB@PB9S;3'/!0"(1=S]$%#>ELJZ3[1\D+O6.KJ!1//;7;($(;@QJI.4XD(Q" M]0=I60]7>GU`)_NX@VH9+U&6387:^.8S_P&5[SU26TEVJ#H]W]H^HNZY5RVV6]$HVN[!GYHW+`%7-TDR8_G8:5 M$K:[G_6V5))+E(]C9?=@#)MT[2%M1@LL60PXQ%0FV3Q:/BY"% MW+#=[C:[I"6ALM.4U[@"40!,6*07X=S+>59Y>%+0&B5S`^!C)>&<)USMC1RJ M(9#@`$#Y"M%NDEY&.)`274//OK&4%$`5&-%Y2Q@M.C;0R?&CZZ!,XB6.M<'H1AKVHAE M5B#+D@+*E7("AVZ35_M89)?RR';PDMU5K7"][N*ZE,>U&(EKG8!!V5K2B-P3 M633%`SK5*`KM)9):X0G'E`#,9EEZACSCJV?'7MA:X@M;E9>=D61$W9B]I;6^ MMX=')S5K01N(<"R39C;^RFT;&'3_,NW3S])U/ M+Z[RU!`#8:.R>!,-8]00+S'CPO48Q:.$!:)A(C)51RIK4LF%/4MH74 M"2OA1P4SI:2/*+JP!MV&'.9)Q7&6E9\0D9 M+)'J_JE]=,&2NBAS+*`$P>14^[5Z<+Q?HR,_Y63;;U$*KSBZ+21W MD-.DXMAOERIH71$5D`MWWI>4%B/DI_*,_S590*;KV&7,]9:'#M.W5:U'.6U9+?9">-S[C92)JXZC(W!V*_!*V)3)+H2E*N(=/J&SU_.S=T4G)/MJ?\YW?R_*_5.O[TG^" M2#Q_>*L,U,!4KH-NC_@$,I7-TF6:#C87%V]N;BH6Z,5_<8/RG/,O[%`G_;\, MDU3SWML8X_^UOK&Z+,3&BQ5X^>+%,OI_K:VNO'CT__H>G\5G^[!Q[-??G%1/ M?GNV2'[!)C&PZRV)&7C"KP[Z$I`'4!PX17%@H=?]%!JU,JF@PM5S#F8O%N"O M5ZZ#6=94KWL1!VBBNZ-WF8JQ1SOX:.^R?=F"[9]$]0L\S2;R,B,`HSS-)O(R M\R+BKBYF".,;7]"(&PL)S3!@X=>I]C&>"Y'>5[R+\?K5PM'.&'.$%ES\?M)2%U5M^;6&W MMD/E-T6UU2(-@@].VL0"IDDWD&K!M*6#3-;`\HN%T]HQMO!R4YQ%T2>TC9$$ M#Q1'AB@*J"AA#JMF+V`YB"3TG^+7H)TW/P6=4+:U'X"./,P:=-MZN?!_SP^) M'6Z*'38_8PZ5!O:Z03AMO4:-2NA!JK0"6F@X6HG6LK0(P"3"7/\@# M+(3=ZD:5R]?&HR;:"^Q',G.+\ZP%:\9^-NP#6VK9SRBFQWXTN''*$(WSHS8H M6:+1^+EZE$GHAW['<7M`MVF/')X9NL]C\[9XCQVD/LGIX`TCFPW6W3D<:O%9 M[=?CVDG]H`;[5)8>%5Y1P*B]FM24L'=-P904X%VX(S-Q4C1"R@_C#$R#*YH- M)T"KQET/^B;''9*"E1/$AOV_#R/D-C&;I;&9GWBT,@QOL7C^I;KV6E4UT MO@;9(C/ZDN>I(>*0]1.*NUP0%5&"15L\!T`E,B>48P-BQZH@I@T8]K4431A: MC^W*6IS0@1P+BJOKL;TD=:W3BRZ"G@RD(S"O/C'ALWQY5[*X5SU/)OK(D5Q:' M[%_G'P[2V,K%D&7[H\1ONA-,9K\K!O\1)O1J\#7QRS8_F#:R!=$D9+EKY$^) MSRS&C]>#>*TWFWG).*"L>F3D*][B+!WB^7-:$5E>")G^E".6Y3LC`>KLC[.; M*JNE\/@_$?.3%PS@2ML6S@XDYM2^H_C:4[6[J,ZH[%7PL?B[8);$S&@K"\F5 M+;G9?728,&D==HK0V7^9PWB'XE/FV^H9#*&#VOD=+QO430,]DX<'(HPS_F') M;8X$-WY^P+MJC3S7T.IY$L:S"9Z3@\YDMK^)#GK7>/R+;G+PA&:,XBLI013V M286BHZ2PG0D-<]/OC@YJTW8DYQ1.GYW/E%!(:"8L\(>(%)V*!??`?XEO'$P+L,&O6B'$_KZ7BA$.EYA'L7I,2/0CDT7>;>$9Y5 M*>2F\-.YV5FQ%A[3LKD>,2NJFQ05AV6OB)%##*U$:0P.Y\9-DYH?+7'_L4.V MUP'!IR2I0!+SSM3X%\7(WH]8$U\W,_G%8'796A8DE[@KP\=^82XW\_F6<=A_ MWH#E7BX[\/SY1S/W!%U,D/'RK$\*34IT5[N;!&.U*A,J6(U*Q'SQY%]0G?2G M3+05"-(Y"I1$4RWQ)%;,;=#CU4.]0?O51+^JPC4FU\*DCC+EZB@,YXY*BM[2 MI&C+HV.=0)..MK9Y=`PI3(W0,N3H7YMGRJH@/.^FF;J!4C";7VP-)9>E@CE= MYGEE9R%#['V]2D+BND%PWZ22D#HBE9Q[4DEH=%^CBHQ+_8%Q9I'L?S*\,%3- M<=E`+,5CA+Z!*>XN,"XE\>H;94/!H(=?J30T;":@E[!2'PRI=>ECIBI(/O;C MK);Z24I1P8B!-'Y/__CC]*8XKN^RB*(SM@G:JZ?I=C7.&(];+2;J)MN((^?) M'3';T9[Y.+Q[/\2$##XO;)C\4^8ID1G4[,TLXU4T&F,/>Y;;P!0\UH;,Q">( MMZ.XU>TC#><=4,HJ60TY=C-!6#=_2.GM#VCIJJ-+P:1+2@[V6V/$)A7B#,"X.6;F2G#2:( MV(VROKC$$`M'#L1EEMG;*V@Z#`R9@!?F5;;H`\N$N9=1AL,+-;%*\B`+1)NP$ MO4PDVA2S,\U9I"G+7TXM2O=FOLN1B:SD2#"=_1.^K>$A.\,MC>P0$F8]G961 M4@NE;2L2'=(1/1^VNV+V35]LB'.?G4'6!QC.M!'9^X$=XF2ED+@;'3:4(_ M3%+K)"+C3'35Z+;0"2RY&2UD$9R5SY_ M;DF77NWZBRJ\L#"^L%+%"SB3A:-LTP/T.K80W_ZG-@(OO^(YR:Y&O>.^.6J.5])R>.(> M4A-$2T_-2P5"G=Q[>^C3#4W<^6EV%`KO1+)C<39>/\32.;HUEX(B7:_5SI6V MON&R$[:$W=F<1FS:8U(SKTZQ36AOP]2PGWE#%]`#3QIJLJ/R,Y-YX0S'@$::K.Q[HG0(J,6>Q]F.[$GI#NQ+ZYL=%FHGD4GOQ?A._K_2_UNZ8SU,&Z/]OY=? MK&U(_^^U]=6U]17,_[FRNO'H__T]/HO/B%Y_D?%:I,1TU5%&+'XFNA`U3$A! M:3%T\%*KR+=[Y=&W^]&W^]&W^Z_NVPV"Q\+7?X!K/!.:DAWWT%GJZ0(-6)&75R_6_J9/K2DET-^>4\#WM4$@6R3 MK"43?.YQ&6"3AF,]]6".M9SY)>U7?S^#/:X;X_4O@(<=[''=&"KT9K6RO+:\ M_FIE8WUU_>6K%Z]`>'VYMN'2^'&]<7386!%S4..96*JLSV<+YOU1`Y[RFY7* MTKQ1Z>AP^>42O5H4\,U\"=7@,5>^'^12:J2(>OQ>,G1I;'1M0)B3(>\28?3/HROIZMAG)0)BEE37][$`]6WNY_F(C`W)< MW:EI&,O9=%3?O*_OPK.7&4U6W^J2&_?#LX^(Y/C$A26&[[BJY;"2FV`P%Y0O MRBF(#G^@@2[8`EET6UQLB0OX)]WZ.@/*AEGDI`8M MT:6"9D,OS"+O3^IGM5R9E]:@:P=Y(.*5641?7FBC+H?>W>I9U9Z!90N_QR=' M;P%KC3?G;\TR*RX<0L_9;\>UK(R%X9VCP[.3H_W&CMV6A>+JFZ.3,^%^EBT< MGQ_^?'CT_A!F`<1<77C90C*GO\*$,N:$+;^PX>S6]G(8`D:U>E]2PGN5=O!3 M>$MGBKF1^3[WN,:.J^<@T[:B/\@*V?U]9>GC5B=,D[GN_-87NO!N#O;R>U/# M0)MDUDF#YHL220#^3L/=VZ^^;?Q2.ZGO_39W$46PX_(I'WY'@RFYXY(7O7K" M'K=B7GPH%??PC_Q5['@0\29H\1")7VZ*&3JZ^:`=5IVC4>K0EO@@`Q7R,*L7 M48P>Z)69)AUFO*GM0WE=(<#78DX]RKIW/UN"D!)\R*HS9Z&6.\'W(E<8L<$( MWYP:+._=F<'<]O=,-O;+F/&9+@+,9\OU]"849\%V#\_>#/!4>7XD^?1W*O)0$JX5QZ3$: MB+LR,3Y:>\+/:5E<1C?AM?*2KBI$8,H?2MP&Z('IO@@IZYLX'?:/3A'P11Q] M"ON;4@:*>7Y6Y_7"Y=,:/FS627WD,`L71^,4'[T]!+\R)]]NF$F`P_R;@]XPP?]M_-@5YD2<8J[5 MN)/`!B0G>GIG6OR!+^CY%C!W$X(\4L24A_9,<4"'U84&Y&\B8H.&G5P+XVG8J3""AJ63@T/*$Y/LR(8"#4ILAYAT,>VEW(;V,Y:T@DQD[OEW,D[;X;'MC:N/,*">U&FB' MU<,SVG2?P$>P9H;?GCU[9I2@_5@YNIH"Q0H6?)9#6]9N_:3^Z[K9ZNG;>N/@ MN'%Z='ZR4RMLV2J5:QV!^AO^QOE"P9@`L:>&/-7Y3[P;U[[_%1,[WG\;H_T_ MQ/+ZVBK>_[JVL;*TLKJ^@8:)I?7'^U^_R^<'<1I0#$;A%4I&DD]89D[ZJI]\ MB35?3TVM+NS5WO"%E#]`K5J?W=GP`A`[I2K=SH%K.>KIB]PH!V^%/`3P*+TI MKUA*T7(*P/`<&%8F>HN`%$@EO[4CVY`(V,GC=D8 M8;4B8,-/=.K6J?P\?AX_CY_'S^/G :\?/X>?P\?AX_CY_'SW_IY_\#,;)"K@!H`0`` ` end From owner-devfs@oss.sgi.com Sun Apr 16 13:34:47 2000 Received: by oss.sgi.com id ; Sun, 16 Apr 2000 13:34:37 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:50309 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Sun, 16 Apr 2000 13:34:22 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e3GKY9o03245; Sun, 16 Apr 2000 14:34:09 -0600 Date: Sun, 16 Apr 2000 14:34:09 -0600 Message-Id: <200004162034.e3GKY9o03245@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Johannes Erdfelt Cc: devfs@oss.sgi.com Subject: Re: New devfsd to play with In-Reply-To: <200004160710.e3G7AaE30537@vindaloo.ras.ucalgary.ca> References: <200004160710.e3G7AaE30537@vindaloo.ras.ucalgary.ca> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Richard Gooch writes: > Hi, Johannes. I've just completed my first cut of the new, generic, > shared object facility for devfsd. Take a look at the new "FUNCTION" > action. This will allow you to run an arbitrary function in a shared > object. > > I'm hoping that this will provide most (all?) of the functionality you > need from devfsd. Comments welcome. I've implemented an even nicer version. I now have "MFUNCTION" (this is the previous "FUNCTION") and "CFUNCTION" actions. The "CFUNCTION" action is designed to be more friendly for calling C library or system calls (such as symlink(2) and unlink(2)). Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca begin 644 devfsd.tar.gz M'XL(`(0C^C@``^P[:7/;QI+Y*OZ*#I.7D`IO7;9IJT*3D,)$(K4D%<=EJU`0 M,"`1@0`>#ATO\?[V[9X97`0ID;N;[(=]K+(,S/3T]#W=,P.#W9N!T?SJK_S! M8>ODZ`B^`H"33IO^[[1:Q_Q=_EK8TSHY/NRTC@[;`.WV\<'!5W#TEU(E?U$0 M:C[`5_[<=?7%9CC=77I1R/R_@Z:_\6<(_5]J=\RT;/:7S-%&;1\>;M1_N]4^ MD?IO'Q^='&++P6&K\Q6T_A)J5G[_S_4_?3\<#883>,=5T0QN+:?4'X_.AN?J MV?!"P?8F"_6F,).&[CIFJ:39]IL]T5(JE<;O?U;ZLRE"2B`7V*/GLR"P7*?A MEDJ6:3`3?E$F(^5"Q;E*_;.+WCD-J(\[4!\V\-^WE;2_VK0`',,"^D4]+S9^[8B::R6]G1=#',EM9!V$@:.N@IU MV["1<`=M`WF5H*4]?PEU$\&DT*K-N$-"0CU(T1:`=`_J7BRD5]",`K^YU!SZ M]PI1F/`)OH8Z(S)2!53AI@OA@CF0&TZ*6`'L@FF52KK--.=-::\N:-W_3]A' MA>`_WYJCL@PK"`4(\/\20$GD_[4Y_OOW-_]D_(_-ZB^9X]GXWSYJ'1TJPVQ*B^ZSUAB%F$4.E7H?WZ]:LZ*AGSNHFE+S3?@',2KX"=+:P`/-^=^]H2 M\-'T&8/`-<,'S6==>'(CT#4'?$;1RK=N4>Q@A:`Y1A.G7;H8W)\X(FR,'(/Y M%"`!=;,,P#7YR_GH&LZ9PWS-AJOHUK9T)%=G3L!`P[FI)5@P`VX%(AIR1E1, M)15PYB)F+<0EK`O,PGX?[IE/2QITXDDDQAJX/L=2T4(BW@?7HX%5I/@);"U, MQS;6"R#ETP`4/N%>N!ZRM$",R.2#A6O++8,H8&9DUS@.A(8/P]E/X^L9]$8? MX4-O,NF-9A^["!TN7.QE]TS@LI:>;2%J9,S7G/`)Z1>:5B;]GW!,[_WP8CC[ MB&S`V7`V4J93.!M/H`=7OGVJW!T-$;-3@^.4++#P+HW:-"^]KRUK>,.3Y>]J#5 M:1^\KL'UM">9R-DT++4G4H[/-%V8%+`E<@RH.Q!1Y4R!M`,@[(E-(0W)9$1Y_#70&^ZT)N-SFIPU8!Q`]Z[CW!R7`/%\RQG7H-1 M8]KX@#QTVIUV#7H8T5!LEM8H[3=+I>9^P>263%@42@H]">EWM#G7J7!V[OS! M4Q"R)?++1W]`<89H3L%_+6'TA6R6`O?;N\ZH%6?*E=\ MP!OH&0:"!I'GN7[(#4T+GAQ]X;N.&P6(#WW'H7"!.8Z+IDB.$,8&N`5IZ4QG MUB.!1G-RR[>H84.ES,N:GR*N!PP*#-Z^M2V'G9ZB-BV'7/U!HR309R;^]H2U9.\:,($1NR@NKIK(^GW M5B;NOCC%86:*:4C!UW&Q#J'T'G5/P2D*D(T27Q91%H#,^4_8CQI>\G@"E8>% ME08%BL,XBJ:M;DO$48%/]&>=C`>Q80[20&?6G#LR=)3]E<4PTKWW7??M3MAJXM&YK>B.Y.MYW]N#"[IG/&,*I$>ACY;%M,)T436V#$$S9&WEE> M.J'GA&5$%YM4T)"@#@M"SK()<37(PU+<7^Y?*+V)*@J@,MRQIVW)>E4D:WPU M&XY'O0MU..I?7`\4B2^V56OND`,+.204\*B">@[NMIRYD[,N;OJD6Q<"YFD^ M'\IQ(C*2CA2[B#TY!%F&(6B-B6N%@336=3+I^M6P+TZ18X8DAY+O)]RT6\`4HH(2BAH&'KP$UN+<,YA[:E"%C*VK7 MMID-%*"E=DV?8N=M9.(R`89OW>^@U.,,W9B]^(QB+`XHA#T1(8X:H#R2(LA: M?Z?5$N=?8F3SP8F6MS@_+6Z&JP8H;Q4[U8#Y%-U.I:DCFLV<3XGS][86T-K7 M']0GX\L:>F^(O-_58-J?#H7&4$W".'A3J&%ZNQO;!ZV"NK)T.< M\RF>?5B@UVB^CO\E#KR9)]MU/4P,!PH)D"@E3)QNP>"NE+=?,#0Y-R*CV4W; M];RG&DQZEX/AM%^#)6;0=;'@2(EBP:!S`OD3)X]>5JF#C7)"6^4/:*;-A9%* MBMYU(R>M+7FLC\:_2A;[F"@1[-NE=L?4X&E)MG`*?&&DO(ER3YW#`'<73"XL M>C$LK`9"EY.*293/_AEAB]%()L]+3<>E68J,F"=%I<%YE6-B;!DFC&V[6AQF MV'K!:F@5L_PPPHP>8W;@8KS6-8\6S!I&>%S>;)&2RCZASVW%>[03'>^G`_"P M=;:*1)$7%H,=L(R*HR"=+V"W^&)Q03=6+,OXN\`##E*L>I2%DN MUJ*!2C<]M,M)"GHY'ER,>X.RI&KK2'FFO.>;8V_@?9PTH5=H#NU>H'?@,G[+ M*J^JB`UK]B@@#R*K*2N_*?WKF;+S?)>]23Q?1()Z%/AX7BW3!&'PN&QL[S0I MUMC*'3;7"`=<#P> M]:FR2#2V/I\2$UQ@"@51.LL6$SSG_GV^7^TZ#"XC.[2X@N0RE$8`VB'Z)JZO MWD:.%81&8W&::<,&RRTTV=;M:IM/Y7VN3<=2@^6;O(<5]'/?6T'T%#2IG"^V M!EB/KX%]HE6_T/R@66N`+1<5FF\FPW=60$W=607CF;PX)5'-8%W?'7:JX;H> MGG07B$%K6VG#,E-;F=9G<_:8;V*^[ZPHQ+"1XGS3G>8O-6K"-M.A\U=,D8[5 MR][/XPG('VW]#S%^:@%&VC"=\1"!4#F0GL?5-P5,+YZ ME>\\R76^SG>^RG:^;N4[7^?7@.@6[[/VF]B;G4Z@SA&`\P\]%,6BIUR@9X6D.[0!BP?&;: M&"42"88C,5>_N'/% MT>`*L!&%."&'K]^]-`O*R_A#K)0_4U0AUFHX?EH M/%DS(2HC.^,OXXM!?WQYU9OEH8[S4"/EPSJHDRS4Y'(#KE=YJ`VX7J?"O_RE MQQFL/"RTL$:)5A4J8BM.+BHJA<`J_,$!>"KV)1T^_3B]&)]7^/9+#<0N98WV M98-&HU&%SWSE^0.MKB)"DFH%*NW.5..]F=6AWWQ#@ZM=.13H1@:8?-^#D(1H M0GX6&@0XDE225'M8\%G\4MYY+]`4[)#-6]_9V"PW[@2@X&ZPMV]!-H+)F%+^DO47U)Q+*2COJ9LE>PQ?L.^PQS'$_9Z$: M[WVK=(P0&S&2%\:HQ!JFBN.Z!!=!BQEQU9O.I(KE(4Y&Z_)LYM-T-AF.SM4+ M970^^^DF1T7.?B4%6:0I1F%H_#B'=9]Q@911OMPIC[B<8G:3R"W@UJ3\-L,U M34V">,6TM3EB5.D"F;* M?E;>Z&?9SKB9ANW12$@9)EE7!;ZTH08\S]C'B&=Z5:C&S%[YUCTMKGE>*7VU M=#$<:^3(4^51H!KOH%000Q8J<]R8IY3**%()QEF2E[AMH-F<\%0V_(A\GY?I M*A7@*]AIOY=O\U)^PV.2:=161F\<+#>(51X?*EL:ZPH.Z=<9?]P:DU!1#GBM MN_&W]=/B.F.[FK';E`7/W'56&5K^YEES\6M'(?]/I^85ZL[\YAQ& M$N-_P\O$4JV1R]70\ M#SS9[?T\TZYMT)I3@VPC%DW4F")9OW00Q_FFRNI:5`BU6,QHV2C[G+6:EH\K MC#2==S"ZOKA8I6CM.#KB>G[8"B-BHL!=A<[*A)]MJOSJR"H8%['CQLI[!V>] MBZF2[\XG[048/@??=5=Y&H\`K3P"[B=J4BBN(I",Q2N5U'4^38OSCB#,IIHB M9?BR.C3X=`/OY,`_RDV<6&\&S#:;IE&N01G_?JG)3M-HMJB-=J"<7'-;-F,Z MD&OOR'9+'^I:S*5.7Y'/Y\<)' MC>OK1'Q)OY"OV`M?TXN!2MRG?`>SR;7LBM=BKA759_?D1F@F:[)IL2$E)J%E M>@5D91$7ZL\F;=9`N=:IRZ%\K)\C7-].9S M^(_@LX-*YA-3Q<0>+0P/[7S1X_H4C"+N49VND!WBIVFZ\,,/_#V9BY>^H:\O M/4[(_2?>?8-SUN_+57B'(JL6M"QTM<=KWV<0&#&"TA[.1!,6W$UBHKZLJ\OF M+YDY-LX2)F1^]UW,.)9VDF/,2P7Z?!C00M>2F*1$;JK=;68;Y&:38[-S)9SF M+1/G1(PA,IW'*/RS5>UF!13[RQHQ;"#+G"=T99U*.AP?GI"VO7GQ#8[$Q/:^ M9*R,:,F*])2F+JI0[&QD8SPG'`OO!(N^P-45*AFH*NWQM9YQ!X5O[R6[D]G3 MRC?PN8QLE&-FJ&;)H*Z!,IF(2G"3_PCU8P1"8OFJ4BDWA'NC:,;J9#`>77PD ME4$5]=Z"%^F,;_M0V4+D26PIC=O1Q#?OL43$R"CV/X?COGJNS,0V*.V!UN"[ M)&9N*<.Y/*TL7)W9C;:O,W9;?::\2^#S$05=Z>N5T)`V":3Y>*6)I"C>ZT;& M99".V=YLZ_+BHKCTRR]G2F\AWD@46H!V#*GUR,V`]#NCK%^TA%\D9"$)#4IZ MK'^QE="W2DF,>BN"_D&WHX$MO?!I%[)6C#HO]#__7/7@=I4:5Q3QYY^(N/+2 MOCY*/6-ZSYB=_"9-?#P1WR)-+US'O-^G\I=G'<31.AF6D^\MZ#Q[]5SR[;H+ MZ*>?'42^#B&4!V+^@C]0=#1BDEZ0QGK,O_!CAGI@&>P9]!DQ=H59[23Z9PS_ M*IXS/@7Y6@KAA2B?LYIJQL!B@$UNNC9@33%@#93WU^?J96_Z"SKNZD+YL@>+ MR)7>LXAO6*P/607N]O(<"$8I*9XQVXX/@QX8T%N-TM..<=NIK9'N!;`SRK MM>8\N.!44/DN388;@19O?_$4+==!*7R0YM0DPBFC(WR8#L]_NKZ"N,*/)9,? M'O>^R^X&I%:5YN85@0YM)44@$J<=!9@G:S M&JA!-5=L+6MW9RB7*J2+M35BY(8?9\*)A1"I$V8S.O*/R2(J](5E&_RC.WZW MRQ)4;(YB$^5"Z4T5Z<[_<:U<*QE_?BET^9R"U*7Y);)MHY>\:%[A\L6D*JDY M^#V&UALQAI^Q';16;-K1\T/"_H$H$)U1:+/_"8^Z2AGG7NK MNZ1[_PWS_E+Z$DO),>`LWD;F.R1\OV3#H4=V2V6;PX_\J=_Z+2?8UR/?EWL' MHM#'=PRAJ]M,6/9C1_V4MJ7(*OG.&A7_V(H&DVY:)E`U.4+N+Z[E>3WI!0[_ MMP]NN(`_3:\O+WN3CS?HP)HAO)9/$?GBPR-Q`9($\S:>YY1_9AB_B0LL&NV= MNTL)&9-P"D.3EZPUCMEWHY"N#_"KV@&-#^VGY#L8X`9. MUVQ*X!_D9X3TX5Q#?))H!?Q*:>ZS.,+T::+,KB>CZ0V,W'#!/QU#,6=W'+T0 M(\H^?7PG[%09A<2JY'"L6>NQO70=$Q1Y*:Z*?MEJFW?":N!7$Z7Z(QO M?_"[6`2HC,88"&F4CR;B.^AIXN8%5/"/BB$-T;*UU?!*L9[SR9U7YE/H5->$ M7;*8PIQB/GE$FBFC,K'&Q'0/71/%6(.<'-&`O6KL5ZF`4-5\0B=:JG3O(]FX MW'MN8QVS&H3@"O.2VPDW!<4)"+H_L-)5XW<--L"32@OPX=(KVL4>60O29),U M\%*Z#FW:W/S^<^O[KE@[IW>61\()6>!1B1V&E[MM4TD69(D`1!$``!$+$" MJVT8>M[_X+YV;)NKB6U38RVQ;P(JV3I&D/08],2@T(G"A;0&)#)'2G;.GUE] M+H?8+RI>)NQOU`/X^/<:_;U.?V]\T.5[OV_2DRWZ>_N#1@%:\6`3)DL>PW3C M^=)VT\P^A@^7TI9M?5*JL25V"3-HLC%KD-GU>1DT-$=#I-@+1>GY\]<42T6> M/CF36%13@];QAMIV2<8&_/@*9Z(4=:UD4*[K!`R=9BJU=/FA?;`H9EA]V$R+ M6@;B[&5<38 M^0+V*Q!=ZJB#_3.,FL2AW!TAOX?,Y*E^D&IP^DYUP@YII-`^B->@25C]R5]) M.AHR646B?"Z_%.V3`G*,&^G1\7GUX+>:KE;93Q]MI.!?''UE"TG%L6V4SWX[ MVJL=GU2.IFPCJ3BFA;W#X[/*E,"ISABXA\?'/U^<3`F8*XWK\9ORT>NINTR5 MQD$^K93/IX9,E=*'*_XU^^Y-YN."G>F6*(?:*E@R%+5)QA69'W2^CEDR>),&#P,"Q93E@E](QYD?C(Z%9S M2E^9TN0F`TTLIE!'+C$&81X05."%Y3Z#TH2V5?JIEN97AU^-(%L]L5(T?QD0 M0!U?-1FQ2&F-&KV#+;]0&[L)<4`S\$?3Q*P.[YI-I&?&5"H2C/#E3#2NNCW> M4F=/R/JB+N!_[7//7N*J"LIF!7X>'RCM9Z^;M)9/GABI!V$=DQNB#?M"XB0? M:^ER$8^:D>22_1.G5_S<2M8IK;6M`JC4RD!,3[>A3L0JTKP"*0I5D7KOEC;5 MG*X6C?"<6D&^*AIG'XS_CN?8/DVY)C#,%OQF,F(?%=[+%+;EO3S_\US*G:P_ M_P7=<:(P=IQPBS%$GY*XQ_,]]`OCM`C:U`*;1<+Z]/:0P]B$]LC3RN,]1AQL M-"=6:7I#WU#HF$=!GQ&5!TWH9"0DS]\Q71/"T:.C+Z4.ILQLQ[<=F)-H^26; MY8O$_";=-Z#R9=36O21+2A/S,2#ZDAYK[4RV#W]/EY?-ZK]C)D&!!CF,PF#D M;\`I?'TUK(('Z647;KTQ_,*S.CE\:9)MCDN.V>6L.*>)MLZD^%C`)IQI,L"F M^!C`5C35)("MXF,!3]5CJ_BD8F_Y_'[%7OB/UUP_O$)?:SZ]7'Z)03%:TR=/ M'3R9L38.#)YA]D4&.[O2H--+F0Q&=)$=D4QV`XK)Z:6Y)O<#X'[]6&U;S[]> MH'?;3QD-!>U;^`AC3Y+%A5AR77ZUW)5R!&8S))&+Y>IKP/%KUPF8GO&")X[) MZ>86FCWK$"X55^<:AJM'!\=H<`X3NT;:1INRSGK/)6PC3?8X8LI(C]1IPYD< M/;)/'OF.OZHTL2`*EW#$#0=:2;LC)@'&$X/'2XN>L4NC^4$>G",J#8HYI72A` M%#9(#?%M<`O$PMF^!OV@)WGE.%L*I4*X08\43B5%!--8>+:(SK9].KFW?2L> MI9R^T5/,.!X:6WRJ6WK-^%7XA(0G=MYPX:<<$?(8Q;=X-_+%[:;(@Z109`?0SX'%XK'-=T@TLUU&.*S`?&5 MH?G%B;2R2M!$XTHUQ^HC9Q%^<2L+.(0211R^\-M?%I.RVC66ZD@<(`P#.Y#5 M'+#'Q]@PMP@\.KIA?P"KVS#(>!`GRKOG9'IF*JK)4LP(X78ZFO&(M>@MX`2J M/988&9?>DU.\ZM'Y:7*$YZ<*[<+`)VHV9_/VRZ45+_=V^+/GN/QK0NURF#@R M[.Y5V^7FPI&Q'O/B[,M1W!CV?'*GP^!M*TQ@3+B8=1"+#2^_C*YA'H88,8;2 M]$NBC2SVYX::&U/VX,L0*!@6Z.`1(=X#R=J))S@H/8RB3W10"E,L.M7"7&/1 M.BOE)LSJXI\4@6\Y`XU**>3),..ZSAF(V27/9F+W0-I9]E;/G'7OGBOY2NN^ M&$[A+`,KLH(SGKYPI*==R8-J'"UT(?J712BGU^Y4;/BFXOW@_>"D']4Q,[)_ M*@AC[C"D/4LH7)23VP/LKF3:@!X$VHD%DW!RT#NBO"A7+>ABM.BD$�^$0E M<_3HA:_1])$NR<4A*+2/I3"+VJG>KX$@WJ'#=NU*9JY6UZEXV:MWKM3GAF*ZWZ6 MY9P7W4^PQ7V0J/VC$E7AB]>9-T)]Z(.[,KM#GF(\4PTE$?X\1O M*+VPONBW:Z9`.[+5.'W=)Z_KT;')V42&T*/'ZJQ6/7A[#AM3848S-,^AT&/U M;RF8OXOG1$6\'PS]DRU["?K`J;G5K0B5+_RW2&=\)3[?X[>-TAQI;/1%^P][ M!0#L;=$,63\=MAKZZU6+$UEXQTKEO&^@FC5T@])'+U0*I<[N6O\(CS+$HFNG MO71SK3HZO(R:!-3Y0LNR6W#&???K#%MCA;59]+5/<,5S&76SWFTV,::V7$_< M6]X$I7`.3T2J\M>XRM3`J52I:4)^G)ZF7`IA=.>2R=]R5N6D(1M%($?NLAQY M):8GEV9V^@5EJOI)P;N=>3:LO$WMWA.+I/:T0VPLP.DF17&23': MK4L\"W7JZJ!@L9]#$3J(DUC7%?B]@M@GY(:I@[\2.;A_+Z>$D M1WE0W3GGMUF,3K/U`A1`O&EOQ13;3=Z3S^GL\B?[V?H'OEX/4&P]W?B00A8? M5^E,X:QDZAZX;]43M>5GAH@5,ZJTAZ\S?QN42.Z:PPK2NJ(G3(-A,$,VP1JI M0`V19ZU"%*>1BM'(8VX2Z? M.SG),:RD&7G9UM35=2TY'LA-DI>\;6??^B,,!'")6GEAG4'H%[+JY)U9A>YB MM0IS/IULH!<=:PX\16>=I>\MDK?^,V'1V1UZ#[1L%"/F'*GZ7_)EQTA?9A=V MG&:0L%T)0XJGNBA]2KLB^(&*]X`=[>.D^D@[1[>=;D>9S^^Z1[2[%[Y`?`ZXVO MRP.K_WNR>E\4N<7KR:\LG^,GG-EU>D+RSKY"KS?-_-,*IW\C2`1H<^2;#]:S M=ZSMYO5PW.9AYQX:"8*B>@Z.77\BEW>:OC.I9),;C6N@<8DOS[XQCDC1][\V1SIF%[#E=EK]51^Z&[W^7NBG>7B32U]>E3RB!U'P?>7Q7& M@TFV0@;,K_4!3:0&P:<)SM_M=)+<@9KL-@D9VF4PV+V6OQ^9X&KKIX#UA5.; M,@0VKX2=-=`DTJ;07#)V.%,T:WEBR:DM]E[D$1O!YG#)%D/U'&5DT/2QG?O* M/:$39MSU'I7377\KP'FV'0[LXMZI!,+#=HK/^T'+_8$Q0G^>#D.)->-*I@./ M^7L8GYMI[WD2;&EW*ZF:]3OV=^EZLXV]V9QBK)N3C37HXZ4TTXQ5JMSO@)N7 MV*.-R7K4O/1V9N.N.A-?]ESLC^P-E*XWYH:F0W3)XUUU1>YTQ.X\FX(8GNVF MHV%R1EJ/6PA[*\DOF83$9"H`8/Z-/S#88%D]+<[*19.^0!D_OJZ^$5E?.1ZN MP4&#^)O#!E,0YE?F*6AB$:[ M`$Y*60&`?L0`OYT;SM5=W*C':O7S6K-(4"9`E.Z!,Z[?T].V1D(W]0YE;@-M M4K+$NSIM/(]CEU#W\S[AS@7?QS,8;).;.:)6L].XM/F M]Z'SB=8M]&^VWIA\S?;OB\'QO:LXEJ<3,O^&EY*>WE6'^HTI=J)^T+G?K:@S M36\Z?M1,VYG[I+M-=/%NQ2-W"^627H-8XGPP#^`6[$7U\B6N]K_V^:T3R@:]<##`#(LR;M$79&1X1U_BC6[I!M7] MRBI?1P=ZP0S#P"TTP!UT)O&_LRNL^2K41U18]U4(1U38\%6X&E%ATU>A-:+" MEJ_"IQ$5MGT5.B,J//55B$94>.:K\#\C*CSW58@]%9)3`:O@;:;@E[10(PM" M;6^@]*();,2Z^L@LA$O^U22.2=C%PTIZ6$E_F95$.Q27_0ON1[F"[<,:>EA# M?YDU]+6[4;[!L%Z?PF1U78^]FH)9QRVG!OF\`38X;:+SU+9J?.L8ZL-@BC%` MZ=%C^-;N#-A*.F%W!H/;L_OM3ZNW/D5_H/1]HZ$T_8'2]]N= MZ_H4BCM@YW[-"+W!K1+[6ZC;"STK?3C3"0I><9@&X-3Q"ZOU//QX,KV\^ MW_XSN*PWT*/65W8=RZZNK6]L;FT_??:_H-AZTZI^( M7ZRMYB)9-T=XX6!3-3MKVXW=(:Y)/MI@?G',+*T],^[_Y',@,LS,F%ID-)O1 M/6GHZ?LRVM#YWS$9.CETDUJX,VM7*ZZ[9N4LU`R![OKXK-P+P:\Q" M3)'?9%OF+J7%5+H'CX)F/D:8'_UR&`.J@_Y5"#_:PZY-0_WP!M"?QHG'V&^3 MF%32YG\#PSZ>$+F8SS72(K$E*,G)QFJ.^#7?GK=*K>65ZMBEUO-*!7:IC1RQ M3.=7SA`)REV`S[G&"B`4_F:,PA=`Z1S:6(5O/&:L/R:T/]9X?PRE-(WGF.X& M*_6YQN5<`V`.YQJ=N8;-NOQ3692)YBF8\&S'-*^/_M&5IK22W3XT/-OS0->9 M7!V[WP-")/8\,O^S)_3*F=#9O/7XOW3:!'S^>[S[K?_JAV=B[K-[Z!)OM?\"JG<#)ZR\^D1U7W93+@D8O2_9+^W/FUC+0)&$23A=T?E@[ MO@&=T8^B&X!5Q_MK*8AC$*E&I&Y:@X_ZPD3J[K?YH;L9I(@&.\&GL&9NK#,C M*]J(,]>\^V.Z?$EG.P$,1,":^`R,E@)T8F:H(B>'*E"Z)=.0\;S#(\J,&Y[7 M^N6XUJ=?I4<[[,K%?/;8QJ4VF8MW%,>;<'5_AB.LZP0?.!A,Q9#:7""+SW0W M!*7<>MAP\O?:(]E-T=_(L!8.6,G$L[AW8:5B40[ZS<@3E._$R21F2/3 MZXZ(_:S7)*+,*IBY?<`NPVDX,`&@'H"_X$[,_4Z9F MJ<-I!W"KYV+!J>($RJ>R M?2>Q46Y*[^0YC5,3LZ'4.-I5YJ$A4ZN80Z="D?JU(4GN9A*F:17`+4B39O*8 M+X?`!CD93>77\T75:$O"\72Y1=.$?N-!!5V7PKJZ]5CQKACNI&PI-COA#U M,J30O&ZI5.)L5UI"F"IQ^,1)D_^=OBC][YA>.XOLQN3IM?5Y9,F7)#A')!B5 M*#@+"QNR?;`HY[:35S7OLCQ)N*E/+F%C:<6#$#9$?829RC::?R5>"M*P.R6L MY.J[%*0@ONW6/T;=:!BW;VG-30B1[KM+`>,)FZ@ZIRM.U>>DR),U3W?7I=NG MN-G)ZE.&]'1]RKF?K>_F3\V2J\Z?ZB1.34@E2[?,%.Q\J9[4"A5DSEI<7`"5 M_L5<8Q%3+##GF8O4L`7BY%Q#7?&_=AK*),F[OG''?KHHY^)8&KDTIQLH\4&? M]8"2Y5F_DYR37W+8Y+VD0&>&:V\TT+':(+F(SO;D@/%"TYD<)%$7UO0`LYS3 M>]30`G51W5?707NH8ZWY'>\__#V]Z>`;JU9:,.X%<7P#0FWO!O=6^T;I5MQH M7>%`&2[=._6O?XD9@1^0%\7R/-H+,L7YXJ=%G7Q&7"5DK$D^`;QOD)I6=-U5 M[P9FVQ3S75R=Y8Y#(6;,L>@H*Z:QK\KY*OU>X.Z!F'U#B3)S)EW/K#WG5V;. MK[YESE]_U9R_SI]SSD.Y=-7O_6ES+FWSI%_UOW[2:2SW,.O2P>675_W:U>AI MOTI-NV1$3JZ`_-J)I]K3S[Q=+9VFF5,TCYYP;2S")@;1L*U?RL7*ZIDUE9I7 MZ[D#T>[YB%G#>Z3XFC?!TQW.7.(T8W7.HMF^#AG^UPO,V'QZ<7::*;K&16_< MHN]\1=>YZ&>WZ*^^HAO^#KP^/.S]]DBC[U=\!7 M])F_`T[1B>Y&>(NUQ69WU;H&:1OS'UN9:S3]2:RVO4[E4>[B-!>VNO>0M*YJ MK%WV6>F#!XNR4CRFL+U@>/5QH,ZJK]].C\[.A0'8R874 M@OTF2<#'=B9225*<.Y,(;$G2$BD[5]>83+-6$6H93=ODX>9F.X$%Z4N!8N;6 MDZ97GM2K1##L-I0)Q@PKTJ3[$KHQQR*Q.,-BIF(#5NSR MDJA!MXI%,]DC/>V!5#:VN6&V.9;UIF[MZNM:NQK36FJJ<]F=X2P^(Y=[W55* M!+'NSUK8H+M:NJ'<7MM40:_7CV`8H&R.-VIE+PI$&3*YUMR!M.JOO\9;]<>7M\)+@3B^*J^W/-_;FN MLPVZ7=;,,D_%LY'IO:6P'G1KL!?(=5C0T'[U5"TU>D5G.VBT^K1DTG=<06V\ MRJ/5ATF(^K=J@!90NK,=O3[Q+@AM4-&F(>A6.PR:"B_CBT5@;/0D2Y>!0TPE M[.OWW#H7(N8<-=G0J2M,?,+BWO5AO4!0L,,N->R<7,AL_#N+L=V1-(=Z.0"` M7STW8;E>6V.MI>F;I1HA\"DY))LMC;A4RBU8LBZ3LN\QTFN[Q[DKYV(^RQ7$ MPA<#1=O!Y?83KI"^]&3L+Y1;WG@@QZ\IV0$`2BVQE2:/I^$_NTQ$O6 MN!!HBF@#*2K91^0TW&`*VNF$G3@]BR83JFK80-^J) ML7#9^SRY3VB@VB7FA=\8MCOZ+L#TP*!/X@IPR`\T7>N2H.VLDOD%+3X MJ)38E#0@5:0[66X&+]RBEL(,3!Y99SRD3:A(@3XLNJ8OBJA_3"457"O2/^O6 M8^E"K1[U;K\F>:`]`3IWH"8E&W91MR23CKVA\[JDR*[-3G&8J<2<6&>=*8Q< M>@C$$\P.2MX\EA7&&);K'Z&\#'EF2>I+@(N]D;L]Y:WQ6D_:H"=JX M(=_*7:I\';:A0WUP/]ZQQ;"#%/S1_BW24@K%:6QF96:B_1Q!SF%X-COTNX.@ MB.T^.C/`#`?# ME>L1TM+>+;8?"YVAVXX!MDL`'?SKRR^=!-(F\;5B_R97-XPC2QN$_PA2)VBW MHSJ\Y.T?^N'RFQS%EJJ+5P'QK<80VA>/L:S16#L-V%1B0-BD>"Y;#@IP$)7XJ;CE]`P^#M._FF[3YA.4Y,-`8],?;T\;0FOA'Z MD3,ON6JD2R>X+O[Q=_BP&K#"_Y2>W4L;:ZNKVYN;ZA^`NJ?K:_CO.CRAW_!9 MWUC;6(,WJT^W-]?7-M>WE5K;V%A[^@^U>B^]27V&>,FZ4O_H7T51_6-^.73' M&P(7^1Y]^HZ?$FQ1>[`+]UMHKEW86U1KSY\_6X8)6E7JM(4KK*%>(VH*4!3_ M!X[;BO6E/@J^TH*+H^;@!E;`KKJ-A@I5<5@-+11"+_&N"E"C8)VO1)2H%!1. M`@0/A]T&,F:\?C?L=V(M?;X^NE"O26MOJY/A)1Y]'(+TW076`6)O#Y_$'X'C M7S(@K$*>CV?2"W6`.9K)WW%7A2UXWU?789\N"ES7C0C$HHKZ!&4!=$SH?%]% M/7+=A1[?JG8P2.J6OSF^ M.%?EH]_4N_+I:?GH_+==\BE&5R$T4Q"L5J?7;@%H&%L_Z`YN80@$XFWE%)TD MSLNOJH?5\]]@).J@>GY4.3M3!Z"=E=5)^?2\NG=Q6#Y5)Q>G)\<@HH.#D:%-5-OP6D([NV,[]4/YGCHJIVZZ6BVGZZI=X&($Z7KV%: M]X+.9;_5N(*O;\MJ=7UMXWE179R5DW$X]`U;["U.$0A:=:8M%79@W`J=<)D[ M_)]@T&V6ZG&K'Y6"H1!"B'+)`(88-!I]E.5;\0Z]2JT?4.E6(E4^/SHHJI.2 M.BZI5]%G]70;A+->C\\*2V>E=S",];5U4"G*P)D`>[JK)H]!`7ALSJ[C0=A1^T'80>44ZAQ M]D8=E=]6"MR$>K\LJP#&U:!"3`Y!-Z#;(]EY:X&7$0+@.L4$>Y%@ MGOUV='QR5CTKE%Z)Q0F_L0V_\#M^7[XN?)!O#?-MH+K#COFU3[YLYF?S"KXB M\/W*V=YI]00=5`LX#^^;56[C??,DN74,EV<@@RBJ_K"+,\N:,.'@,HH&A;C> M;_4&(`F"\@>D@/P+`%RW^(Y,TL';[=85^]4!#L(.?@4Z;_"XT1_29`":7QG+:1(&L^GWSUZC4',K+@QN>X(S.KR9SQ$?C2Z0L*,`5"7S.IV1QN%4Z!79Z(=%^R2NB`G M80I.@H>T!:6Z5#!=0F&)^+/5&T%_T`;-CG`0>Y%0$"0`F^YJE# M"B`#@LZ!;V/<;FBK0!<0!73]49@#81] M!A07;ELA2'HD"G(A)YS(C%RV:3UTF3YXI*/*FO:32 MJ)MN3183L&G<$@'"7M0A60!_`;D,8^%M#"!`ID)NLO,_S)/)"WAWV#?5"EP- ME]AE.^A^$C"X<[:N@)LCXZC0_N#K!7:]\"F\O8GZN#K:[>B&:?Z?83]26GR' MC3_HA'BM#)ZMT=$3\G7"=H$A,0]B"&1DE'-LD?P]$65<#Q;*JQ#J%+##M*#P MANP!KCSI%LK"/.75H[W#B_T*'>@40%YO#QN^4#5"/AIS:"`P;UB>5LPO^J"> M[BVCY8H(Z+%JQ*M+"JN%6.+@S%#@SR_ETVKYU6%%57X]*1^=(3E=8N\7#5DR MRR\?UIS.@O`47$:H4H2?ZV%O(%H=+S;J;R."20.=A:V\1=3X<-'"J^Z@?5O0 M4ZF;V3NLE$]K3-B%/:`0$2R&?3KW=1"2[,CV)8ETUHW,C'5*&CYO2D8ZX%Z* MFG89%BAD!45+O7DUY!A<*`PIS][8NA)'`K19D-`P-K;"=AI\9BV'AT/!*DI' MX98I8DS]'O2OXE*I]*'`&R),#I43>0#':^#C2ZYFO77OP4(H7:M65`=LB00D M)7&KZ\*VR@.]29@=>3O!N@>.!3(Q0W=.[EE\X`BNH-D$B@'DL/QF9K;%%)O( M'=:6K^E`-!^SU^/^@@9FE/Z0RP!C0UF]@+?OA72/?`E4VDYHIBP>]O""(R`C M8+1X_1E)QW&1?,X)"HI6B%E<$85"=DDH=TD0(C689%4DBZ*0711*%@7N@>A* MP.+HP&$0QFD&\1@76-*O1U?=%G03"./4B$WB)D5X:PY1!,$#W?11H\C.21TL M4$A/5%(2IH/DD"3"C#K2"Q(@N)/);#7\4PT;3E0'S5W7&+8:5`&]XE5U7]>1 M252D!R)0*7XEQ=DW?%3YTXI9Q`D*1?K,H(Z!:SFU<)[N]0T=_.K((&22@2[0 MZ+>NT5%%8"3!17XH=H31*#A)8!'!H4$1``XE8C.`%D3UZ,W"H7MU<94$!2#Z M'I!YN&AQPN.S"B.&-MU`1X29$AQ$5"AWI5V.'Z*2L-F@'!*R1C,@-H//NY$S MUJ0QBBEN(Y-,A'PNPKQ/5)]:ON5+![`&H M]P-7$/Y$LLJE61J(2C6+M%\B(+,$CXVG!7H^BR0]*R_1``#B$1E$R&YFG-2A M$`BYF&X/TK(9KCA:0">[N(,: M&2_6IDV-VO[-9_X#*M\[I+:"=*G%"P7]N('1!A@KDH"QND@;/5I]VLCF%L+2 M50FA+N.?Y67M"$X&#]*"R7PJ;0+@W=$*J'>V97,D4!=[4O[V,\-BZ;2_7 MM\?[A\?E?=8K9=MEO1*MKNR,^*/V>54+=*TJ/YV%E1(V6Y_-ME20)"[9/%XS)D(3=L-EOU%FE)J.S(O:-( M%``3%NEEN/!LD54>GA2T1DE\/S[6$LY%S-5>R5`M@00'`,I7B':3P<<(!U+` MGDJO$^5&P/).AW(0B4$VSO`P]R:FHQ(8.2I@@;*T$DN0U6W#3]H2DSU&*]12 MGZ4H:$QJ!4314-S8<8T<4!!I0I">P%KH!)];G6%';2_Z.D%GHP9,@:=7W]&J MS(6M$R-HMA.TNK/+\>"V'2;5<3[1;B<']05Q`AB!0V/2LKT& MB@EA:$,A=1-YCYQN8ZQ"%S@9\78T,+6C2RC&C""F%G6O4-IL905-TVFN,W;N M"MFY2Z$YN>9=3]U6>NH*V:E3(Z?.9%G0IIM!1`Z&+.GB@9]NE'2<3@O-SU(7 MUQO,$K9L2L'@]Q*=6V3V!"PJ$@62I*$"AY9`Q^I%<1"A2]H7=\V&/`T5^?KW MRM!ALNR-8B?"?$&SCSH&F743W6@UX6+'C:]94V@;)>,\R);'B]# M;6I%V(!$#F<1*WA8L#1S(Q/" MI.J*I*O;?WUT?%IQIJ0>P!84T_J)AY`7JS50@K)ZC-99P`+1,%:)GBNK7BP<('"( MI@OEI2U0,N0ST=AB90/S]QS*U:3&GPL`Z0/?:&C*>IG2*?_H(C<)@88@%(].O<< M?I'_>KT=!B#CE:S2H!*^G:+XFXN3/,-K"P7.92-SXC&$LZ_R5`R[*"B%8M&M M_%I^>W)8H4-A[?C<;5">MGYTF[LD0)`7[M9M%DIH?E,E4!SVWA6TFDO^1*4E M93XVGTBTX50A>Y4F8&'LS18SM,.3O)[FK+2OZFFRK$?T-"DTHJ>'EE":TP_6 MJ@6LTP^1\$>`?XOGD.;L4YS661*VL+9T%+>WBJK0F MH:B@BY;1$"2+G%3TC@7H\*!*1'BRKU:1V-4Z_/.JFCE+*/B-U'+<@B*`+(1. MB[G<+BQS"49XM%^J45 M&GQ"95['8``AE. MX>-@T-M96;FYN2DYH%?^S0W*R?[?P_OQX2/^GY9%NG[G;8SQ_]S:1O_/[:?K M\/+ITS7XOK:YL?[@__E=/BM+AR`Z'%9?G99/?UM:(4]\FQC8V9T$373PT>?\ M,4B$*!">H4"XW&Y]"JU:B5Q8XNH9!].GR_#7\[2#:=)4NW79#]!"/Z5WJ#4A^X1KJ94:PH_TTGF,^5O*K@=X6_*R2VRLSVMORG!F=S9]%,`.MLZ! MG)GR.67*\/JGR6>4$6WBVH\ZCZ!.:QDF'`XHC.S2%,!4P:UR]';!02#K: M3_V7JA?4/P57H;1U&,3`B)(&TVT]6_Z_%T?$#G?4'I\^8=:B&O:Z1CAMO$2= M6IE!ZD0>1FNE4XF8-5TL1.O86/%@$F`N?Y#S:X3=:$6ECR^M1W4T.[F/)%=2 MZED#UHS[;-@%MM1PGU$4G?NH=Y,J0S3.CYJ@9JM:[>?RZ=MRK5;X02FW5"T> M4,',\SX]1G^69J'P`ROKZM7%0>VL^O\J:FU[X]DF@N]FX$O1?@U0&7:O%?]C M0!'=G_1;UZCO:3S&%--S=EX&9E!;71!`LH\7EK"+BQ,DQN&ZR8,B:4#0[WZ_B;D" M=DD^O*(0 M;7BF5;72^!-DB.>4AQW-+Q*'3"BB> MYH*HE1,LVN(Y="^6+&PI*R#[509]VH!A7QN$02-1ZEM2BU.HD%]1?G4S]F8$ MW>ZJH'_9&I`\HF-/DR.6G]Q1ZJ'3M+]4^ZW@JAO%E!1/>V>C\.',2KJ3U#4^ MCI+05?(2A;=R9,QC^_8X_O1:\3P5]I6DE7,X9/QWS>`_P(1V>E^3,<#E![-6?BZ:A"1;E/P4?"91M;P>U$NSV2P*XX"R^I&5 M1'R7\^*H)T]H12296"3A,.<(D'=6RN'Y'^=W=!Y9Y7%_).8G=X3@2GNA4CN0 M6M#[CN9KC_7NHCNC\\7!Q^'OBED2,Z/=)`A>6DKGTS*!^:1UN$EYY_]M#^,- MBD^):[MG,(0.:N=WO"_4-`WT3`Y>B##.L8DE7W#N!>OG>[PQ&%_ M/D8W&="9[/9WT#_W&KT_T$L6GM",460PI63#/NGD#R@IO$B$AH79-\=O*[-N M@/(,3I^;09A02&@F+'-,O\5&S$&&>D\0W\^2-T@3M0V=T(]J.I1,U^7BT\P, M8$Z!&3<3"C1';X1VU1.S2E^^$-(8T77NLL/K@8]%*L90DZ_N82?L4(H.`6BZ M5$3D$,'J]"XSNK-/7C#/P0M)3*(+;.%+0E[HW(5>V\C+8,;=V4YHC-8EW]`C M"V%7/7+HZ_%C(JA'0E_63Z0O&ANOVR=/`(XF?<8[`EYF$K;H%]\!OB6"'WB7 M1:->E*.S#MF_1;AW00I^-,JAZ2+WCO"L2R$WA9])*C^'M?"8UNSUB'F( MTVF(<5CNBA@YQ-!)3%COS"7.]D,YSCL/V_`LI=+!YX\^6!G>Z';0A)> MGO1)HTF+[GIW$S!.JY+"Q&E4$//%D_%$=]*?I-15($CGR%$2;;7$D\HTLT&/ M5P_-!NU7$_VJ"M>87`L3'64FK:,PG"F5%+.EB6C+HV.=P)".L;9Y=`P1ID9H M&3+ZE[97@2X(SUN#1-U`*9C-+ZZ&DLD+PYPN<;QT\_XA]KY>)2%QW2*X;U)) M2!T1)>>.5!(:W=>H(N.2[6"8:23]CX>7EJHY+O^.HWB,T#0EAJ7%7GVC M:"D8]/`KE8::RP3,$M;J@R6UKGY(5`7A8S_.&ZF?I!0=BQR(\7OVQQ]G=]1) M=9]%%),C4=%>/4L7)/(=#;C58FI\LHVDY#S9$9,=;Q!OQ_U&JXLTG'5!*NKT4!37P03A MW+4CTML?J9G@P#^/2Q--A"4GBI38BH-V=]C)*"$U5PG9F=<82HN)/A$Q3SP< M-56#L-.+:$'?R6QYA,*L0)@5!AW=R$W431"Q&T5S59`E%HX:FJT241*UM$)$ M>/6+@SG#]"I$?]V%DM:!IETHQEA@UL(.YX,@;@/4J0;]5OU3LD(TD0I%TKBG MH?W=%)FG^-\7=]6]E?B*.'?UT3$='^1\F>6U^'=>.(S&L>89EU$F:Z=H[#`X M8`*6D]'&61G8(";,ZF)?`6[2<8!10@%.Z ML+.H7E$>`YG MHHI/&948N8+Y.)SNAT.D.1W3\>-[NQ$JZPA',7 MP(Q#U?]I$D3%@UN)KA6R)$SK<%^PBTX)P8ZKF.N"F#: M>;3!VY99[]^#BW+:'NB'=^^X:XZ:X96T'!ZE#ZD)HJ.G9J4"I4_NO3WTZ88V M[OPT.PJ%4Y'L6)R-UP^Q=(9N[:6@2==KM4M+6]]PO1!;PJ8VIQ&;]IC4[,N* M7!/:ZW!@V<^\P2OH@2>&FN2H_-QF7C@#TUNM;/Z7V)S$7$70OM5D1:%U"&BD MR9SMR)V4]M"^P(W"\V13,>3.S;Q09EK=@U#-ZKG8H[3L38]] MB;23PT+C)#+I333?R?]7_+_%'>M^VACM_[WV='-;_+\WMS8VM]8Q_^_ZQO:# M__?W^*PL$;W^(A%[I,2T]%%&7_U,=*$JF(^&LN*8\+5&GF_W^H-O]X-O]X-O M]U_=MQL$C^6O_P#76%*&DE/NX>ASP92*,;']B/+.)7P%A3I='47=Y/"4R+T; MF<3:2>H33=+\,=5QP;5#]+"&5=/!N\VA%5B=.\N+*O^#U;]E[(`][5;,3L5O MC/>Q_GU'V#V,KC!7J!%\8@D_=9!Y'^-#AW`<'T4LMX.KW8)VU,9S=?2A'G:3 M7^PWK7%`?H5KNCP=K"<5Y*=;@QZJU;O"6A64SBO<'&`00([H04->JT&L[5<^ MO-TAUH@9M7#][IIGYM"27@[YY1T->-\0!+)-LI9,\+G#98!-6H[UU(,%UG(6 M5XU?_=T,]J1JC=>_`.YWL"=5:ZC0FXW2VN;:UO/U[:V-K6?/GSX'X?79YG:: MQD^JM>.CVKI:@!I+:K6TM9@LF'?'-7C*;]9+JXM6I>.CM6>K]&I%P3?[)52# MQUSY;I!+F=$B2GDE&;@P_?MX9-\%/]XXM7AY5: M]:SV2_FPNH\:%REI;?635%GTE'UU6#[Z6ZN?;3[;>KJ=`#DI[U4,C+5D.LJOWE7WX=FSA";+ MKTW)[;OAV<=$DX)\G6^7!#T0.[L&R.TA'(M\$\)4<-<`8MW.=;37VK'/_OPN6H7 M>57>KX$"4'[K%%FSBU`"0R`^M]BZ70366^TMZ"=NF8UT0YQYUVYHTRZ"7F=X ML67MX/CB:%\7V;*+[)6/L`"FJ;2@;-M%3BO0$EWC:3?TU"[R[K1Z7LF4>>8, MNO(V"T0]MXN8ZT)=U&70NU\^+[LSL.;@]^3T^#5@K?;JXK5=9CT-A]!S_MM) M)2GC8'CO^.C\]/BPMN>VY:"X_.KX]%RE/VL.CB^.?CXZ?G<$LP!BKBF\YB"9 ML]]A2B%[PM:>NG#V*P<9#`&CVK@K*>&=SCKZ*;RE,\7,R'R?.UQC)^4+D&D; MT1]DA6S]OK[Z8?FAH$VR:R3!LU7DW(VL>\SW(/# M\NO:+Y73ZL%O"Y=1!#LNG_+A=S28DCLN>='K)^QQJQ;5^T)^#_\PYQ`<@R,' M$:^"!@^1^.6.FJ.CF_?&835U-$H=VE7O)5`A"[-\&?71`[TT5Z?#C%>50RAO M*@3X6BWH1TGW[F9+4"+!AZPZ!:ILLJ,,D7U.[W*:-EE4Q9&6@$J9C4Q,M1:`T$[3BD3&N`";'#+3VA)\'1?4QN@FO MM9=T62,"\Q]1ZCY`3Q=O,J*\?^ILV#T^0\"7_>A3V-T1&:C/\[.Q:!8NG];P M8;/)0%3B0';6PLR-IA08WM3N-PO'9S5JA1W4]--XV"7N\T@_J-7BZ_YFK>8^ MQXFU`OW_8Q3:-"@C=H)UL(80V['+XX(-3U'3: M*4=T207I+MA\V!I1^&LQ#[`4DLMLJ9AHHG>@ALN2$W95^?6\>QCC_RY^W`H+JC_`5,O]JQ@V()GHV;U9]0>^H.>[ MP-QM"'*DB%=YNS/%#==K;KN3M:P;2]5)M66WYM!ZK79VOK^'1`RT;E'VH%&' MA[K"5$A(]RB_3VZOIFUD(=L]SJFA83/).E_OC(Q=*DZ2'DC.`SJLSC4@?Q,1 M6S2MJ[>U)[>SXXG2ODMNR4RK3.@+U M-_R-\X6",0%B3PTYU?G[W.H\^<>]_QFS7-Y]&Z/]/]3:UN8&WO^\N;V^NKZQ MA?<_;ZYN;3[X?WR/SP_J+*`8C-P;U*R,I[#,4NFK?O)E&7TY,[.Q?%!YQ1?2 M_@"U*EUV9\/[?]QTN70Y#Z[EJ&WN<:0LS"7R$,"C]+KZ`8V,G33F^PBK$0$;?F22T\Z4EF9F M_$F#Z96=*AAJIWN(/:.K1BXI+VX7K\.T>F]EG.;^SU]C'\Q5=0UV'I$4K*`^ MF8'U6U@-&TJ[?0O`\(HDSF+]@Y-Q%S[7]14[TZ^3'/D' M)[FNI[`]\@SDWN!V)2_M<@9RNO!(R)U67+>WPI&0TX7'S!;1TPAJ; Sun, 16 Apr 2000 18:47:38 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:6534 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Sun, 16 Apr 2000 18:47:13 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e3H1kHG05860; Sun, 16 Apr 2000 19:46:17 -0600 Date: Sun, 16 Apr 2000 19:46:17 -0600 Message-Id: <200004170146.e3H1kHG05860@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: linux-kernel@vger.rutgers.edu, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: devfsd-v1.3.3 available Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Hi, all. I've just released version 1.3.3 of my devfsd (devfs daemon) at: http://www.atnf.csiro.au/~rgooch/linux/ This work has been sponsored by SGI. This works with devfs-patch-v130 and devfs-patch-v99.7 (or later). The main changes are: - added new actions to allow functions in shared objects to be called directly (useful for custom extensions to devfsd or for calling C library/system calls) - Added compatibility entries for Computone Multiport serial devices. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Mon Apr 17 12:01:03 2000 Received: by oss.sgi.com id ; Mon, 17 Apr 2000 12:00:53 -0700 Received: from nat-su-33.valinux.com ([198.186.202.33]:32778 "EHLO phenoxide.su.varesearch.com") by oss.sgi.com with ESMTP id ; Mon, 17 Apr 2000 12:00:41 -0700 Received: (from jerdfelt@localhost) by phenoxide.su.varesearch.com (8.9.3/8.9.3) id MAA13181; Mon, 17 Apr 2000 12:00:35 -0700 Date: Mon, 17 Apr 2000 12:00:35 -0700 From: Johannes Erdfelt To: Richard Gooch Cc: devfs@oss.sgi.com Subject: Re: devfs and USB Message-ID: <20000417120035.Y14581@valinux.com> References: <20000328144530.Z860@valinux.com> <200004130453.e3D4r9F04628@vindaloo.ras.ucalgary.ca> <20000413115522.W14581@valinux.com> <200004152255.e3FMtG425171@vindaloo.ras.ucalgary.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200004152255.e3FMtG425171@vindaloo.ras.ucalgary.ca> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing On Sat, Apr 15, 2000, Richard Gooch wrote: > > > There's already a daemon which does this, devfsd. It already gets > > informed of device insertion and removal and does things with that > > information. > > I just want to be sure that you're not wanting to "hijack" the devfsd > protocol. In other words, that it really does make sense to use devfsd > rather than a new daemon (even if you don't modify the protocol). Just > because it might be convenient (it's there, and it's easy to tap > into), doesn't mean it should be used. > > On the other hand, it doesn't mean devfsd is the wrong approach, > either. I just want to get a clear picture of what's going on. I don't want to modify the devfsd protocol. My original intention was to do so, but upon talking to other people, this was deemed a bad idea. > > This driver binding is done completely via ioctl()'s on the USB > > device node, completely bypassing devfs (the kernel portion). The > > current patch that I've sent makes no changes to devfs (the kernel > > portion), only to devfsd (the user space portion). > > What exactly is this driver binding process? How does it work? USB devices have multiple interfaces. Each interface is a logical function of a device. For instance, I have a webcam which has 2 interfaces. One is the video camera portion. This uses a vendor defined protocol. The other interface is for a microphone on the camera. This uses the USB consortium defined class specification for audio devices. So, we want the driver specific for the camera to be responsible for the camera interface, and the audio driver to be responsible for the audio interface. It also gets a bit more complicated than this. There are configurations for a device which modify the number of interfaces and properties for the device. There are also alternate setttings for interfaces which define the protocol used, the amount of bandwidth allocated to an interface, etc. There is an election process which a device goes through to select the appropriate configuration, drivers for interfaces and alternate setttings for interfaces. You can take a look at my explanation at: http://www.electricrain.com/lists/archive/linux-usb/2000/03/msg00860.html This explains the proposed algorithm to be used. > > Another really quick example. I have a digital still camera. The > > driver for this camera is in userspace in gphoto. We would like to > > setup the permissions for the device to be accessable by a certain > > group of users whenever the device is plugged in. However, the USB > > id, which is what is used to create the device node for the USB > > device, is arbitrary and can/will differ each time the user plugs in > > the device. > > Why does the ID change? If you plug the same device into the same > port, why does it change? Do you have unique sequence numbers or > something? USB ids are assigned to a device by the host. This is a unique id to identify the device on the bus and is arbitrarily assigned. It is assigned in sequential order when USB devices get enumerated on the bus. It need not be sequential, but that is how it's implemented currently. Because of the way USB devices are enumerated, they can be assigned any USB id and this may change from reboot to reboot depending on the sequence the devices were plugged in, or the topology of the USB bus. > > We can use the same code to choose a driver, also track the device > > and assign the correct permissions to it, no matter what it's device > > node name of the moment is. > > Ah, I think the light begins to dawn. I noted how in your patch you > were using the DEVFSD_NOTIFY_REGISTERED and DEVFSD_NOTIFY_UNREGISTERED > events. I was thinking that you were just creating fake events (by > trying to write to the /dev/.devfsd pipe yourself somehow) or by > registering fake device entries. That's why I've been negative, as > such a scheme would be a real abuse of devfs. Far cleaner to implement > your own protocol and daemon. > > However, I'm now guessing that you register a real device entry (in > other words, it's connected to a driver (in this case, the USB > subsystem driver) and is the only way for user-space to talk to the > device) in the USB subsystem, and you want devfsd to install the best > driver and (somehow) attach that driver to the device entry. And you > make the attachment using an ioctl(2) on the newly registered device > driver. > > Furthermore, the attached device driver doesn't register a new device > entry, the user must use the "generic" device entry created by the USB > subsystem, except that it's not quite so generic once a driver gets > attached. > > Is this a reasonable description of what happens and what you want to > do? This is exactly what is being done. > > Do you see this a good use for devfsd? Would you accept this feature > > for inclusion into devfsd? > > If it's as I descibed just above, then it makes perfect sense to use > devfsd. Great. > > I'm not asking for the particular patch I sent you to be included, > > but rather for something like it. I can make changes to the patch, > > or reimplment it if necessary. I have already changed my local copy > > to use threads for instance. > > I'll implement part of what I'm planning for devfsd modularity so you > can see how I want this done. I'll send a message to you and the devfs > list when I've done this. Also, please subscribe to the devfs list by > sending email to majordomo@oss.sgi.com and "subscribe devfs" in the > body. Excellent. I did not realize there was a devfs mailing list. I'll subscribe now and make sure to open up the discussion for all of those there as well. JE From owner-devfs@oss.sgi.com Mon Apr 17 19:37:26 2000 Received: by oss.sgi.com id ; Mon, 17 Apr 2000 19:37:06 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:11912 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Mon, 17 Apr 2000 19:36:38 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e3I2aSo27324; Mon, 17 Apr 2000 20:36:28 -0600 Date: Mon, 17 Apr 2000 20:36:28 -0600 Message-Id: <200004180236.e3I2aSo27324@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: devfs@oss.sgi.com Subject: Re: devfs and USB In-Reply-To: <20000417120035.Y14581@valinux.com> References: <20000328144530.Z860@valinux.com> <200004130453.e3D4r9F04628@vindaloo.ras.ucalgary.ca> <20000413115522.W14581@valinux.com> <200004152255.e3FMtG425171@vindaloo.ras.ucalgary.ca> <20000417120035.Y14581@valinux.com> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Johannes Erdfelt writes: > On Sat, Apr 15, 2000, Richard Gooch wrote: > > What exactly is this driver binding process? How does it work? > > USB devices have multiple interfaces. Each interface is a logical > function of a device. > > For instance, I have a webcam which has 2 interfaces. One is the > video camera portion. This uses a vendor defined protocol. > > The other interface is for a microphone on the camera. This uses the > USB consortium defined class specification for audio devices. > > So, we want the driver specific for the camera to be responsible for > the camera interface, and the audio driver to be responsible for the > audio interface. [...] > Because of the way USB devices are enumerated, they can be assigned > any USB id and this may change from reboot to reboot depending on > the sequence the devices were plugged in, or the topology of the USB > bus. Fair enough. That's about what I figured. > > > We can use the same code to choose a driver, also track the device > > > and assign the correct permissions to it, no matter what it's device > > > node name of the moment is. > > > > Ah, I think the light begins to dawn. I noted how in your patch you > > were using the DEVFSD_NOTIFY_REGISTERED and DEVFSD_NOTIFY_UNREGISTERED > > events. I was thinking that you were just creating fake events (by > > trying to write to the /dev/.devfsd pipe yourself somehow) or by > > registering fake device entries. That's why I've been negative, as > > such a scheme would be a real abuse of devfs. Far cleaner to implement > > your own protocol and daemon. > > > > However, I'm now guessing that you register a real device entry (in > > other words, it's connected to a driver (in this case, the USB > > subsystem driver) and is the only way for user-space to talk to the > > device) in the USB subsystem, and you want devfsd to install the best > > driver and (somehow) attach that driver to the device entry. And you > > make the attachment using an ioctl(2) on the newly registered device > > driver. > > > > Furthermore, the attached device driver doesn't register a new device > > entry, the user must use the "generic" device entry created by the USB > > subsystem, except that it's not quite so generic once a driver gets > > attached. > > > > Is this a reasonable description of what happens and what you want to > > do? > > This is exactly what is being done. Hm. But is it quite like this? If you have a device with multiple interfaces, and multiple drivers get loaded, what's the interface to user-space? Do you have a single device node and multiplex that, or do you actually present multiple device nodes, with each hooked to a single driver? I have another question too: from what context do you call ? I.e. interrupt, tasklet or process? Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Mon Apr 17 19:45:36 2000 Received: by oss.sgi.com id ; Mon, 17 Apr 2000 19:45:26 -0700 Received: from nat-su-33.valinux.com ([198.186.202.33]:59403 "EHLO phenoxide.su.varesearch.com") by oss.sgi.com with ESMTP id ; Mon, 17 Apr 2000 19:45:08 -0700 Received: (from jerdfelt@localhost) by phenoxide.su.varesearch.com (8.9.3/8.9.3) id TAA14196 for devfs@oss.sgi.com; Mon, 17 Apr 2000 19:45:08 -0700 Date: Mon, 17 Apr 2000 19:45:08 -0700 From: Johannes Erdfelt To: devfs@oss.sgi.com Subject: Re: devfs and USB Message-ID: <20000417194508.G14581@valinux.com> References: <20000328144530.Z860@valinux.com> <200004130453.e3D4r9F04628@vindaloo.ras.ucalgary.ca> <20000413115522.W14581@valinux.com> <200004152255.e3FMtG425171@vindaloo.ras.ucalgary.ca> <20000417120035.Y14581@valinux.com> <200004180236.e3I2aSo27324@vindaloo.ras.ucalgary.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200004180236.e3I2aSo27324@vindaloo.ras.ucalgary.ca> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing On Mon, Apr 17, 2000, Richard Gooch wrote: > > > Ah, I think the light begins to dawn. I noted how in your patch you > > > were using the DEVFSD_NOTIFY_REGISTERED and DEVFSD_NOTIFY_UNREGISTERED > > > events. I was thinking that you were just creating fake events (by > > > trying to write to the /dev/.devfsd pipe yourself somehow) or by > > > registering fake device entries. That's why I've been negative, as > > > such a scheme would be a real abuse of devfs. Far cleaner to implement > > > your own protocol and daemon. > > > > > > However, I'm now guessing that you register a real device entry (in > > > other words, it's connected to a driver (in this case, the USB > > > subsystem driver) and is the only way for user-space to talk to the > > > device) in the USB subsystem, and you want devfsd to install the best > > > driver and (somehow) attach that driver to the device entry. And you > > > make the attachment using an ioctl(2) on the newly registered device > > > driver. > > > > > > Furthermore, the attached device driver doesn't register a new device > > > entry, the user must use the "generic" device entry created by the USB > > > subsystem, except that it's not quite so generic once a driver gets > > > attached. > > > > > > Is this a reasonable description of what happens and what you want to > > > do? > > > > This is exactly what is being done. > > Hm. But is it quite like this? If you have a device with multiple > interfaces, and multiple drivers get loaded, what's the interface to > user-space? Do you have a single device node and multiplex that, or do > you actually present multiple device nodes, with each hooked to a > single driver? Right now, we have one node for the entire device and everything is done via ioctl()'s. This isn't a good idea. I have a solution which splits out everything into separate nodes, but I'm still implementing some of it. > I have another question too: from what context do you call > ? I.e. interrupt, tasklet or process? Kernel thread. It's called khubd and it handles all insertions and removals of all USB devices. JE From owner-devfs@oss.sgi.com Mon Apr 17 19:56:26 2000 Received: by oss.sgi.com id ; Mon, 17 Apr 2000 19:56:17 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:13192 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Mon, 17 Apr 2000 19:55:57 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e3I2toJ27552; Mon, 17 Apr 2000 20:55:50 -0600 Date: Mon, 17 Apr 2000 20:55:50 -0600 Message-Id: <200004180255.e3I2toJ27552@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: devfs@oss.sgi.com Subject: Re: devfs and USB In-Reply-To: <20000417194508.G14581@valinux.com> References: <20000328144530.Z860@valinux.com> <200004130453.e3D4r9F04628@vindaloo.ras.ucalgary.ca> <20000413115522.W14581@valinux.com> <200004152255.e3FMtG425171@vindaloo.ras.ucalgary.ca> <20000417120035.Y14581@valinux.com> <200004180236.e3I2aSo27324@vindaloo.ras.ucalgary.ca> <20000417194508.G14581@valinux.com> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Johannes Erdfelt writes: > On Mon, Apr 17, 2000, Richard Gooch wrote: > > > > Ah, I think the light begins to dawn. I noted how in your patch you > > > > were using the DEVFSD_NOTIFY_REGISTERED and DEVFSD_NOTIFY_UNREGISTERED > > > > events. I was thinking that you were just creating fake events (by > > > > trying to write to the /dev/.devfsd pipe yourself somehow) or by > > > > registering fake device entries. That's why I've been negative, as > > > > such a scheme would be a real abuse of devfs. Far cleaner to implement > > > > your own protocol and daemon. > > > > > > > > However, I'm now guessing that you register a real device entry (in > > > > other words, it's connected to a driver (in this case, the USB > > > > subsystem driver) and is the only way for user-space to talk to the > > > > device) in the USB subsystem, and you want devfsd to install the best > > > > driver and (somehow) attach that driver to the device entry. And you > > > > make the attachment using an ioctl(2) on the newly registered device > > > > driver. > > > > > > > > Furthermore, the attached device driver doesn't register a new device > > > > entry, the user must use the "generic" device entry created by the USB > > > > subsystem, except that it's not quite so generic once a driver gets > > > > attached. > > > > > > > > Is this a reasonable description of what happens and what you want to > > > > do? > > > > > > This is exactly what is being done. > > > > Hm. But is it quite like this? If you have a device with multiple > > interfaces, and multiple drivers get loaded, what's the interface to > > user-space? Do you have a single device node and multiplex that, or do > > you actually present multiple device nodes, with each hooked to a > > single driver? > > Right now, we have one node for the entire device and everything is > done via ioctl()'s. This isn't a good idea. I have a solution which > splits out everything into separate nodes, but I'm still > implementing some of it. Yeah, I think separate device nodes would be cleaner. Now, if you do that, do you still need the user-space daemon talking via the dynamically created "generic" device node? Or can you just talk via a central device node for all USB devices? The PCMCIA code, for example, just as a central node/pipe which cardmgr talks to. Why can't you do it like that? > > I have another question too: from what context do you call > > ? I.e. interrupt, tasklet or process? > > Kernel thread. It's called khubd and it handles all insertions and > removals of all USB devices. Whew. That's a relief. At the moment, device registrations have to be done from a process context. I've left this issue open. I may decide to support this from interrupt contexts, but that would make things a lot harder, and I'm undecided on whether that's a good idea. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Mon Apr 17 20:03:07 2000 Received: by oss.sgi.com id ; Mon, 17 Apr 2000 20:02:57 -0700 Received: from nat-su-33.valinux.com ([198.186.202.33]:1035 "EHLO phenoxide.su.varesearch.com") by oss.sgi.com with ESMTP id ; Mon, 17 Apr 2000 20:02:38 -0700 Received: (from jerdfelt@localhost) by phenoxide.su.varesearch.com (8.9.3/8.9.3) id UAA14255 for devfs@oss.sgi.com; Mon, 17 Apr 2000 20:02:38 -0700 Date: Mon, 17 Apr 2000 20:02:38 -0700 From: Johannes Erdfelt To: devfs@oss.sgi.com Subject: Re: devfs and USB Message-ID: <20000417200237.I14581@valinux.com> References: <20000328144530.Z860@valinux.com> <200004130453.e3D4r9F04628@vindaloo.ras.ucalgary.ca> <20000413115522.W14581@valinux.com> <200004152255.e3FMtG425171@vindaloo.ras.ucalgary.ca> <20000417120035.Y14581@valinux.com> <200004180236.e3I2aSo27324@vindaloo.ras.ucalgary.ca> <20000417194508.G14581@valinux.com> <200004180255.e3I2toJ27552@vindaloo.ras.ucalgary.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200004180255.e3I2toJ27552@vindaloo.ras.ucalgary.ca> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing On Mon, Apr 17, 2000, Richard Gooch wrote: > Johannes Erdfelt writes: > > On Mon, Apr 17, 2000, Richard Gooch wrote: > > > Hm. But is it quite like this? If you have a device with multiple > > > interfaces, and multiple drivers get loaded, what's the interface to > > > user-space? Do you have a single device node and multiplex that, or do > > > you actually present multiple device nodes, with each hooked to a > > > single driver? > > > > Right now, we have one node for the entire device and everything is > > done via ioctl()'s. This isn't a good idea. I have a solution which > > splits out everything into separate nodes, but I'm still > > implementing some of it. > > Yeah, I think separate device nodes would be cleaner. Now, if you do > that, do you still need the user-space daemon talking via the > dynamically created "generic" device node? Or can you just talk via a > central device node for all USB devices? > > The PCMCIA code, for example, just as a central node/pipe which > cardmgr talks to. Why can't you do it like that? This the same interface that user level drivers will use. We could use a central node/pipe, but we're gonna create the device nodes anyway, so might as well use them. It could work either way. I'm not particular attached to either method. > > > I have another question too: from what context do you call > > > ? I.e. interrupt, tasklet or process? > > > > Kernel thread. It's called khubd and it handles all insertions and > > removals of all USB devices. > > > Whew. That's a relief. At the moment, device registrations have to be > done from a process context. I've left this issue open. I may decide > to support this from interrupt contexts, but that would make things a > lot harder, and I'm undecided on whether that's a good idea. > We originally had it like that, but it's a whole lot cleaner and easier to code the hub control code when you can block until on a wait_queue or something similar. There's just too much state and creating weird asynchronous code to handle it all was more trouble than it's worth. JE From owner-devfs@oss.sgi.com Mon Apr 17 20:39:46 2000 Received: by oss.sgi.com id ; Mon, 17 Apr 2000 20:39:27 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:15240 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Mon, 17 Apr 2000 20:38:58 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e3I3cng27991; Mon, 17 Apr 2000 21:38:49 -0600 Date: Mon, 17 Apr 2000 21:38:49 -0600 Message-Id: <200004180338.e3I3cng27991@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: devfs@oss.sgi.com Subject: Re: devfs and USB In-Reply-To: <20000417200237.I14581@valinux.com> References: <20000328144530.Z860@valinux.com> <200004130453.e3D4r9F04628@vindaloo.ras.ucalgary.ca> <20000413115522.W14581@valinux.com> <200004152255.e3FMtG425171@vindaloo.ras.ucalgary.ca> <20000417120035.Y14581@valinux.com> <200004180236.e3I2aSo27324@vindaloo.ras.ucalgary.ca> <20000417194508.G14581@valinux.com> <200004180255.e3I2toJ27552@vindaloo.ras.ucalgary.ca> <20000417200237.I14581@valinux.com> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Johannes Erdfelt writes: > On Mon, Apr 17, 2000, Richard Gooch wrote: > > Johannes Erdfelt writes: > > > On Mon, Apr 17, 2000, Richard Gooch wrote: > > > > Hm. But is it quite like this? If you have a device with multiple > > > > interfaces, and multiple drivers get loaded, what's the interface to > > > > user-space? Do you have a single device node and multiplex that, or do > > > > you actually present multiple device nodes, with each hooked to a > > > > single driver? > > > > > > Right now, we have one node for the entire device and everything is > > > done via ioctl()'s. This isn't a good idea. I have a solution which > > > splits out everything into separate nodes, but I'm still > > > implementing some of it. > > > > Yeah, I think separate device nodes would be cleaner. Now, if you do > > that, do you still need the user-space daemon talking via the > > dynamically created "generic" device node? Or can you just talk via a > > central device node for all USB devices? > > > > The PCMCIA code, for example, just as a central node/pipe which > > cardmgr talks to. Why can't you do it like that? > > This the same interface that user level drivers will use. > > We could use a central node/pipe, but we're gonna create the device > nodes anyway, so might as well use them. Why are you creating these "generic" device nodes anyway? What I'm basically trying to work out is why you can't have a central pipe which the daemon talks to, and when drivers attach to the interface, the daemon talks to the USB subsystem and does a mknod(2) as appropriate. This is the kind of argument the anti-devfs crowd will make. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Mon Apr 17 20:58:17 2000 Received: by oss.sgi.com id ; Mon, 17 Apr 2000 20:57:57 -0700 Received: from nat-su-33.valinux.com ([198.186.202.33]:37385 "EHLO phenoxide.su.varesearch.com") by oss.sgi.com with ESMTP id ; Mon, 17 Apr 2000 20:57:40 -0700 Received: (from jerdfelt@localhost) by phenoxide.su.varesearch.com (8.9.3/8.9.3) id UAA14382; Mon, 17 Apr 2000 20:57:39 -0700 Date: Mon, 17 Apr 2000 20:57:39 -0700 From: Johannes Erdfelt To: Richard Gooch Cc: devfs@oss.sgi.com Subject: Re: devfs and USB Message-ID: <20000417205739.A12513@valinux.com> References: <20000328144530.Z860@valinux.com> <200004130453.e3D4r9F04628@vindaloo.ras.ucalgary.ca> <20000413115522.W14581@valinux.com> <200004152255.e3FMtG425171@vindaloo.ras.ucalgary.ca> <20000417120035.Y14581@valinux.com> <200004180236.e3I2aSo27324@vindaloo.ras.ucalgary.ca> <20000417194508.G14581@valinux.com> <200004180255.e3I2toJ27552@vindaloo.ras.ucalgary.ca> <20000417200237.I14581@valinux.com> <200004180338.e3I3cng27991@vindaloo.ras.ucalgary.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200004180338.e3I3cng27991@vindaloo.ras.ucalgary.ca> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing On Mon, Apr 17, 2000, Richard Gooch wrote: > Johannes Erdfelt writes: > > On Mon, Apr 17, 2000, Richard Gooch wrote: > > > Johannes Erdfelt writes: > > > > On Mon, Apr 17, 2000, Richard Gooch wrote: > > > > > Hm. But is it quite like this? If you have a device with multiple > > > > > interfaces, and multiple drivers get loaded, what's the interface to > > > > > user-space? Do you have a single device node and multiplex that, or do > > > > > you actually present multiple device nodes, with each hooked to a > > > > > single driver? > > > > > > > > Right now, we have one node for the entire device and everything is > > > > done via ioctl()'s. This isn't a good idea. I have a solution which > > > > splits out everything into separate nodes, but I'm still > > > > implementing some of it. > > > > > > Yeah, I think separate device nodes would be cleaner. Now, if you do > > > that, do you still need the user-space daemon talking via the > > > dynamically created "generic" device node? Or can you just talk via a > > > central device node for all USB devices? > > > > > > The PCMCIA code, for example, just as a central node/pipe which > > > cardmgr talks to. Why can't you do it like that? > > > > This the same interface that user level drivers will use. > > > > We could use a central node/pipe, but we're gonna create the device > > nodes anyway, so might as well use them. > > Why are you creating these "generic" device nodes anyway? > > What I'm basically trying to work out is why you can't have a central > pipe which the daemon talks to, and when drivers attach to the > interface, the daemon talks to the USB subsystem and does a mknod(2) > as appropriate. This is the kind of argument the anti-devfs crowd will > make. Right now? major/minor issues. We don't have enough. The nodes I create are either too sparse or too many. No one seems interested in actually following through in increasing the major/minor for 2.4 and we need this working for 2.4. Even increasing the major/minor would be a band-aid solution. I'm much more content using a solution which is here today and IMHO a good solution. JE From owner-devfs@oss.sgi.com Mon Apr 17 21:15:17 2000 Received: by oss.sgi.com id ; Mon, 17 Apr 2000 21:14:57 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:18056 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Mon, 17 Apr 2000 21:14:29 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e3I4EOO28467; Mon, 17 Apr 2000 22:14:24 -0600 Date: Mon, 17 Apr 2000 22:14:24 -0600 Message-Id: <200004180414.e3I4EOO28467@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: devfs@oss.sgi.com Subject: Re: devfs and USB In-Reply-To: <20000417205739.A12513@valinux.com> References: <20000328144530.Z860@valinux.com> <200004130453.e3D4r9F04628@vindaloo.ras.ucalgary.ca> <20000413115522.W14581@valinux.com> <200004152255.e3FMtG425171@vindaloo.ras.ucalgary.ca> <20000417120035.Y14581@valinux.com> <200004180236.e3I2aSo27324@vindaloo.ras.ucalgary.ca> <20000417194508.G14581@valinux.com> <200004180255.e3I2toJ27552@vindaloo.ras.ucalgary.ca> <20000417200237.I14581@valinux.com> <200004180338.e3I3cng27991@vindaloo.ras.ucalgary.ca> <20000417205739.A12513@valinux.com> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Johannes Erdfelt writes: > On Mon, Apr 17, 2000, Richard Gooch wrote: > > What I'm basically trying to work out is why you can't have a central > > pipe which the daemon talks to, and when drivers attach to the > > interface, the daemon talks to the USB subsystem and does a mknod(2) > > as appropriate. This is the kind of argument the anti-devfs crowd will > > make. > > Right now? major/minor issues. > > We don't have enough. > > The nodes I create are either too sparse or too many. Is it possible to have the USB subsystem pick an unused minor, pass that over a new usbd protocol, and have the usbd daemon mknod(2) using that number? So unless you have >256 USB "interfaces" hooked in at once, you'll be OK. > No one seems interested in actually following through in increasing > the major/minor for 2.4 and we need this working for 2.4. IIRC, a bigger dev_t is a 2.5 issue. > Even increasing the major/minor would be a band-aid solution. In what way? > I'm much more content using a solution which is here today and IMHO > a good solution. I agree that devfs is overall cleaner:-) I'm just playing devil's advocate here so that the pro-devfs argument can be refined and sharpened. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Mon Apr 17 22:05:47 2000 Received: by oss.sgi.com id ; Mon, 17 Apr 2000 22:05:28 -0700 Received: from nat-su-33.valinux.com ([198.186.202.33]:62983 "EHLO phenoxide.su.varesearch.com") by oss.sgi.com with ESMTP id ; Mon, 17 Apr 2000 22:05:03 -0700 Received: (from jerdfelt@localhost) by phenoxide.su.varesearch.com (8.9.3/8.9.3) id WAA14432 for devfs@oss.sgi.com; Mon, 17 Apr 2000 22:04:58 -0700 Date: Mon, 17 Apr 2000 22:04:58 -0700 From: Johannes Erdfelt To: devfs@oss.sgi.com Subject: Re: devfs and USB Message-ID: <20000417220458.B12513@valinux.com> References: <20000413115522.W14581@valinux.com> <200004152255.e3FMtG425171@vindaloo.ras.ucalgary.ca> <20000417120035.Y14581@valinux.com> <200004180236.e3I2aSo27324@vindaloo.ras.ucalgary.ca> <20000417194508.G14581@valinux.com> <200004180255.e3I2toJ27552@vindaloo.ras.ucalgary.ca> <20000417200237.I14581@valinux.com> <200004180338.e3I3cng27991@vindaloo.ras.ucalgary.ca> <20000417205739.A12513@valinux.com> <200004180414.e3I4EOO28467@vindaloo.ras.ucalgary.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200004180414.e3I4EOO28467@vindaloo.ras.ucalgary.ca> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing On Mon, Apr 17, 2000, Richard Gooch wrote: > Johannes Erdfelt writes: > > Right now? major/minor issues. > > > > We don't have enough. > > > > The nodes I create are either too sparse or too many. > > Is it possible to have the USB subsystem pick an unused minor, pass > that over a new usbd protocol, and have the usbd daemon mknod(2) using > that number? So unless you have >256 USB "interfaces" hooked in at > once, you'll be OK. If you have one node per interface. The current patch I have is one node per endpoint. An endpoint is a further set of pipes to talk to the device. On the average device, there are 4 or 5 endpoints. Some have as little as 2. Some have as many as a couple of dozen. My development machine, which admitedly has more devices than the average person, would overflow 256 minors. Plus, there are different types of nodes. One which is for the main device, to get all of the cached descriptors for the device. (Some devices don't like being asked for the descriptors after being enumerated) It gets further complicated (which minor points what kind of node on which device, etc). > > No one seems interested in actually following through in increasing > > the major/minor for 2.4 and we need this working for 2.4. > > IIRC, a bigger dev_t is a 2.5 issue. Could be. I do remember seeing discussions a while ago, I do not know the current status, but this sounds accurate from people's attitudes towards doing it. > > Even increasing the major/minor would be a band-aid solution. > > In what way? Run out of numbers, make it bigger? I just have a fundamental problem with major/minor numbers. It's very inefficient method of communicating to the kernel which device you want. They are ill suited for today's OS' which handle Hot Swap devices. Back when Unix was designed and created, you didn't have Hot Swap devices so this wasn't a problem. Unfortunately for Unix, times change. Thankfully, we can change with it. Anything which increases major/minors, or dynamically assigned major/minors increases the complexity of the code needed to determine which minor goes to which device, and what part of the device. devfs centralizes that and keeps me, the subsystem, out of it. This is definately attractive to the lazy part of me :) I just don't see why we should pass a static number/cookie from the kernel to userspace. It's taking a step backwards. We already have a standard and useful interface to select the device we want, open(2). I think it's biggest piece of legacy baggage holding us back. Anything which uses major/minors and/or dynamically assigns them is band aid solution. > > I'm much more content using a solution which is here today and IMHO > > a good solution. > > I agree that devfs is overall cleaner:-) I'm just playing devil's > advocate here so that the pro-devfs argument can be refined and > sharpened. I understand. I'm just sick and tired of all of the arguments over it. So many people feel that devfs is not the correct soltion, but they never offer up what the correct solution may be. It works, with minimal overhead. I never expected to get extra features for free, but I think the ability to actually cope with Hot Swap devices at all, more than makes up for any extra minimal amount of memory used. Plus, getting rid of legacy baggage like major/minor is a net win IMO. No more worrying about changes in major/minor numbers. No more worrying about the code to convert minors into devices and what part of the devices. JE From owner-devfs@oss.sgi.com Mon Apr 17 22:48:52 2000 Received: by oss.sgi.com id ; Mon, 17 Apr 2000 22:48:33 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:22664 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Mon, 17 Apr 2000 22:48:04 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e3I5l2I29283; Mon, 17 Apr 2000 23:47:02 -0600 Date: Mon, 17 Apr 2000 23:47:02 -0600 Message-Id: <200004180547.e3I5l2I29283@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: linux-kernel@vger.rutgers.edu, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: devfsd-v1.3.4 available Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Hi, all. I've just released version 1.3.4 of my devfsd (devfs daemon) at: http://www.atnf.csiro.au/~rgooch/linux/ This work has been sponsored by SGI. This works with devfs-patch-v130 and devfs-patch-v99.7 (or later). The main changes are: - added "COPY" action. This is an important development, as it makes it easy to mirror permissions between two directory trees. No longer do you need the "tar kludge" or to write your own script called by devfsd to manage permissions. The "COPY" action does it all for you. And due to the regex engine, you can selectively decide what devices you want permission persistence for, and which you don't. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Mon Apr 17 23:01:53 2000 Received: by oss.sgi.com id ; Mon, 17 Apr 2000 23:01:33 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:23688 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Mon, 17 Apr 2000 23:01:04 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e3I612v29463; Tue, 18 Apr 2000 00:01:02 -0600 Date: Tue, 18 Apr 2000 00:01:02 -0600 Message-Id: <200004180601.e3I612v29463@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: devfs@oss.sgi.com Subject: Re: devfs and USB In-Reply-To: <20000417220458.B12513@valinux.com> References: <20000413115522.W14581@valinux.com> <200004152255.e3FMtG425171@vindaloo.ras.ucalgary.ca> <20000417120035.Y14581@valinux.com> <200004180236.e3I2aSo27324@vindaloo.ras.ucalgary.ca> <20000417194508.G14581@valinux.com> <200004180255.e3I2toJ27552@vindaloo.ras.ucalgary.ca> <20000417200237.I14581@valinux.com> <200004180338.e3I3cng27991@vindaloo.ras.ucalgary.ca> <20000417205739.A12513@valinux.com> <200004180414.e3I4EOO28467@vindaloo.ras.ucalgary.ca> <20000417220458.B12513@valinux.com> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Johannes Erdfelt writes: > On Mon, Apr 17, 2000, Richard Gooch wrote: > > Johannes Erdfelt writes: > > > Right now? major/minor issues. > > > > > > We don't have enough. > > > > > > The nodes I create are either too sparse or too many. > > > > Is it possible to have the USB subsystem pick an unused minor, pass > > that over a new usbd protocol, and have the usbd daemon mknod(2) using > > that number? So unless you have >256 USB "interfaces" hooked in at > > once, you'll be OK. > > If you have one node per interface. The current patch I have is one > node per endpoint. An endpoint is a further set of pipes to talk to > the device. > > On the average device, there are 4 or 5 endpoints. Some have as > little as 2. Some have as many as a couple of dozen. > > My development machine, which admitedly has more devices than the > average person, would overflow 256 minors. > > Plus, there are different types of nodes. One which is for the main > device, to get all of the cached descriptors for the device. (Some > devices don't like being asked for the descriptors after being > enumerated) > > It gets further complicated (which minor points what kind of node on > which device, etc). OK, so basically, to be able to support USB, we either need devfs, or we need much larger device numbers. With devfs, many things are made easy, without it, you have to jump through a lot of hoops to get things to work. I think I've got the bigger picture (USB-wise) now, thanks. So I guess the next question is how we proceed? Obviously, you're busy patching the USB subsystem. Are you using the void *private_data method of connecting device nodes to device instances? IOW, ignore major&minor numbers entirely and use the method I advocate in the devfs README? Is this done, or a work in progress? As far as the user-space component goes, you want to have an extension to devfsd. How do you see that being maintained and distributed? Your earlier patch stuck it into the devfsd source tree, but I wonder if that's the way you want to do it? My guess is that the USB extension will be changing a lot, as new devices are supported and you come up with better ways of doing things. If so, do you really want to have to go through me? BTW: how does usbdevfs tie into all this? Can we get rid of it and just use devfs instead? Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Mon Apr 17 23:15:22 2000 Received: by oss.sgi.com id ; Mon, 17 Apr 2000 23:15:12 -0700 Received: from nat-su-33.valinux.com ([198.186.202.33]:7431 "EHLO phenoxide.su.varesearch.com") by oss.sgi.com with ESMTP id ; Mon, 17 Apr 2000 23:14:56 -0700 Received: (from jerdfelt@localhost) by phenoxide.su.varesearch.com (8.9.3/8.9.3) id XAA14487; Mon, 17 Apr 2000 23:14:55 -0700 Date: Mon, 17 Apr 2000 23:14:55 -0700 From: Johannes Erdfelt To: Richard Gooch Cc: devfs@oss.sgi.com Subject: Re: devfs and USB Message-ID: <20000417231455.D12513@valinux.com> References: <20000417120035.Y14581@valinux.com> <200004180236.e3I2aSo27324@vindaloo.ras.ucalgary.ca> <20000417194508.G14581@valinux.com> <200004180255.e3I2toJ27552@vindaloo.ras.ucalgary.ca> <20000417200237.I14581@valinux.com> <200004180338.e3I3cng27991@vindaloo.ras.ucalgary.ca> <20000417205739.A12513@valinux.com> <200004180414.e3I4EOO28467@vindaloo.ras.ucalgary.ca> <20000417220458.B12513@valinux.com> <200004180601.e3I612v29463@vindaloo.ras.ucalgary.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200004180601.e3I612v29463@vindaloo.ras.ucalgary.ca> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing On Tue, Apr 18, 2000, Richard Gooch wrote: > Johannes Erdfelt writes: > > On Mon, Apr 17, 2000, Richard Gooch wrote: > > > Is it possible to have the USB subsystem pick an unused minor, pass > > > that over a new usbd protocol, and have the usbd daemon mknod(2) using > > > that number? So unless you have >256 USB "interfaces" hooked in at > > > once, you'll be OK. > > > > If you have one node per interface. The current patch I have is one > > node per endpoint. An endpoint is a further set of pipes to talk to > > the device. > > > > On the average device, there are 4 or 5 endpoints. Some have as > > little as 2. Some have as many as a couple of dozen. > > > > My development machine, which admitedly has more devices than the > > average person, would overflow 256 minors. > > > > Plus, there are different types of nodes. One which is for the main > > device, to get all of the cached descriptors for the device. (Some > > devices don't like being asked for the descriptors after being > > enumerated) > > > > It gets further complicated (which minor points what kind of node on > > which device, etc). > > OK, so basically, to be able to support USB, we either need devfs, or > we need much larger device numbers. With devfs, many things are made > easy, without it, you have to jump through a lot of hoops to get > things to work. Basically. If the VFS portion was not there, this could be made to work, but at the expense of lots hoops. > I think I've got the bigger picture (USB-wise) now, thanks. So I guess > the next question is how we proceed? > > Obviously, you're busy patching the USB subsystem. Are you using the > void *private_data method of connecting device nodes to device > instances? IOW, ignore major&minor numbers entirely and use the method > I advocate in the devfs README? Is this done, or a work in progress? Yup. We use private_data to point to a struct usb_device * or a struct usb_endpoint_descriptor * for instance. We have a separate set of file_operations for the different types of nodes we want. The original patch doesn't use character or block devices at all. I haven't found a reason to use them yet, so I haven't changed it. > As far as the user-space component goes, you want to have an extension > to devfsd. How do you see that being maintained and distributed? Your > earlier patch stuck it into the devfsd source tree, but I wonder if > that's the way you want to do it? My guess is that the USB extension > will be changing a lot, as new devices are supported and you come up > with better ways of doing things. If so, do you really want to have to > go through me? I'd suppose that keeping them separate would probably the best for now. Things will be changing rapidly and I don't want to burden the rest of devfs or devfsd with USB development for now. > BTW: how does usbdevfs tie into all this? Can we get rid of it and > just use devfs instead? That was the intention. The necessary support wasn't there that we needed, so we created it. devfs provides a super set of functionality that we need so making the change is not much of a problem. I was busy tracking down and fixing some other bugs today so I didn't get much time to actually work on the coding for moving the rest of the core to devfs, but work will continue. JE From owner-devfs@oss.sgi.com Mon Apr 17 23:28:22 2000 Received: by oss.sgi.com id ; Mon, 17 Apr 2000 23:28:02 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:25736 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Mon, 17 Apr 2000 23:27:34 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e3I6RVr29809; Tue, 18 Apr 2000 00:27:31 -0600 Date: Tue, 18 Apr 2000 00:27:31 -0600 Message-Id: <200004180627.e3I6RVr29809@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Johannes Erdfelt Cc: devfs@oss.sgi.com Subject: Re: devfs and USB In-Reply-To: <20000417231455.D12513@valinux.com> References: <20000417120035.Y14581@valinux.com> <200004180236.e3I2aSo27324@vindaloo.ras.ucalgary.ca> <20000417194508.G14581@valinux.com> <200004180255.e3I2toJ27552@vindaloo.ras.ucalgary.ca> <20000417200237.I14581@valinux.com> <200004180338.e3I3cng27991@vindaloo.ras.ucalgary.ca> <20000417205739.A12513@valinux.com> <200004180414.e3I4EOO28467@vindaloo.ras.ucalgary.ca> <20000417220458.B12513@valinux.com> <200004180601.e3I612v29463@vindaloo.ras.ucalgary.ca> <20000417231455.D12513@valinux.com> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Johannes Erdfelt writes: > On Tue, Apr 18, 2000, Richard Gooch wrote: > > I think I've got the bigger picture (USB-wise) now, thanks. So I guess > > the next question is how we proceed? > > > > Obviously, you're busy patching the USB subsystem. Are you using the > > void *private_data method of connecting device nodes to device > > instances? IOW, ignore major&minor numbers entirely and use the method > > I advocate in the devfs README? Is this done, or a work in progress? > > Yup. We use private_data to point to a struct usb_device * or a > struct usb_endpoint_descriptor * for instance. Really? I just did a scan of drivers/usb/ in 2.3.99-pre6-2 and I don't see you passing pointers to . In input.c all I see is a conventional driver with basic devfs support added. > We have a separate set of file_operations for the different types of > nodes we want. I only see &input_fops being passed (there's only one call to anyway:-). > > As far as the user-space component goes, you want to have an extension > > to devfsd. How do you see that being maintained and distributed? Your > > earlier patch stuck it into the devfsd source tree, but I wonder if > > that's the way you want to do it? My guess is that the USB extension > > will be changing a lot, as new devices are supported and you come up > > with better ways of doing things. If so, do you really want to have to > > go through me? > > I'd suppose that keeping them separate would probably the best for > now. Things will be changing rapidly and I don't want to burden the > rest of devfs or devfsd with USB development for now. Yeah, makes sense to me. Is there anything you need changed in devfsd? I'm hoping that the recent changes provide you all the hooks you need. > > BTW: how does usbdevfs tie into all this? Can we get rid of it and > > just use devfs instead? > > That was the intention. The necessary support wasn't there that we > needed, so we created it. devfs provides a super set of > functionality that we need so making the change is not much of a > problem. > > I was busy tracking down and fixing some other bugs today so I > didn't get much time to actually work on the coding for moving the > rest of the core to devfs, but work will continue. In the last email I had with Thomas Sailer, he didn't seem to think there was much advantage to using devfs, and he felt that there were special-purpose things needed for USB that wouldn't belong in devfs. BTW: do you prefer to be Cc'ed or not? I have duplicate filtering, so a second copy doesn't bother me;-) Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Tue Apr 18 09:08:28 2000 Received: by oss.sgi.com id ; Tue, 18 Apr 2000 09:08:18 -0700 Received: from nat-su-33.valinux.com ([198.186.202.33]:1550 "EHLO phenoxide.su.varesearch.com") by oss.sgi.com with ESMTP id ; Tue, 18 Apr 2000 09:07:59 -0700 Received: (from jerdfelt@localhost) by phenoxide.su.varesearch.com (8.9.3/8.9.3) id JAA14781 for devfs@oss.sgi.com; Tue, 18 Apr 2000 09:07:59 -0700 Date: Tue, 18 Apr 2000 09:07:59 -0700 From: Johannes Erdfelt To: devfs@oss.sgi.com Subject: Re: devfs and USB Message-ID: <20000418090759.E12513@valinux.com> References: <20000417194508.G14581@valinux.com> <200004180255.e3I2toJ27552@vindaloo.ras.ucalgary.ca> <20000417200237.I14581@valinux.com> <200004180338.e3I3cng27991@vindaloo.ras.ucalgary.ca> <20000417205739.A12513@valinux.com> <200004180414.e3I4EOO28467@vindaloo.ras.ucalgary.ca> <20000417220458.B12513@valinux.com> <200004180601.e3I612v29463@vindaloo.ras.ucalgary.ca> <20000417231455.D12513@valinux.com> <200004180627.e3I6RVr29809@vindaloo.ras.ucalgary.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200004180627.e3I6RVr29809@vindaloo.ras.ucalgary.ca> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing On Tue, Apr 18, 2000, Richard Gooch wrote: > Johannes Erdfelt writes: > > Yup. We use private_data to point to a struct usb_device * or a > > struct usb_endpoint_descriptor * for instance. > > Really? I just did a scan of drivers/usb/ in 2.3.99-pre6-2 and I don't > see you passing pointers to . In input.c all I see is > a conventional driver with basic devfs support added. Patches haven't been merged yet. Take a look at the patch I sent you. And those should be using pointers, but I haven't looked at how they are implemented. > > We have a separate set of file_operations for the different types of > > nodes we want. > > I only see &input_fops being passed (there's only one call to > anyway:-). See above. > > I'd suppose that keeping them separate would probably the best for > > now. Things will be changing rapidly and I don't want to burden the > > rest of devfs or devfsd with USB development for now. > > Yeah, makes sense to me. Is there anything you need changed in devfsd? > I'm hoping that the recent changes provide you all the hooks you need. That's most of it. The only other changes I need are things like exporting variables so SYSLOG will work, etc. > > That was the intention. The necessary support wasn't there that we > > needed, so we created it. devfs provides a super set of > > functionality that we need so making the change is not much of a > > problem. > > > > I was busy tracking down and fixing some other bugs today so I > > didn't get much time to actually work on the coding for moving the > > rest of the core to devfs, but work will continue. > > In the last email I had with Thomas Sailer, he didn't seem to think > there was much advantage to using devfs, and he felt that there were > special-purpose things needed for USB that wouldn't belong in devfs. I've talked to him and he hasn't told me why it's not possible to use devfs. He mentioned locking issues and race conditions once, but he hasn't expanded on it in multiple emails sent to him. So, if we can use devfs and remove all of the VFS specific code, we have a net win. Less code to maintain on our end. > BTW: do you prefer to be Cc'ed or not? I have duplicate filtering, so > a second copy doesn't bother me;-) I don't have duplicate filterings, but I can delete by hand, doesn't bother me much. I'm used to it on the rest of the lists I'm on. JE From owner-devfs@oss.sgi.com Tue Apr 18 15:48:29 2000 Received: by oss.sgi.com id ; Tue, 18 Apr 2000 15:48:20 -0700 Received: from nat-su-33.valinux.com ([198.186.202.33]:34835 "EHLO phenoxide.su.varesearch.com") by oss.sgi.com with ESMTP id ; Tue, 18 Apr 2000 15:47:54 -0700 Received: (from jerdfelt@localhost) by phenoxide.su.varesearch.com (8.9.3/8.9.3) id PAA15601 for devfs@oss.sgi.com; Tue, 18 Apr 2000 15:47:54 -0700 Date: Tue, 18 Apr 2000 15:47:54 -0700 From: Johannes Erdfelt To: devfs@oss.sgi.com Subject: devfsd and COPY Message-ID: <20000418154754.A15247@valinux.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing I noticed that COPY was a new feature in devfsd. I'd like to implement something similar for USB, but which tracks the device. Or, if the device is new (not previously known to be plugged into this system), could be given a default set of permissions based on configuration options. COPY unfortunately will make it difficult to track USB devices since the information tracked is the filename and it is store as a file. I guess the information could be encoded into a filename, but that starts getting ugly. I'd like to use a database (berkeley, gdbm, text, etc) to store the information necessary. Perhaps in addition to the current scheme of storing the information in the filesystem via a different tree. In most cases, we would use the serial number to track the device. I'd like to make it flexible enough to track based on vendor/product and possibly bus topology for those people who wish to use it. JE From owner-devfs@oss.sgi.com Tue Apr 18 16:42:00 2000 Received: by oss.sgi.com id ; Tue, 18 Apr 2000 16:41:51 -0700 Received: from nat-su-33.valinux.com ([198.186.202.33]:36107 "EHLO phenoxide.su.varesearch.com") by oss.sgi.com with ESMTP id ; Tue, 18 Apr 2000 16:41:34 -0700 Received: (from jerdfelt@localhost) by phenoxide.su.varesearch.com (8.9.3/8.9.3) id QAA15790 for devfs@oss.sgi.com; Tue, 18 Apr 2000 16:41:34 -0700 Date: Tue, 18 Apr 2000 16:41:34 -0700 From: Johannes Erdfelt To: devfs@oss.sgi.com Subject: [patch] fix crash with modules and tracing enabled Message-ID: <20000418164134.D15247@valinux.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="X1bOJ3K7DJ5YkBrT" X-Mailer: Mutt 1.0pre2i Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii entry->u.function.so was never set to anything, but when tracing was enabled, devfsd would try to dereference it to something for use in fprintf. This patch fixes the problem. JE --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="devfsd-so.patch" --- devfsd/devfsd.c Mon Apr 17 22:35:50 2000 +++ devfsd.je/devfsd.c Tue Apr 18 16:37:17 2000 @@ -656,6 +656,7 @@ p[0], dlerror () ); exit (1); } + new->u.function.so = so; if ( ( new->u.function.func.m = dlsym (so->handle,p[1]) ) == NULL ) { SYSLOG (LOG_ERR, "symbol: \"%s\" not found in %s\n", --X1bOJ3K7DJ5YkBrT-- From owner-devfs@oss.sgi.com Tue Apr 18 22:54:04 2000 Received: by oss.sgi.com id ; Tue, 18 Apr 2000 22:53:54 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:29578 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Tue, 18 Apr 2000 22:53:37 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e3J5rUu10968; Tue, 18 Apr 2000 23:53:30 -0600 Date: Tue, 18 Apr 2000 23:53:30 -0600 Message-Id: <200004190553.e3J5rUu10968@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: devfs@oss.sgi.com Subject: Re: devfs and USB In-Reply-To: <20000418090759.E12513@valinux.com> References: <20000417194508.G14581@valinux.com> <200004180255.e3I2toJ27552@vindaloo.ras.ucalgary.ca> <20000417200237.I14581@valinux.com> <200004180338.e3I3cng27991@vindaloo.ras.ucalgary.ca> <20000417205739.A12513@valinux.com> <200004180414.e3I4EOO28467@vindaloo.ras.ucalgary.ca> <20000417220458.B12513@valinux.com> <200004180601.e3I612v29463@vindaloo.ras.ucalgary.ca> <20000417231455.D12513@valinux.com> <200004180627.e3I6RVr29809@vindaloo.ras.ucalgary.ca> <20000418090759.E12513@valinux.com> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Johannes Erdfelt writes: > On Tue, Apr 18, 2000, Richard Gooch wrote: > > Johannes Erdfelt writes: > > > Yup. We use private_data to point to a struct usb_device * or a > > > struct usb_endpoint_descriptor * for instance. > > > > Really? I just did a scan of drivers/usb/ in 2.3.99-pre6-2 and I don't > > see you passing pointers to . In input.c all I see is > > a conventional driver with basic devfs support added. > > Patches haven't been merged yet. Take a look at the patch I sent > you. That only had patches to devfsd. I didn't see any kernel patches. > > > I'd suppose that keeping them separate would probably the best for > > > now. Things will be changing rapidly and I don't want to burden the > > > rest of devfs or devfsd with USB development for now. > > > > Yeah, makes sense to me. Is there anything you need changed in devfsd? > > I'm hoping that the recent changes provide you all the hooks you need. > > That's most of it. The only other changes I need are things like > exporting variables so SYSLOG will work, etc. OK, I've done that in my tree. I've made a devfsd.h file too. > > BTW: do you prefer to be Cc'ed or not? I have duplicate filtering, so > > a second copy doesn't bother me;-) > > I don't have duplicate filterings, but I can delete by hand, doesn't > bother me much. I'm used to it on the rest of the lists I'm on. I'll try to just post to the list then, but won't feel too guilty if I send two :-) Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Tue Apr 18 23:02:24 2000 Received: by oss.sgi.com id ; Tue, 18 Apr 2000 23:02:15 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:30090 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Tue, 18 Apr 2000 23:02:12 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e3J62AP11088; Wed, 19 Apr 2000 00:02:10 -0600 Date: Wed, 19 Apr 2000 00:02:10 -0600 Message-Id: <200004190602.e3J62AP11088@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: devfs@oss.sgi.com Subject: Re: devfsd and COPY In-Reply-To: <20000418154754.A15247@valinux.com> References: <20000418154754.A15247@valinux.com> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Johannes Erdfelt writes: > I noticed that COPY was a new feature in devfsd. > > I'd like to implement something similar for USB, but which tracks the > device. > > Or, if the device is new (not previously known to be plugged into > this system), could be given a default set of permissions based on > configuration options. You should already be able to do that with the PERMISSIONS action. With the regex engine, you should have a lot of flexibilty in managing permissions. I basically see PERMISSIONS as the preferred way of managing permissions for hot-plug devices. > COPY unfortunately will make it difficult to track USB devices since > the information tracked is the filename and it is store as a file. I didn't really see COPY as being all that useful for USB. I should point out that I see two distinct families of devices in devfs. The "classic" devices, which are pretty much static, and "dynamic" devices such as USB. For classic devices, most people want the old permissions semantics. Hence COPY. For dynamic devices, we really need a different mechanism, hence PERMISSIONS. > I'd like to use a database (berkeley, gdbm, text, etc) to store the > information necessary. Perhaps in addition to the current scheme of > storing the information in the filesystem via a different tree. How is PERMISSIONS insufficient for your needs? > In most cases, we would use the serial number to track the device. > > I'd like to make it flexible enough to track based on vendor/product > and possibly bus topology for those people who wish to use it. Is this perhaps USB-specific? If so, we could leave this to the USB extension for devfsd. This level of flexibility sounds quite complex, and I don't know if there is a generic scheme that could be applied. Also, I don't see the advantage of using a database, rather than just a directory tree. It seems to me that the hard part is in deciding what to store and "where", and in deciding what to extract. That's all policy, and is probably USB specific. The actual mechanisms for storing and extracting permissions would seem to be trivial. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Tue Apr 18 23:07:55 2000 Received: by oss.sgi.com id ; Tue, 18 Apr 2000 23:07:46 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:30858 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Tue, 18 Apr 2000 23:07:43 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e3J67gJ11193; Wed, 19 Apr 2000 00:07:42 -0600 Date: Wed, 19 Apr 2000 00:07:42 -0600 Message-Id: <200004190607.e3J67gJ11193@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: devfs@oss.sgi.com Subject: Re: [patch] fix crash with modules and tracing enabled In-Reply-To: <20000418164134.D15247@valinux.com> References: <20000418164134.D15247@valinux.com> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Johannes Erdfelt writes: > entry->u.function.so was never set to anything, but when tracing was > enabled, devfsd would try to dereference it to something for use in > fprintf. > > This patch fixes the problem. Wow. The new features are already being used. Good to see. I've done a slightly different patch (I've dropped the variable entirely). Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Tue Apr 18 23:11:15 2000 Received: by oss.sgi.com id ; Tue, 18 Apr 2000 23:11:06 -0700 Received: from nat-su-33.valinux.com ([198.186.202.33]:20243 "EHLO phenoxide.su.varesearch.com") by oss.sgi.com with ESMTP id ; Tue, 18 Apr 2000 23:10:52 -0700 Received: (from jerdfelt@localhost) by phenoxide.su.varesearch.com (8.9.3/8.9.3) id XAA16185; Tue, 18 Apr 2000 23:10:46 -0700 Date: Tue, 18 Apr 2000 23:10:46 -0700 From: Johannes Erdfelt To: Richard Gooch Cc: devfs@oss.sgi.com Subject: Re: devfsd and COPY Message-ID: <20000418231046.G12513@valinux.com> References: <20000418154754.A15247@valinux.com> <200004190602.e3J62AP11088@vindaloo.ras.ucalgary.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200004190602.e3J62AP11088@vindaloo.ras.ucalgary.ca> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing On Wed, Apr 19, 2000, Richard Gooch wrote: > Johannes Erdfelt writes: > > I noticed that COPY was a new feature in devfsd. > > > > I'd like to implement something similar for USB, but which tracks the > > device. > > > > Or, if the device is new (not previously known to be plugged into > > this system), could be given a default set of permissions based on > > configuration options. > > You should already be able to do that with the PERMISSIONS action. > With the regex engine, you should have a lot of flexibilty in managing > permissions. I basically see PERMISSIONS as the preferred way of > managing permissions for hot-plug devices. > > > COPY unfortunately will make it difficult to track USB devices since > > the information tracked is the filename and it is store as a file. > > I didn't really see COPY as being all that useful for USB. > > I should point out that I see two distinct families of devices in > devfs. The "classic" devices, which are pretty much static, and > "dynamic" devices such as USB. > > For classic devices, most people want the old permissions > semantics. Hence COPY. > > For dynamic devices, we really need a different mechanism, hence > PERMISSIONS. > > > I'd like to use a database (berkeley, gdbm, text, etc) to store the > > information necessary. Perhaps in addition to the current scheme of > > storing the information in the filesystem via a different tree. > > How is PERMISSIONS insufficient for your needs? > > > In most cases, we would use the serial number to track the device. > > > > I'd like to make it flexible enough to track based on vendor/product > > and possibly bus topology for those people who wish to use it. > > Is this perhaps USB-specific? If so, we could leave this to the USB > extension for devfsd. This level of flexibility sounds quite complex, > and I don't know if there is a generic scheme that could be applied. > > Also, I don't see the advantage of using a database, rather than just > a directory tree. It seems to me that the hard part is in deciding > what to store and "where", and in deciding what to extract. That's all > policy, and is probably USB specific. > > The actual mechanisms for storing and extracting permissions would > seem to be trivial. It's all dynamic. I'd rather not rewrite the config file with dynamically generated information. It could be specific to the module, but I suppose other systems will have similar issues. Firewire, hot plug PCI, etc. How do we want to handle USB specific options? For instance, the driver database (this is relatively static). The location of the device permissions tracking database. JE From owner-devfs@oss.sgi.com Tue Apr 18 23:20:16 2000 Received: by oss.sgi.com id ; Tue, 18 Apr 2000 23:20:06 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:31882 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Tue, 18 Apr 2000 23:19:52 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e3J6JoI11350; Wed, 19 Apr 2000 00:19:50 -0600 Date: Wed, 19 Apr 2000 00:19:50 -0600 Message-Id: <200004190619.e3J6JoI11350@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: devfs@oss.sgi.com Subject: Re: devfsd and COPY In-Reply-To: <20000418231046.G12513@valinux.com> References: <20000418154754.A15247@valinux.com> <200004190602.e3J62AP11088@vindaloo.ras.ucalgary.ca> <20000418231046.G12513@valinux.com> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Johannes Erdfelt writes: > On Wed, Apr 19, 2000, Richard Gooch wrote: > > Johannes Erdfelt writes: > > > I'd like to make it flexible enough to track based on vendor/product > > > and possibly bus topology for those people who wish to use it. > > > > Is this perhaps USB-specific? If so, we could leave this to the USB > > extension for devfsd. This level of flexibility sounds quite complex, > > and I don't know if there is a generic scheme that could be applied. > > > > Also, I don't see the advantage of using a database, rather than just > > a directory tree. It seems to me that the hard part is in deciding > > what to store and "where", and in deciding what to extract. That's all > > policy, and is probably USB specific. > > > > The actual mechanisms for storing and extracting permissions would > > seem to be trivial. > > It's all dynamic. I'd rather not rewrite the config file with > dynamically generated information. I'm not suggesting that. I'm just saying that I don't know if a database is better than using a directory tree. In any case, like I said, it seems the hard part is deciding what to store and where, not how to actually store something. > It could be specific to the module, but I suppose other systems will > have similar issues. Firewire, hot plug PCI, etc. True. I don't know how similar they will be, though. > How do we want to handle USB specific options? Depends on how complex the USB needs are. If the config file isn't flexible enough, then we can consider new (core) actions for it, provided they are reasonably generic. Otherwise, they belong in usb.so instead. > For instance, the driver database (this is relatively static). The > location of the device permissions tracking database. What exactly are these things? I don't have a clear picture of what you want to do, or what your vision of USB permissions persistence is, so I'm just groping in the dark here. It may be easier to talk on the telephone. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Tue Apr 18 23:48:26 2000 Received: by oss.sgi.com id ; Tue, 18 Apr 2000 23:48:16 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:36234 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Tue, 18 Apr 2000 23:47:53 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e3J6kmX11818; Wed, 19 Apr 2000 00:46:48 -0600 Date: Wed, 19 Apr 2000 00:46:48 -0600 Message-Id: <200004190646.e3J6kmX11818@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: linux-kernel@vger.rutgers.edu, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: devfsd-v1.3.5 available Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Hi, all. I've just released version 1.3.5 of my devfsd (devfs daemon) at: http://www.atnf.csiro.au/~rgooch/linux/ This work has been sponsored by SGI. This works with devfs-patch-v130 and devfs-patch-v99.7 (or later). The main changes are: - moved some things to header "devfsd.h" - removed special argument "ENTRY" and renamed "INFO" to "EVENT" for "CFUNCTION" action - bug fix in debug mode with shared objects. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Sat Apr 22 13:08:09 2000 Received: by oss.sgi.com id ; Sat, 22 Apr 2000 13:08:00 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:6799 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Sat, 22 Apr 2000 13:07:39 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e3MK76f15772; Sat, 22 Apr 2000 14:07:06 -0600 Date: Sat, 22 Apr 2000 14:07:06 -0600 Message-Id: <200004222007.e3MK76f15772@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Paul Jakma Cc: Khimenko Victor , dgilbert@interlog.com, linuxguy@directlink.net, devfs@oss.sgi.com Subject: Re: devfs + xinit Authentication error In-Reply-To: References: Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Paul Jakma writes: > On Thu, 2 Mar 2000, Khimenko Victor wrote: > > In Paul Jakma (paul@clubi.ie) wrote: > > On Wed, 1 Mar 2000, Douglas Gilbert wrote: > > > Exactly. And it's NOT what you want. > > > What's really needed is to fix the PAM securetty module. At the moment it > > won't parse full paths like /dev/vc/6 - which imo means pam securetty is > > broken. > > Oh, yeah. Of course PAM is broken. We need to embed telepathy in PAM > IMMEDEATELY ! > > :) > > Or you can fix PAM so it will use full name after THAT > -- cut -- > if ((tty = rindex(ttyn, '/'))) > ++tty; > else > tty = ttyn; > -- cut -- > snippet from login.c ? PAM module was NEVER supplied with full device name > to begin with. Add tiny patch to your login.c (from unix-utils) and stop > blaming the innocent PAM. > > sorry, i just presumed the brokenness was in PAM. thanks for pointing > the correct source of the problem. You should that submit that patch > to the utils-linux maintainer. Can someone tell me what the status of this is? Has util-linux been fixed (it's not obvious from the 2.10k HISTORY)? If not, what's the patch that needs to be applied? And who will step forward and push it to Andries? Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Sat Apr 22 13:18:50 2000 Received: by oss.sgi.com id ; Sat, 22 Apr 2000 13:18:40 -0700 Received: from t3-static3-206.adsl.directlink.net ([63.68.136.206]:37649 "HELO t3-static3-206.adsl.directlink.net") by oss.sgi.com with SMTP id ; Sat, 22 Apr 2000 13:18:18 -0700 Received: from directlink.net (reliant.home.pri [192.168.1.25]) by t3-static3-206.adsl.directlink.net (Postfix) with ESMTP id 76AA42F79; Sat, 22 Apr 2000 15:18:05 -0500 (CDT) Message-ID: <390208FD.A025CEF8@directlink.net> Date: Sat, 22 Apr 2000 15:18:05 -0500 From: Matthew Vanecek Organization: University of North Texas X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.3.99-pre5 i586) X-Accept-Language: en MIME-Version: 1.0 To: Richard Gooch Cc: Paul Jakma , Khimenko Victor , dgilbert@interlog.com, devfs@oss.sgi.com Subject: Re: devfs + xinit Authentication error References: <200004222007.e3MK76f15772@vindaloo.ras.ucalgary.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Richard Gooch wrote: > > Paul Jakma writes: > > On Thu, 2 Mar 2000, Khimenko Victor wrote: > > > > In Paul Jakma (paul@clubi.ie) wrote: > > > On Wed, 1 Mar 2000, Douglas Gilbert wrote: > > > > > > Exactly. And it's NOT what you want. > > > > > What's really needed is to fix the PAM securetty module. At the moment it > > > won't parse full paths like /dev/vc/6 - which imo means pam securetty is > > > broken. > > > > Oh, yeah. Of course PAM is broken. We need to embed telepathy in PAM > > IMMEDEATELY ! > > > > :) > > > > Or you can fix PAM so it will use full name after THAT > > -- cut -- > > if ((tty = rindex(ttyn, '/'))) > > ++tty; > > else > > tty = ttyn; > > -- cut -- > > snippet from login.c ? PAM module was NEVER supplied with full device name > > to begin with. Add tiny patch to your login.c (from unix-utils) and stop > > blaming the innocent PAM. > > > > sorry, i just presumed the brokenness was in PAM. thanks for pointing > > the correct source of the problem. You should that submit that patch > > to the utils-linux maintainer. > > Can someone tell me what the status of this is? Has util-linux been > fixed (it's not obvious from the 2.10k HISTORY)? If not, what's the > patch that needs to be applied? And who will step forward and push it > to Andries? > > Regards, > > Richard.... > Permanent: rgooch@atnf.csiro.au > Current: rgooch@ras.ucalgary.ca I have util-linux-2.10h-6 installed, and it seems to be working ok. I had to change my securetty and console.perms to vc/*, anyhow. -- Matthew Vanecek Visit my Website at http://mysite.directlink.net/linuxguy For answers type: perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);' ***************************************************************** For 93 million miles, there is nothing between the sun and my shadow except me. I'm always getting in the way of something... From owner-devfs@oss.sgi.com Sat Apr 22 13:35:00 2000 Received: by oss.sgi.com id ; Sat, 22 Apr 2000 13:34:50 -0700 Received: from firewall-in.sch57.msk.ru ([195.178.195.6]:36365 "EHLO dell.sch57.msk.ru") by oss.sgi.com with ESMTP id ; Sat, 22 Apr 2000 13:34:34 -0700 Received: from localhost (khim@localhost) by dell.sch57.msk.ru (8.8.8/8.8.8) with ESMTP id AAA29315; Sun, 23 Apr 2000 00:31:34 +0400 Date: Sun, 23 Apr 2000 00:31:34 +0400 (MSD) From: Khimenko Victor To: Richard Gooch cc: Paul Jakma , dgilbert@interlog.com, linuxguy@directlink.net, devfs@oss.sgi.com Subject: Re: devfs + xinit Authentication error In-Reply-To: <200004222007.e3MK76f15772@vindaloo.ras.ucalgary.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing On Sat, 22 Apr 2000, Richard Gooch wrote: > Paul Jakma writes: > > On Thu, 2 Mar 2000, Khimenko Victor wrote: > > > > In Paul Jakma (paul@clubi.ie) wrote: > > > On Wed, 1 Mar 2000, Douglas Gilbert wrote: > > > > > > Exactly. And it's NOT what you want. > > > > > What's really needed is to fix the PAM securetty module. At the moment it > > > won't parse full paths like /dev/vc/6 - which imo means pam securetty is > > > broken. > > > > Oh, yeah. Of course PAM is broken. We need to embed telepathy in PAM > > IMMEDEATELY ! > > > > :) > > > > Or you can fix PAM so it will use full name after THAT > > -- cut -- > > if ((tty = rindex(ttyn, '/'))) > > ++tty; > > else > > tty = ttyn; > > -- cut -- > > snippet from login.c ? PAM module was NEVER supplied with full device name > > to begin with. Add tiny patch to your login.c (from unix-utils) and stop > > blaming the innocent PAM. > > > > sorry, i just presumed the brokenness was in PAM. thanks for pointing > > the correct source of the problem. You should that submit that patch > > to the utils-linux maintainer. > > Can someone tell me what the status of this is? Has util-linux been > fixed (it's not obvious from the 2.10k HISTORY)? If not, what's the > patch that needs to be applied? And who will step forward and push it > to Andries? > It was applied in some 2.10 linux-utils ... Not remember which but latest ones should work just fine... Since it's tiny change I think it just not mentioned in HISTORY file... From owner-devfs@oss.sgi.com Sun Apr 23 14:14:21 2000 Received: by oss.sgi.com id ; Sun, 23 Apr 2000 14:14:11 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:11664 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Sun, 23 Apr 2000 14:14:01 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e3NLDVH21949; Sun, 23 Apr 2000 15:13:31 -0600 Date: Sun, 23 Apr 2000 15:13:31 -0600 Message-Id: <200004232113.e3NLDVH21949@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Matthew Vanecek Cc: Paul Jakma , Khimenko Victor , dgilbert@interlog.com, devfs@oss.sgi.com Subject: Re: devfs + xinit Authentication error In-Reply-To: <390208FD.A025CEF8@directlink.net> References: <200004222007.e3MK76f15772@vindaloo.ras.ucalgary.ca> <390208FD.A025CEF8@directlink.net> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Matthew Vanecek writes: > Richard Gooch wrote: > > Can someone tell me what the status of this is? Has util-linux been > > fixed (it's not obvious from the 2.10k HISTORY)? If not, what's the > > patch that needs to be applied? And who will step forward and push it > > to Andries? > > I have util-linux-2.10h-6 installed, and it seems to be working ok. I > had to change my securetty and console.perms to vc/*, anyhow. Khimenko Victor writes: > It was applied in some 2.10 linux-utils ... Not remember > which but latest ones should work just fine... Since it's tiny > change I think it just not mentioned in HISTORY file... Looks like we have disagreement. Victor: do you still need modified versions of /etc/securetty and console.perms? Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Sun Apr 23 16:09:42 2000 Received: by oss.sgi.com id ; Sun, 23 Apr 2000 16:09:32 -0700 Received: from firewall-in.sch57.msk.ru ([195.178.195.6]:18437 "EHLO dell.sch57.msk.ru") by oss.sgi.com with ESMTP id ; Sun, 23 Apr 2000 16:09:17 -0700 Received: from localhost (khim@localhost) by dell.sch57.msk.ru (8.8.8/8.8.8) with ESMTP id DAA06312; Mon, 24 Apr 2000 03:07:08 +0400 Date: Mon, 24 Apr 2000 03:07:07 +0400 (MSD) From: Khimenko Victor To: Richard Gooch cc: Matthew Vanecek , Paul Jakma , dgilbert@interlog.com, devfs@oss.sgi.com Subject: Re: devfs + xinit Authentication error In-Reply-To: <200004232113.e3NLDVH21949@vindaloo.ras.ucalgary.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing On Sun, 23 Apr 2000, Richard Gooch wrote: > Matthew Vanecek writes: > > Richard Gooch wrote: > > > Can someone tell me what the status of this is? Has util-linux been > > > fixed (it's not obvious from the 2.10k HISTORY)? If not, what's the > > > patch that needs to be applied? And who will step forward and push it > > > to Andries? > > > > I have util-linux-2.10h-6 installed, and it seems to be working ok. I > > had to change my securetty and console.perms to vc/*, anyhow. > > Khimenko Victor writes: > > It was applied in some 2.10 linux-utils ... Not remember > > which but latest ones should work just fine... Since it's tiny > > change I think it just not mentioned in HISTORY file... > > Looks like we have disagreement. Victor: do you still need modified > versions of /etc/securetty and console.perms? > No, if you are using devfsd and "old" names like /dev/tty1, /dev/ttyS0, etc. Yes, if you are modified /etc/initttab and switched to /dev/vc/1, /dev/tts/1, etc. But with old linux-utils (before 2.10d at least) you have no choice: old version will just use basename of device file for all checks (login from linux-utils is doing it before even calling pam!). So pam can not distinguish /dev/vc/1 and /dev/tts/1 : both are presented as just "1" to pam module. With my small fix (included in recent linux-utils) /dev/vc/1 will be presented to pam module as vc/1 while /dev/tts/1 will be presented as tts/1 and so pam can distinguish them. Of course tty1 and vc/1 are still different (pam is using file names, not device major/minor numbers or any AI). Problem was NOT with changes in /etc/securetty and console.perms : it was expected. What was NOT expected is that you can not make vc/1 allowed for root login and NOT make tts/1 allowed for root logon in the same time. THAT was problem. And it's fixed in recent linux-utils. From owner-devfs@oss.sgi.com Mon Apr 24 03:04:30 2000 Received: by oss.sgi.com id ; Mon, 24 Apr 2000 03:04:20 -0700 Received: from smtp-out.netactive.net ([196.22.160.30]:21519 "HELO smtp-out.netactive.net") by oss.sgi.com with SMTP id ; Mon, 24 Apr 2000 03:04:04 -0700 Received: (qmail 4466 invoked from network); 24 Apr 2000 10:08:18 -0000 Received: from ctpm34-225.netactive.co.za (HELO chippo.netactive.co.za) (root@196.22.170.225) by smtp-out.netactive.net with SMTP; 24 Apr 2000 10:08:18 -0000 Received: from netactive.co.za (IDENT:chippo@localhost.localdomain [127.0.0.1]) by chippo.netactive.co.za (8.9.3/8.8.7) with ESMTP id MAA02163 for ; Mon, 24 Apr 2000 12:03:57 +0200 Message-ID: <39041C0D.DEE13149@netactive.co.za> Date: Mon, 24 Apr 2000 12:03:57 +0200 From: Chris the Elder X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: devfs@oss.sgi.com Subject: network cards, loadable modules, and 3dfx.o Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Hi all, While converting my machine to devfs, I've had a few problems. The most important one is that I can't find the device entry for my ethernet card. Where in /dev will the entry be? The 3c905 driver is built in (not module). A slightly related wierdness, is that since converting to devfs, the kernel doesn't print anthing about the enet card during the boot. The /usr/src/linux/Documentation/filesystems/devfs/README doesn't mention network devices. Since I've got 128M memory, I have no real need to have everything compiled as modules, but I also would expect devfs to work fine with modules. I was unable to mount my cdrom drive while it was built as a module. Prior to converting to devfs this worked fine. It works fine with the cdrom driver built into the kernel. My /etc/fstab reads: /dev/cdrom /cdrom iso9660 noauto,user,exec,ro 0 0 My /etc/devfsd.conf reads: REGISTER cdroms/cdrom0 CFUNCTION GLOBAL symlink $devname cdrom UNREGISTER cdroms/cdrom0 CFUNCTION GLOBAL unlink cdrom What should I be doing to mount CDs with the cdrom built as a module? Finally, I posted a question about the 3dfx driver and devfs on the kernel mailing list, which several of you saw. Jim Radford replied to me and told me that what I needed to do was add: LOOKUP 3dfx EXECUTE /bin/mknod $devpath c 107 0 to my devfsd.conf. I haven't got this to work yet, but I think that it is a permissions problem at this stage. The patches I was referring to, are the (probably non-existent) patches to apply to make 3dfx register with devfs. Cheers, chippo From owner-devfs@oss.sgi.com Mon Apr 24 03:52:10 2000 Received: by oss.sgi.com id ; Mon, 24 Apr 2000 03:52:01 -0700 Received: from smtp-out.netactive.net ([196.22.160.30]:39954 "HELO smtp-out.netactive.net") by oss.sgi.com with SMTP id ; Mon, 24 Apr 2000 03:51:40 -0700 Received: (qmail 5733 invoked from network); 24 Apr 2000 10:55:52 -0000 Received: from ctpm33-38.netactive.co.za (HELO chippo.netactive.co.za) (root@196.22.170.38) by smtp-out.netactive.net with SMTP; 24 Apr 2000 10:55:52 -0000 Received: from netactive.co.za (IDENT:chippo@localhost.localdomain [127.0.0.1]) by chippo.netactive.co.za (8.9.3/8.8.7) with ESMTP id MAA02383 for ; Mon, 24 Apr 2000 12:51:30 +0200 Message-ID: <39042732.81756259@netactive.co.za> Date: Mon, 24 Apr 2000 12:51:30 +0200 From: Chris the Elder X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: devfs@oss.sgi.com Subject: glibc-2.1.2 UNIX98 pty bug exposed by devfs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Howdy, I just spend many hours battling with a glibc-2.1.2 bug (before I knew about the bug). The symptoms are that after switching to devfs, gnome-terms don't get a shell prompt, and you get error dialogs, telling you that you need to configure your ptys correctly. The bug was discovered by the Rock linux distro. AFAIK, they are the only distro that uses devfs. The bug is fixed in glibc-2.1.3. I downloaded glibc-2.1.3-16.i386.rpm from one of the rawhide mirrors, but sources are also available from Ulrich's ftp site at cygnus. I think that this problem should be mentioned in the /usr/src/linux/Documentation/filesystems/devfs/README. Cheers, chippo From owner-devfs@oss.sgi.com Mon Apr 24 08:46:52 2000 Received: by oss.sgi.com id ; Mon, 24 Apr 2000 08:46:43 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:39202 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 24 Apr 2000 08:46:22 -0700 Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA24492 for ; Mon, 24 Apr 2000 08:41:35 -0700 (PDT) mail_from (tduffy@dbear.engr.sgi.com) Received: from dbear.engr.sgi.com (dbear.engr.sgi.com [163.154.18.85]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id IAA62962; Mon, 24 Apr 2000 08:46:02 -0700 (PDT) mail_from (tduffy@dbear.engr.sgi.com) Received: from localhost (tduffy@localhost) by dbear.engr.sgi.com (8.9.3/8.8.7) with ESMTP id IAA15072; Mon, 24 Apr 2000 08:45:25 -0700 Date: Mon, 24 Apr 2000 08:45:25 -0700 (PDT) From: Thomas Duffy To: Chris the Elder cc: devfs@oss.sgi.com Subject: Re: network cards, loadable modules, and 3dfx.o In-Reply-To: <39041C0D.DEE13149@netactive.co.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing > The most important one is that I can't find the device entry for > my ethernet card. Where in /dev will the entry be? The 3c905 > driver is built in (not module). A slightly related wierdness, is > that since converting to devfs, the kernel doesn't print anthing > about the enet card during the boot. The > /usr/src/linux/Documentation/filesystems/devfs/README > doesn't mention network devices. I am pretty sure that ethernet devices have never been present in the device filesystem. The name "eth0" or such is used by route and others as a symbol to direct the kernel to use which ethernet device, but it will not be in the /dev system. -tduffy From owner-devfs@oss.sgi.com Mon Apr 24 11:10:32 2000 Received: by oss.sgi.com id ; Mon, 24 Apr 2000 11:10:13 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:21649 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Mon, 24 Apr 2000 11:10:00 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e3OI9rk30940; Mon, 24 Apr 2000 12:09:53 -0600 Date: Mon, 24 Apr 2000 12:09:53 -0600 Message-Id: <200004241809.e3OI9rk30940@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: devfs@oss.sgi.com Subject: Re: network cards, loadable modules, and 3dfx.o In-Reply-To: <39041C0D.DEE13149@netactive.co.za> References: <39041C0D.DEE13149@netactive.co.za> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Chris the Elder writes: > The most important one is that I can't find the device entry for > my ethernet card. Where in /dev will the entry be? The 3c905 > driver is built in (not module). A slightly related wierdness, is > that since converting to devfs, the kernel doesn't print anthing > about the enet card during the boot. The > /usr/src/linux/Documentation/filesystems/devfs/README > doesn't mention network devices. That README is rapidly getting out of date. I've been working on a new FAQ which is much better. The answer to your question is in there. http://www.atnf.csiro.au/~rgooch/linux/docs/devfs.html > Since I've got 128M memory, I have no real need to have > everything compiled as modules, but I also would expect devfs > to work fine with modules. I was unable to mount my cdrom > drive while it was built as a module. Prior to converting to > devfs this worked fine. It works fine with the cdrom driver built > into the kernel. My /etc/fstab reads: > /dev/cdrom /cdrom iso9660 noauto,user,exec,ro 0 0 > My /etc/devfsd.conf reads: > REGISTER cdroms/cdrom0 CFUNCTION GLOBAL symlink $devname cdrom > UNREGISTER cdroms/cdrom0 CFUNCTION GLOBAL unlink cdrom > > What should I be doing to mount CDs with the cdrom built as > a module? Have you loaded the appropriate modules? Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Mon Apr 24 11:11:12 2000 Received: by oss.sgi.com id ; Mon, 24 Apr 2000 11:11:02 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:22161 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Mon, 24 Apr 2000 11:10:51 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e3OIAfc30986; Mon, 24 Apr 2000 12:10:41 -0600 Date: Mon, 24 Apr 2000 12:10:41 -0600 Message-Id: <200004241810.e3OIAfc30986@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: devfs@oss.sgi.com Subject: Re: glibc-2.1.2 UNIX98 pty bug exposed by devfs In-Reply-To: <39042732.81756259@netactive.co.za> References: <39042732.81756259@netactive.co.za> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Chris the Elder writes: > Howdy, > > I just spend many hours battling with a glibc-2.1.2 bug (before > I knew about the bug). > > The symptoms are that after switching to devfs, gnome-terms > don't get a shell prompt, and you get error dialogs, telling you > that you need to configure your ptys correctly. > > The bug was discovered by the Rock linux distro. AFAIK, they > are the only distro that uses devfs. The bug is fixed in > glibc-2.1.3. I downloaded glibc-2.1.3-16.i386.rpm from one of > the rawhide mirrors, but sources are also available from Ulrich's > ftp site at cygnus. > > I think that this problem should be mentioned in the > /usr/src/linux/Documentation/filesystems/devfs/README. It's documented in the new FAQ: http://www.atnf.csiro.au/~rgooch/linux/docs/devfs.html Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Mon Apr 24 20:39:52 2000 Received: by oss.sgi.com id ; Mon, 24 Apr 2000 20:39:33 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:50834 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Mon, 24 Apr 2000 20:39:09 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e3P3d3a01645; Mon, 24 Apr 2000 21:39:03 -0600 Date: Mon, 24 Apr 2000 21:39:03 -0600 Message-Id: <200004250339.e3P3d3a01645@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: devfs@oss.sgi.com Subject: [OT] HTML -> ASCII translator Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Hi, all. I'd like to include my new HTML FAQ in the kernel source tree, but I'd rather not put HTML in there (I feel that the kernel documentation should be readable without a browser). If anyone knows of a handy HTML -> ASCII translator that I could use for this task, please let me know. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Mon Apr 24 21:39:22 2000 Received: by oss.sgi.com id ; Mon, 24 Apr 2000 21:39:12 -0700 Received: from cx745293-b.elcjn1.sdca.home.com ([24.13.28.202]:2052 "EHLO cassini.us.mandrakesoft.com") by oss.sgi.com with ESMTP id ; Mon, 24 Apr 2000 21:38:51 -0700 Received: (from chmou@localhost) by cassini.us.mandrakesoft.com (8.9.3/8.8.7/Chmouel Boudjnah - Sendmail - 04/12/98) id OAA00857; Mon, 24 Apr 2000 14:36:45 -0700 X-Authentication-Warning: cassini.us.mandrakesoft.com: chmou set sender to chmouel@mandrakesoft.com using -f To: Richard Gooch Cc: devfs@oss.sgi.com Subject: Re: [OT] HTML -> ASCII translator References: <200004250339.e3P3d3a01645@vindaloo.ras.ucalgary.ca> From: Chmouel Boudjnah Date: 24 Apr 2000 14:36:45 -0700 In-Reply-To: Richard Gooch's message of "Mon, 24 Apr 2000 21:39:03 -0600" Message-ID: Lines: 15 User-Agent: Gnus/5.0805 (Gnus v5.8.5) Emacs/20.5 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Richard Gooch writes: > Hi, all. I'd like to include my new HTML FAQ in the kernel source > tree, but I'd rather not put HTML in there (I feel that the kernel > documentation should be readable without a browser). > > If anyone knows of a handy HTML -> ASCII translator that I could use > for this task, please let me know. -$ lynx -dump ? -- MandrakeSoft Inc http://www.mandrakesoft.com San-Diego, CA USA. --Chmouel From owner-devfs@oss.sgi.com Mon Apr 24 21:41:22 2000 Received: by oss.sgi.com id ; Mon, 24 Apr 2000 21:41:03 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:54930 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Mon, 24 Apr 2000 21:40:50 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e3P4ehl02291; Mon, 24 Apr 2000 22:40:43 -0600 Date: Mon, 24 Apr 2000 22:40:43 -0600 Message-Id: <200004250440.e3P4ehl02291@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Chmouel Boudjnah Cc: devfs@oss.sgi.com Subject: Re: [OT] HTML -> ASCII translator In-Reply-To: References: <200004250339.e3P3d3a01645@vindaloo.ras.ucalgary.ca> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Chmouel Boudjnah writes: > Richard Gooch writes: > > > Hi, all. I'd like to include my new HTML FAQ in the kernel source > > tree, but I'd rather not put HTML in there (I feel that the kernel > > documentation should be readable without a browser). > > > > If anyone knows of a handy HTML -> ASCII translator that I could use > > for this task, please let me know. > > -$ lynx -dump ? I was afraid of that answer. I don't have it installed. Sigh. Hopefully it's not too hard to build (and lean). I was hoping for a simple perl script. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Mon Apr 24 21:49:02 2000 Received: by oss.sgi.com id ; Mon, 24 Apr 2000 21:48:52 -0700 Received: from cx745293-b.elcjn1.sdca.home.com ([24.13.28.202]:14852 "EHLO cassini.us.mandrakesoft.com") by oss.sgi.com with ESMTP id ; Mon, 24 Apr 2000 21:48:35 -0700 Received: (from chmou@localhost) by cassini.us.mandrakesoft.com (8.9.3/8.8.7/Chmouel Boudjnah - Sendmail - 04/12/98) id OAA00996; Mon, 24 Apr 2000 14:46:11 -0700 X-Authentication-Warning: cassini.us.mandrakesoft.com: chmou set sender to chmouel@mandrakesoft.com using -f To: Richard Gooch Cc: Chmouel Boudjnah , devfs@oss.sgi.com Subject: Re: [OT] HTML -> ASCII translator References: <200004250339.e3P3d3a01645@vindaloo.ras.ucalgary.ca> <200004250440.e3P4ehl02291@vindaloo.ras.ucalgary.ca> From: Chmouel Boudjnah Date: 24 Apr 2000 14:46:11 -0700 In-Reply-To: Richard Gooch's message of "Mon, 24 Apr 2000 22:40:43 -0600" Message-ID: Lines: 31 User-Agent: Gnus/5.0805 (Gnus v5.8.5) Emacs/20.5 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Richard Gooch writes: > Chmouel Boudjnah writes: > > Richard Gooch writes: > > > > > Hi, all. I'd like to include my new HTML FAQ in the kernel source > > > tree, but I'd rather not put HTML in there (I feel that the kernel > > > documentation should be readable without a browser). > > > > > > If anyone knows of a handy HTML -> ASCII translator that I could use > > > for this task, please let me know. > > > > -$ lynx -dump ? > > I was afraid of that answer. I don't have it installed. Sigh. > Hopefully it's not too hard to build (and lean). I was hoping for a > simple perl script. what do you think about this : http://h82.ryd.student.liu.se/pub/programs/txt2html/ or this : http://www.aigeek.com/txt2html/ let me know if you want a lynx -dump version -- MandrakeSoft Inc http://www.mandrakesoft.com San-Diego, CA USA. --Chmouel From owner-devfs@oss.sgi.com Mon Apr 24 21:51:12 2000 Received: by oss.sgi.com id ; Mon, 24 Apr 2000 21:51:02 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:56978 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Mon, 24 Apr 2000 21:50:53 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e3P4olE02517; Mon, 24 Apr 2000 22:50:47 -0600 Date: Mon, 24 Apr 2000 22:50:47 -0600 Message-Id: <200004250450.e3P4olE02517@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Chmouel Boudjnah Cc: devfs@oss.sgi.com Subject: Re: [OT] HTML -> ASCII translator In-Reply-To: References: <200004250339.e3P3d3a01645@vindaloo.ras.ucalgary.ca> <200004250440.e3P4ehl02291@vindaloo.ras.ucalgary.ca> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Chmouel Boudjnah writes: > what do you think about this : > > http://h82.ryd.student.liu.se/pub/programs/txt2html/ > > or this : > > http://www.aigeek.com/txt2html/ They go the wrong way! I want HTML->txt. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Mon Apr 24 22:11:24 2000 Received: by oss.sgi.com id ; Mon, 24 Apr 2000 22:11:05 -0700 Received: from cx745293-b.elcjn1.sdca.home.com ([24.13.28.202]:42756 "EHLO cassini.us.mandrakesoft.com") by oss.sgi.com with ESMTP id ; Mon, 24 Apr 2000 22:10:35 -0700 Received: (from chmou@localhost) by cassini.us.mandrakesoft.com (8.9.3/8.8.7/Chmouel Boudjnah - Sendmail - 04/12/98) id PAA01215; Mon, 24 Apr 2000 15:08:27 -0700 X-Authentication-Warning: cassini.us.mandrakesoft.com: chmou set sender to chmouel@mandrakesoft.com using -f To: Richard Gooch Cc: Chmouel Boudjnah , devfs@oss.sgi.com Subject: Re: [OT] HTML -> ASCII translator References: <200004250339.e3P3d3a01645@vindaloo.ras.ucalgary.ca> <200004250440.e3P4ehl02291@vindaloo.ras.ucalgary.ca> <200004250450.e3P4olE02517@vindaloo.ras.ucalgary.ca> From: Chmouel Boudjnah Date: 24 Apr 2000 15:08:27 -0700 In-Reply-To: Richard Gooch's message of "Mon, 24 Apr 2000 22:50:47 -0600" Message-ID: Lines: 42 User-Agent: Gnus/5.0805 (Gnus v5.8.5) Emacs/20.5 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Richard Gooch writes: > Chmouel Boudjnah writes: > > what do you think about this : > > > > http://h82.ryd.student.liu.se/pub/programs/txt2html/ > > > > or this : > > > > http://www.aigeek.com/txt2html/ > > They go the wrong way! I want HTML->txt. oops sorry so i guess finally this one should do what you want: --=-=-= Title: UnHTML Version: 1.5 Entered-date: 8 JUNE 1996 Description: UnHTML is a utility that removes unwanted HTML ASCII files. Oftentimes, one wants to get rid o a document that contains useful or interesting UnHTML should be used to avoid the tedious task many html tags by hand, using a text editor. UnHTML produces better output than similar util as html-stripper. In addition, UnHTML can inter an editor (e.g. Pico) to manually edit the outp Keywords: html, strip, text, util, unhtml Author: Jawed Karim Maintained-by: Jawed Karim Primary-site: ftp://sunsite.unc.edu/pub/Linux/utils/text Alternate-site: http://umn.edu/~kari0022 Platforms: Linux ELF Copying-policy: Freeware --=-=-= ftp://metalab.unc.edu/pub/linux/utils/text/unhtml-v1.5.tar.gz -- MandrakeSoft Inc http://www.mandrakesoft.com San-Diego, CA USA. --Chmouel From owner-devfs@oss.sgi.com Mon Apr 24 22:24:24 2000 Received: by oss.sgi.com id ; Mon, 24 Apr 2000 22:24:15 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:61330 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Mon, 24 Apr 2000 22:23:53 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e3P5Nlh02989; Mon, 24 Apr 2000 23:23:47 -0600 Date: Mon, 24 Apr 2000 23:23:47 -0600 Message-Id: <200004250523.e3P5Nlh02989@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Chmouel Boudjnah Cc: devfs@oss.sgi.com Subject: Re: [OT] HTML -> ASCII translator In-Reply-To: References: <200004250339.e3P3d3a01645@vindaloo.ras.ucalgary.ca> <200004250440.e3P4ehl02291@vindaloo.ras.ucalgary.ca> <200004250450.e3P4olE02517@vindaloo.ras.ucalgary.ca> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Chmouel Boudjnah writes: > oops sorry so i guess finally this one should do what you want: > > --=-=-= > Title: UnHTML > > ftp://metalab.unc.edu/pub/linux/utils/text/unhtml-v1.5.tar.gz It eats most of my document! And it's a binary! What's a binary-only package doing on metalab?!? Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Mon Apr 24 22:38:25 2000 Received: by oss.sgi.com id ; Mon, 24 Apr 2000 22:38:05 -0700 Received: from cx745293-b.elcjn1.sdca.home.com ([24.13.28.202]:63748 "EHLO cassini.us.mandrakesoft.com") by oss.sgi.com with ESMTP id ; Mon, 24 Apr 2000 22:38:00 -0700 Received: (from chmou@localhost) by cassini.us.mandrakesoft.com (8.9.3/8.8.7/Chmouel Boudjnah - Sendmail - 04/12/98) id PAA01548; Mon, 24 Apr 2000 15:35:26 -0700 X-Authentication-Warning: cassini.us.mandrakesoft.com: chmou set sender to chmouel@mandrakesoft.com using -f To: Richard Gooch Cc: Chmouel Boudjnah , devfs@oss.sgi.com Subject: Re: [OT] HTML -> ASCII translator References: <200004250339.e3P3d3a01645@vindaloo.ras.ucalgary.ca> <200004250440.e3P4ehl02291@vindaloo.ras.ucalgary.ca> <200004250450.e3P4olE02517@vindaloo.ras.ucalgary.ca> <200004250523.e3P5Nlh02989@vindaloo.ras.ucalgary.ca> From: Chmouel Boudjnah Date: 24 Apr 2000 15:35:26 -0700 In-Reply-To: Richard Gooch's message of "Mon, 24 Apr 2000 23:23:47 -0600" Message-ID: Lines: 15 User-Agent: Gnus/5.0805 (Gnus v5.8.5) Emacs/20.5 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Richard Gooch writes: > It eats most of my document! argh. > And it's a binary! What's a binary-only package doing on metalab?!? doble argh, i send a email to the ftpmaster, ok finally maybe this : ftp://ftp.debian.org/debian/dists/woody/main/source/text/unhtml_2.2.orig.tar.gz -- MandrakeSoft Inc http://www.mandrakesoft.com San-Diego, CA USA. --Chmouel From owner-devfs@oss.sgi.com Mon Apr 24 23:49:45 2000 Received: by oss.sgi.com id ; Mon, 24 Apr 2000 23:49:25 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:8595 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Mon, 24 Apr 2000 23:48:57 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e3P6m9L04415; Tue, 25 Apr 2000 00:48:09 -0600 Date: Tue, 25 Apr 2000 00:48:09 -0600 Message-Id: <200004250648.e3P6m9L04415@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: linux-kernel@vger.rutgers.edu, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: [PATCH] devfs v163 available Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Hi, all. Version 163 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. This work has been sponsored by SGI. NOTE: there is a whole new FAQ for devfs which is bigger and better: http://www.atnf.csiro.au/~rgooch/linux/docs/devfs.html I've put a lot of work into fixing the deficiencies in the previous one. I hope it shows :-) This is against 2.3.99-pre6-6. Highlights of this release: - Don't create missing directories in - Removed Documentation/filesystems/devfs/mk-devlinks - Updated Documentation/filesystems/devfs/README Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Tue Apr 25 01:19:45 2000 Received: by oss.sgi.com id ; Tue, 25 Apr 2000 01:19:36 -0700 Received: from smtp-out.netactive.net ([196.22.160.30]:33032 "HELO smtp-out.netactive.net") by oss.sgi.com with SMTP id ; Tue, 25 Apr 2000 01:19:26 -0700 Received: (qmail 27479 invoked from network); 25 Apr 2000 08:23:32 -0000 Received: from ctpm33-54.netactive.co.za (HELO chippo.netactive.co.za) (root@196.22.170.54) by smtp-out.netactive.net with SMTP; 25 Apr 2000 08:23:32 -0000 Received: from netactive.co.za (IDENT:chippo@localhost.localdomain [127.0.0.1]) by chippo.netactive.co.za (8.9.3/8.8.7) with ESMTP id KAA02937; Tue, 25 Apr 2000 10:18:41 +0200 Message-ID: <390554E1.7D045D24@netactive.co.za> Date: Tue, 25 Apr 2000 10:18:41 +0200 From: Chris the Elder X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: Richard Gooch CC: devfs@oss.sgi.com Subject: Re: [OT] HTML -> ASCII translator References: <200004250339.e3P3d3a01645@vindaloo.ras.ucalgary.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Richard Gooch wrote: > Hi, all. I'd like to include my new HTML FAQ in the kernel source > tree, but I'd rather not put HTML in there (I feel that the kernel > documentation should be readable without a browser). > > If anyone knows of a handy HTML -> ASCII translator that I could use > for this task, please let me know. I hope you find the right tool, so that if future there won't be any work when you update one document. However, in the meantime, X cut'n'paste from netscape into vi does an acceptable job. Cheers, chippo BTW, I found and read the on-line FAQ, and was considerably happier than when I thought that the README was the official doc. From owner-devfs@oss.sgi.com Tue Apr 25 01:40:45 2000 Received: by oss.sgi.com id ; Tue, 25 Apr 2000 01:40:35 -0700 Received: from smtp-out.netactive.net ([196.22.160.30]:32527 "HELO smtp-out.netactive.net") by oss.sgi.com with SMTP id ; Tue, 25 Apr 2000 01:40:23 -0700 Received: (qmail 30044 invoked from network); 25 Apr 2000 08:44:33 -0000 Received: from ctpm33-54.netactive.co.za (HELO chippo.netactive.co.za) (root@196.22.170.54) by smtp-out.netactive.net with SMTP; 25 Apr 2000 08:44:33 -0000 Received: from netactive.co.za (IDENT:chippo@localhost.localdomain [127.0.0.1]) by chippo.netactive.co.za (8.9.3/8.8.7) with ESMTP id KAA02989 for ; Tue, 25 Apr 2000 10:40:13 +0200 Message-ID: <390559ED.890F06D0@netactive.co.za> Date: Tue, 25 Apr 2000 10:40:13 +0200 From: Chris the Elder X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: devfs@oss.sgi.com Subject: module autoloading Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Howdy, I've come a long way since my last (rather lost) email. I'm now wondering why I need various lines in devfsd.conf to get the correct modules loaded. My /etc/conf.modules looks like this: (BTW, in the on-line FAQ, at one point this is called /etc/modules.conf) -------------------------------- alias char-major-107 3dfx alias parport_lowlevel parport_pc alias eth0 3c59x alias gen_sound es1371 # Generic section: do not change # Soundcard alias /dev/sound gen_sound alias /dev/audio gen_sound alias /dev/mixer gen_sound [ ----- most of this file (which is distributed with devfs snipped) ----- ] alias /dev/stdout off alias /dev/stderr off ------------------------------- Now the docs indicate that this is what I need to make module autoloading work. However, it doesn't. I have autoloading working, but I had to edit devfsd.conf to organise this. Here is what I did. ------------------------------- REGISTER .* MKOLDCOMPAT UNREGISTER .* RMOLDCOMPAT LOOKUP mixer MODLOAD LOOKUP ttyS0 MODLOAD LOOKUP lp0 MODLOAD LOOKUP ide/cd/c0b1t0u0 MODLOAD LOOKUP 3dfx EXECUTE /bin/mknod $devpath c 107 0 REGISTER misc/psaux CFUNCTION GLOBAL symlink $devname mouse UNREGISTER misc/psaux CFUNCTION GLOBAL unlink mouse ------------------------------- What I thought that I wouldn't need would be those LOOKUP/MODLOAD lines. Any help would be appreciated, chippo From owner-devfs@oss.sgi.com Tue Apr 25 05:17:36 2000 Received: by oss.sgi.com id ; Tue, 25 Apr 2000 05:17:26 -0700 Received: from smtp-out.netactive.net ([196.22.160.30]:23052 "HELO smtp-out.netactive.net") by oss.sgi.com with SMTP id ; Tue, 25 Apr 2000 05:17:07 -0700 Received: (qmail 19523 invoked from network); 25 Apr 2000 12:21:18 -0000 Received: from ctpm34-224.netactive.co.za (HELO chippo.netactive.co.za) (root@196.22.170.224) by smtp-out.netactive.net with SMTP; 25 Apr 2000 12:21:18 -0000 Received: from netactive.co.za (IDENT:chippo@localhost.localdomain [127.0.0.1]) by chippo.netactive.co.za (8.9.3/8.8.7) with ESMTP id MAA01402 for ; Tue, 25 Apr 2000 12:57:51 +0200 Message-ID: <39057A2F.F344EBD0@netactive.co.za> Date: Tue, 25 Apr 2000 12:57:51 +0200 From: Chris the Elder X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: devfs@oss.sgi.com Subject: saving permissions in /dev-state of UNIX98 ptys Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Greetings, At one stage, I wanted to save the changed inodes in /dev, so I uncommented the lines in /etc/devfsd.conf: -------------------------- REGISTER .* COPY /dev-state/$devname $devpath CHANGE .* COPY $devpath /dev-state/$devname CREATE .* COPY $devpath /dev-state/$devname -------------------------- It seemed to work fine. I since decided to not copy these inodes, and I now rather get (or at least try to get) devfsd to make everything that I need in /dev on the fly. So, I don't currently suffer from this problem, but for the rest of the mail, assume that the above lines are in /etc/devfsd.conf. I was logging in to xterms and gnome-terms OK, until I logged in as root. This worked fine, but then when I next logged in as chippo, I had the UNIX98 pty problem, similarly to when I had glibc-2.1.2 installed. This was persistent across reboots. It seemed to me (though I don't know enough to confirm it), that when root logged in, it changed the permissions of some pty stuff, and that devfsd was remembering this. I could well have (due to ignorance) messed up the installation. Any guesses what? Or this could be a bug. Maybe we should warn people in the README. Cheers, chippo From owner-devfs@oss.sgi.com Tue Apr 25 20:42:18 2000 Received: by oss.sgi.com id ; Tue, 25 Apr 2000 20:42:08 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:25216 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Tue, 25 Apr 2000 20:41:42 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e3Q3eod07014; Tue, 25 Apr 2000 21:40:50 -0600 Date: Tue, 25 Apr 2000 21:40:50 -0600 Message-Id: <200004260340.e3Q3eod07014@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: linux-kernel@vger.rutgers.edu, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: [PATCH] devfs v164 available Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Hi, all. Version 164 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. This work has been sponsored by SGI. NOTE: there is a whole new FAQ for devfs which is bigger and better: http://www.atnf.csiro.au/~rgooch/linux/docs/devfs.html I've put a lot of work into fixing the deficiencies in the previous one. I hope it shows :-) This is against 2.3.99-pre6-7. Highlights of this release: - Fixed CONFIG_DEVFS breakage in drivers/char/serial.c introduced in linux-2.3.99-pre6-7 Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Wed Apr 26 21:35:27 2000 Received: by oss.sgi.com id ; Wed, 26 Apr 2000 21:35:07 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:33666 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Wed, 26 Apr 2000 21:34:49 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e3R4XWG17102; Wed, 26 Apr 2000 22:33:32 -0600 Date: Wed, 26 Apr 2000 22:33:32 -0600 Message-Id: <200004270433.e3R4XWG17102@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: linux-kernel@vger.rutgers.edu, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: [PATCH] devfs v165 available Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Hi, all. Version 165 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. This work has been sponsored by SGI. Patch directly available from: ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/kernel-patches/v2.3/devfs-patch-current.gz NOTE: there is a whole new FAQ for devfs which is bigger and better: http://www.atnf.csiro.au/~rgooch/linux/docs/devfs.html I've put a lot of work into fixing the deficiencies in the previous one. I hope it shows :-) This is against 2.3.99-pre6. Highlights of this release: - Ported to kernel 2.3.99-pre6 Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Wed Apr 26 23:13:17 2000 Received: by oss.sgi.com id ; Wed, 26 Apr 2000 23:13:09 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:43650 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Wed, 26 Apr 2000 23:12:52 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e3R6Bx618434; Thu, 27 Apr 2000 00:11:59 -0600 Date: Thu, 27 Apr 2000 00:11:59 -0600 Message-Id: <200004270611.e3R6Bx618434@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: linux-kernel@vger.rutgers.edu, devfs-announce-list@vindaloo.ras.ucalgary.ca Cc: torvalds@transmeta.com Subject: devfsd-v1.3.6 available Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Hi, all. I've just released version 1.3.6 of my devfsd (devfs daemon) at: http://www.atnf.csiro.au/~rgooch/linux/ This work has been sponsored by SGI. This works with devfs-patch-v130 and devfs-patch-v99.7 (or later). The main changes are: - Created a table of rules for simple compatibility translations - Added NIS configuration support. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Thu Apr 27 08:39:31 2000 Received: by oss.sgi.com id ; Thu, 27 Apr 2000 08:39:21 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:10115 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Thu, 27 Apr 2000 08:39:00 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e3RFchp21531; Thu, 27 Apr 2000 09:38:43 -0600 Date: Thu, 27 Apr 2000 09:38:43 -0600 Message-Id: <200004271538.e3RFchp21531@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Dag Bakke , Martin Costabel Cc: Chun-Chung Chen , devfs@oss.sgi.com Subject: Re: 2.3.99-p6 + devfs 165 = undef. ref to yp_all in devfsd 1.3.6 In-Reply-To: <3907FF27.75B272A2@oslo.sgi.com> References: <3907FF27.75B272A2@oslo.sgi.com> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Dag Bakke writes: > I just installed the 2.3.99-pre6 sources + devfs patch 165. Compiling > devfsd 1.3.6 yields: > > cc -O2 -o devfsd devfsd.o expression.o -O2 -I. -Wall -ldl > devfsd.o: In function `read_config': > devfsd.o(.text+0x72e): undefined reference to `yp_all' > collect2: ld returned 1 exit status > make: *** [devfsd] Error 1 > > I have no NIS support installed on this particular system. > /usr/src/linux is a symlink to the 2.3.99-pre6 sources. > Using glibc 2.1.3. What happens if you add -lnsl or -lnss_nis? Could all people who reported problems (and others too:-) please try compiling devfsd on their systems and tell me which library is required (try it both ways), and what their system configuration is? I have libc5 which has it yp_all(3) built-in. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Thu Apr 27 22:34:56 2000 Received: by oss.sgi.com id ; Thu, 27 Apr 2000 22:34:47 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:21632 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Thu, 27 Apr 2000 22:34:19 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e3S5X8w03247; Thu, 27 Apr 2000 23:33:08 -0600 Date: Thu, 27 Apr 2000 23:33:08 -0600 Message-Id: <200004280533.e3S5X8w03247@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: linux-kernel@vger.rutgers.edu, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: devfsd-v1.3.7 available Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Hi, all. I've just released version 1.3.7 of my devfsd (devfs daemon) at: http://www.atnf.csiro.au/~rgooch/linux/ This work has been sponsored by SGI. This works with devfs-patch-v130 and devfs-patch-v99.7 (or later). The main changes are: - Fixed compilation on glibc systems (-lnsl needed) - Fixed DIR leak - Generate synthetic REGISTER events on SIGHUP - Silently ignore NIS attempts when no NIS domain set. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Sat Apr 29 15:56:50 2000 Received: by oss.sgi.com id ; Sat, 29 Apr 2000 15:56:40 -0700 Received: from smtp-out.netactive.net ([196.22.160.30]:24841 "HELO smtp-out.netactive.net") by oss.sgi.com with SMTP id ; Sat, 29 Apr 2000 15:56:21 -0700 Received: (qmail 10625 invoked from network); 29 Apr 2000 23:00:25 -0000 Received: from ctpm33-48.netactive.co.za (HELO chippo.netactive.co.za) (root@196.22.170.48) by smtp-out.netactive.net with SMTP; 29 Apr 2000 23:00:25 -0000 Received: from netactive.co.za (IDENT:chippo@localhost.localdomain [127.0.0.1]) by chippo.netactive.co.za (8.9.3/8.8.7) with ESMTP id AAA00892 for ; Sun, 30 Apr 2000 00:55:58 +0200 Message-ID: <390B687E.F27AA376@netactive.co.za> Date: Sun, 30 Apr 2000 00:55:58 +0200 From: Chris the Elder X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: devfs@oss.sgi.com Subject: probeall not understood Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Hi, I'm using kernel 2.3.99-pre6, the devfs patch-v165 and devfsd-v1.3.7. I used the file in Documentation/filesystems/devfs/modules.conf as a template for /etc/modules.conf. However, devfsd complains about not understanding probeall and bombs. Obviously depmod and modprobe haven't a clue either. What did I do wrong? Cheers, chippo From owner-devfs@oss.sgi.com Sat Apr 29 23:55:35 2000 Received: by oss.sgi.com id ; Sat, 29 Apr 2000 23:55:25 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:38274 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Sat, 29 Apr 2000 23:55:09 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e3U6sqn17695; Sun, 30 Apr 2000 00:54:52 -0600 Date: Sun, 30 Apr 2000 00:54:52 -0600 Message-Id: <200004300654.e3U6sqn17695@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Chris the Elder Cc: devfs@oss.sgi.com Subject: Re: probeall not understood In-Reply-To: <390B687E.F27AA376@netactive.co.za> References: <390B687E.F27AA376@netactive.co.za> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Chris the Elder writes: > Hi, > > I'm using kernel 2.3.99-pre6, the devfs patch-v165 and devfsd-v1.3.7. > > I used the file in Documentation/filesystems/devfs/modules.conf as a > template for /etc/modules.conf. > > However, devfsd complains about not understanding probeall and > bombs. Obviously depmod and modprobe haven't a clue either. Is it devfsd or actually modprobe that complains? If it's modprobe not understanding something, it may be something you should report to Keith Owens (modutils maintainer). > What did I do wrong? Do you have modutils 2.3.10 installed? Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Sun Apr 30 12:03:57 2000 Received: by oss.sgi.com id ; Sun, 30 Apr 2000 12:03:48 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:13699 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Sun, 30 Apr 2000 12:03:28 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e3UJ2eW21010; Sun, 30 Apr 2000 13:02:40 -0600 Date: Sun, 30 Apr 2000 13:02:40 -0600 Message-Id: <200004301902.e3UJ2eW21010@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: linux-kernel@vger.rutgers.edu, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: [WARNING] devfs mount default changed Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Hi, all. The default mounting behaviour for devfs has changed recently :-( If your system no longer boots correctly (a typical message is "Unable to open initial console"), you may have been caught by this change. Look for the boot message: Mounted devfs on /dev If this is not present, add "devfs=mount" to your boot options. Don't Blame Me[tm]. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Sun Apr 30 12:16:37 2000 Received: by oss.sgi.com id ; Sun, 30 Apr 2000 12:16:28 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:18563 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Sun, 30 Apr 2000 12:16:09 -0700 Received: from dmz1.ras.ucalgary.ca (dmz1.ras.ucalgary.ca [136.159.55.130]) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) with ESMTP id e3UJFKK21302 for ; Sun, 30 Apr 2000 13:15:20 -0600 Received: from havoc.gtf.org (panic.ohr.gatech.edu [130.207.47.194]) by dmz1.ras.ucalgary.ca (8.10.0/8.10.0) with ESMTP id e3UJFKo21838 for ; Sun, 30 Apr 2000 13:15:20 -0600 Received: from mandrakesoft.com (adsl-77-228-125.atl.bellsouth.net [216.77.228.125]) by havoc.gtf.org (8.9.3/8.9.3) with ESMTP id PAA26695; Sun, 30 Apr 2000 15:15:03 -0400 Message-ID: <390C8637.D2ED49D3@mandrakesoft.com> Date: Sun, 30 Apr 2000 15:15:03 -0400 From: Jeff Garzik Organization: MandrakeSoft X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.15-0.28mdksmp i686) X-Accept-Language: en MIME-Version: 1.0 To: Richard Gooch CC: linux-kernel@vger.rutgers.edu, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: Re: [WARNING] devfs mount default changed References: <200004301902.e3UJ2eW21010@vindaloo.ras.ucalgary.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Richard Gooch wrote: > Hi, all. The default mounting behaviour for devfs has changed > recently :-( Thanks to the default mounting behavior change, people can compile devfs into their kernels without being forced to use it. > If your system no longer boots correctly (a typical > message is "Unable to open initial console"), you may have been caught > by this change. Look for the boot message: > Mounted devfs on /dev If there is a script that prints out a message "mounted devfs on /dev" but didn't really do so, that sounds like a bug. Jeff -- Jeff Garzik | Nothing cures insomnia like the Building 1024 | realization that it's time to get up. MandrakeSoft, Inc. | -- random fortune From owner-devfs@oss.sgi.com Sun Apr 30 12:26:47 2000 Received: by oss.sgi.com id ; Sun, 30 Apr 2000 12:26:38 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:21379 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Sun, 30 Apr 2000 12:26:12 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e3UJPNh21434; Sun, 30 Apr 2000 13:25:23 -0600 Date: Sun, 30 Apr 2000 13:25:23 -0600 Message-Id: <200004301925.e3UJPNh21434@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Jeff Garzik Cc: linux-kernel@vger.rutgers.edu, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: Re: [WARNING] devfs mount default changed In-Reply-To: <390C8637.D2ED49D3@mandrakesoft.com> References: <200004301902.e3UJ2eW21010@vindaloo.ras.ucalgary.ca> <390C8637.D2ED49D3@mandrakesoft.com> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Jeff Garzik writes: > Richard Gooch wrote: > > Hi, all. The default mounting behaviour for devfs has changed > > recently :-( > > Thanks to the default mounting behavior change, people can compile > devfs into their kernels without being forced to use it. Of course, they could before as well: just add "devfs=nomount". Your patch just made it more convenient to some people, at the cost of breaking existing behaviour (and making it inconvenient to others). Anyway, I don't really want to argue. I'm not happy about the change, but the King Penguin has decided, and that's that. Unlike some people, I won't keep screaming at the top of my lungs for him to change his mind. I'll just grumble whenever I get a similar bug report ;-) Hm. Maybe I should add a config option to control the default. > > If your system no longer boots correctly (a typical > > message is "Unable to open initial console"), you may have been caught > > by this change. Look for the boot message: > > Mounted devfs on /dev > > If there is a script that prints out a message "mounted devfs on /dev" > but didn't really do so, that sounds like a bug. I think you reversed the sense of what I wrote. If that message *doesn't* appear, it's a sign that "devfs=mount" needs to be added. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Sun Apr 30 13:13:27 2000 Received: by oss.sgi.com id ; Sun, 30 Apr 2000 13:13:18 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:28803 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Sun, 30 Apr 2000 13:13:13 -0700 Received: from dmz1.ras.ucalgary.ca (dmz1.ras.ucalgary.ca [136.159.55.130]) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) with ESMTP id e3UKCNK22103 for ; Sun, 30 Apr 2000 14:12:23 -0600 Received: from mail3.svr.pol.co.uk (mail3.svr.pol.co.uk [195.92.193.19]) by dmz1.ras.ucalgary.ca (8.10.0/8.10.0) with ESMTP id e3UKCNo22589 for ; Sun, 30 Apr 2000 14:12:23 -0600 Received: from modem-132.oregon.dialup.pol.co.uk ([62.137.88.132]) by mail3.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 12m01T-0000pa-00; Sun, 30 Apr 2000 21:09:00 +0100 Date: Sun, 30 Apr 2000 21:10:00 +0100 (BST) From: Tigran Aivazian X-Sender: tigran@saturn.homenet To: Richard Gooch cc: Jeff Garzik , linux-kernel@vger.rutgers.edu, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: Re: [WARNING] devfs mount default changed In-Reply-To: <200004301925.e3UJPNh21434@vindaloo.ras.ucalgary.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Hi Richard, On Sun, 30 Apr 2000, Richard Gooch wrote: > Of course, they could before as well: just add "devfs=nomount". not if they use LILO and their current command line is very close to 79 byte limit :) Regards, Tigran From owner-devfs@oss.sgi.com Sun Apr 30 17:44:09 2000 Received: by oss.sgi.com id ; Sun, 30 Apr 2000 17:43:59 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:50307 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Sun, 30 Apr 2000 17:43:51 -0700 Received: from dmz1.ras.ucalgary.ca (dmz1.ras.ucalgary.ca [136.159.55.130]) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) with ESMTP id e410h3K08596 for ; Sun, 30 Apr 2000 18:43:04 -0600 Received: from mharnois.workgroup.net (c1030098-a.wtrlo1.ia.home.com [24.14.126.45]) by dmz1.ras.ucalgary.ca (8.10.0/8.10.0) with ESMTP id e410h2o25889 for ; Sun, 30 Apr 2000 18:43:02 -0600 Received: (from mharnois@localhost) by mharnois.workgroup.net (8.10.1/8.10.1/Debian 8.10.1-1) id e410gCM30809; Sun, 30 Apr 2000 19:42:12 -0500 To: linux-kernel@vger.rutgers.edu, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: Re: [WARNING] devfs mount default changed References: <200004301902.e3UJ2eW21010@vindaloo.ras.ucalgary.ca> <390C8637.D2ED49D3@mandrakesoft.com> <200004301925.e3UJPNh21434@vindaloo.ras.ucalgary.ca> From: Michael Harnois Date: 30 Apr 2000 19:42:12 -0500 In-Reply-To: Richard Gooch's message of "Sun, 30 Apr 2000 13:25:23 -0600" Message-ID: <87u2gj5cez.fsf@mharnois.workgroup.net> Lines: 18 User-Agent: Gnus/5.0805 (Gnus v5.8.5) XEmacs/21.2 (Kastor & Polydeukes) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing On Sun, 30 Apr 2000 13:25:23 -0600, Richard Gooch said: > Your patch just made it more convenient to some people, at the > cost of breaking existing behaviour (and making it inconvenient > to others). "Inconvenient?" How about "idiotic?" "inane?" "woefully misguided?" Thanks to this change I can no longer reboot unattended after a power failure, since I have to be sitting at the console to enter something at the prompt (I use a boot floppy.) That's not inconvenient. That's just a plain stupid change. Geez, if you don't want to use it, don't compile it in. Don't mess up the systems of those of us who expect reasonably normal behavior. -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA mdharnois@home.com aa0bt@aa0bt.ampr.org When the stomach is satisfied, and lust is spent, man spares a little time for God. -- Will Durant From owner-devfs@oss.sgi.com Sun Apr 30 17:58:29 2000 Received: by oss.sgi.com id ; Sun, 30 Apr 2000 17:58:20 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:53635 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Sun, 30 Apr 2000 17:58:02 -0700 Received: from dmz1.ras.ucalgary.ca (dmz1.ras.ucalgary.ca [136.159.55.130]) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) with ESMTP id e410v8K08800 for ; Sun, 30 Apr 2000 18:57:08 -0600 Received: from colargol.tihlde.org (colargol.tihlde.hist.no [158.38.48.10]) by dmz1.ras.ucalgary.ca (8.10.0/8.10.0) with SMTP id e410v8o26100 for ; Sun, 30 Apr 2000 18:57:08 -0600 Received: (qmail 13242 invoked by uid 1292); 1 May 2000 00:57:02 -0000 To: Michael Harnois Cc: linux-kernel@vger.rutgers.edu, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: Re: [WARNING] devfs mount default changed References: <200004301902.e3UJ2eW21010@vindaloo.ras.ucalgary.ca> <390C8637.D2ED49D3@mandrakesoft.com> <200004301925.e3UJPNh21434@vindaloo.ras.ucalgary.ca> <87u2gj5cez.fsf@mharnois.workgroup.net> From: Oystein Viggen Organization: drift@tihlde X-Phone-Number: +47 97 11 48 58 X-Adress: Tordenskioldsgt. 12, 7012 Trondheim, Norway X-Priority: 1 X-MSMail-Priority: High X-Face: R=b-K(^1#]KR?6moG:Wrc/t>p)?p`?bgHg36M3hZ>^?\akat3!nX*8xZpIvZrI#]ZzN`I<+ L{8#pdH*1SOB$Zu-_e1<>iE$5cGiLhRem.ct.QtE=&v@9\S_6slX4='![%,F3^&ed5Y5g-#!N'Lr[s &Gfs3c}pYq^oUo{8l-qD87s[P1~+f([41~gD}Pj)nX|KcVv;tF4IIx%pnN\UL|SNT Date: 01 May 2000 02:57:02 +0200 In-Reply-To: Michael Harnois's message of "30 Apr 2000 19:42:12 -0500" Message-ID: <03g0s3jdep.fsf@colargol.tihlde.hist.no> Lines: 26 User-Agent: Gnus/5.0803 (Gnus v5.8.3) XEmacs/21.1 (Arches) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Michael Harnois wrote: > "Inconvenient?" How about "idiotic?" "inane?" "woefully misguided?" > Thanks to this change I can no longer reboot unattended after a power > failure, since I have to be sitting at the console to enter something > at the prompt (I use a boot floppy.) That's not inconvenient. That's > just a plain stupid change. Geez, if you don't want to use it, don't > compile it in. Don't mess up the systems of those of us who expect > reasonably normal behavior. Actually, if you think about how filesystems like proc and devpts are not automatically mounted at boot time, the change actually seems more correct. The problem is of course that devfs should be availible at boot time (if you mount /dev/disc/something in fstab, putting devfs also in there won't work). This makes devfs special, but not _that_ special. If you want to, you can put "/sbin/mount -t devfs none /dev" or something near the top of rc.sysinit or rc.S or whatever your particular distribution calls this file, and you'll be fine. That way, you don't even need the special not-conforming-to-standards behaviour of devfs mounting itself automatically at boot time. Personally, I don't think putting 'append="devfs=mount"' in my /etc/lilo.conf was that big a problem, anyway... :) Oystein From owner-devfs@oss.sgi.com Sun Apr 30 22:18:30 2000 Received: by oss.sgi.com id ; Sun, 30 Apr 2000 22:18:20 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:8324 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Sun, 30 Apr 2000 22:18:05 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e415FpM29207; Sun, 30 Apr 2000 23:15:51 -0600 Date: Sun, 30 Apr 2000 23:15:51 -0600 Message-Id: <200005010515.e415FpM29207@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: linux-kernel@vger.rutgers.edu, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: devfsd-v1.3.8 available Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Hi, all. I've just released version 1.3.8 of my devfsd (devfs daemon) at: http://www.atnf.csiro.au/~rgooch/linux/ This work has been sponsored by SGI. This works with devfs-patch-v130 and devfs-patch-v99.7 (or later). The main changes are: - Created new file compat_name.c and moved parts of into it - Simplified for SCSI and IDE new compatibilty entries. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Sun Apr 30 22:42:33 2000 Received: by oss.sgi.com id ; Sun, 30 Apr 2000 22:42:23 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:12164 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Sun, 30 Apr 2000 22:42:08 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e415fP329681; Sun, 30 Apr 2000 23:41:25 -0600 Date: Sun, 30 Apr 2000 23:41:25 -0600 Message-Id: <200005010541.e415fP329681@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: linux-kernel@vger.rutgers.edu, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: [PATCH] devfs v166 available Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Hi, all. Version 166 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. This work has been sponsored by SGI. Patch directly available from: ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/kernel-patches/v2.3/devfs-patch-current.gz NOTE: there is a whole new FAQ for devfs which is bigger and better: http://www.atnf.csiro.au/~rgooch/linux/docs/devfs.html I've put a lot of work into fixing the deficiencies in the previous one. I hope it shows :-) This is against 2.3.99-pre6. Highlights of this release: - Added CONFIG_DEVFS_MOUNT Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca