From owner-devfs@oss.sgi.com Sat Jun 3 08:14:46 2000 Received: by oss.sgi.com id ; Sat, 3 Jun 2000 08:14:36 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:47757 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Sat, 3 Jun 2000 08:14:10 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e53GDff31052; Sat, 3 Jun 2000 10:13:41 -0600 Date: Sat, 3 Jun 2000 10:13:41 -0600 Message-Id: <200006031613.e53GDff31052@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: devfs@oss.sgi.com, linux-fsdevel@vger.rutgers.edu Cc: linux-kernel@vger.rutgers.edu Subject: [RFC] Removal of devfs multi-mount feature Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Hi, all. The recent work by Al Viro on VFS bindings opens up the possibility of removing the built-in multi-mount facility in devfs. I'd like to discuss the pros and cons and get some feedback. As some of you are aware, devfs may be mounted multiple times, with the option of *not* exposing device entries in a mounted devfs until the sysadmin does mknod(2). Permissions and ownerships are maintained separately for each mounted devfs. This multi-mount feature is designed with chroot gaols in mind, where you may want to expose a very limited number of device nodes in a gaol. With VFS bindings, it is possible to bind individual files (the original design only bound directories, IIRC), thus providing a similar feature that the devfs multi-mount facility does. What would be lost is the ability to independently change permissions on device nodes in each chroot gaol; permissions would be shared. At some point in the future VFS bindings may allow us to inherit permissions from the VFS mount, which would mean all devices in a gaol would have the same permissions. But such a development may never happen, so bear that in mind. My inclination is to just rely on VFS bindings, as it should be sufficiently flexible (I hope) and it simplifies the devfs code. I'd like to get feedback from people who set up chroot gaols (or at least those people who think and care about them:-) on whether changing from the current built-in devfs multi-mount feature to just relying on VFS bindings (and thus less flexibilty with controlling permissions) is a problem or not. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Thu Jun 8 00:12:54 2000 Received: by oss.sgi.com id ; Thu, 8 Jun 2000 00:12:45 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:62614 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Thu, 8 Jun 2000 00:12:28 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e585j5d18700; Wed, 7 Jun 2000 23:45:05 -0600 Date: Wed, 7 Jun 2000 23:45:05 -0600 Message-Id: <200006080545.e585j5d18700@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Johannes Erdfelt Cc: devfs@oss.sgi.com Subject: Devfs and USB status Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Hi, Johannes. I'm wondering what's happened as a result of our discussions a couple of months ago? You were planning on making heavy use of devfs+devfsd in the USB code. How's that going? Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Thu Jun 8 00:12:54 2000 Received: by oss.sgi.com id ; Thu, 8 Jun 2000 00:12:45 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:62614 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Thu, 8 Jun 2000 00:12:29 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e585gbn18615; Wed, 7 Jun 2000 23:42:37 -0600 Date: Wed, 7 Jun 2000 23:42:37 -0600 Message-Id: <200006080542.e585gbn18615@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Johannes Erdfelt Cc: devfs@oss.sgi.com Subject: Re: small patch + question In-Reply-To: <20000517161218.C15221@valinux.com> References: <20000517161218.C15221@valinux.com> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Johannes Erdfelt writes: > On an unrelated point, I have a question about changing permissions and > supression. > > I have a module which dynamically tracks permissions for USB devices > and applies them back to the device when it gets plugged back in. > > In the REGISTER handler, I do a chown/chmod pair (well, fchown/fchmod) > which then generates another CHANGE request, causing extra processing since > it looks like a user (admin, etc) made a change to file, when it was > actually generated by devfsd. > > Would it be possible for devfs (the kernel portion) to not generate > events when the devfsd process (or the process which has .devfsd > open) makes changes? This is possible, but it has a performance impact, since inode changes will then require a test to see if the changing process is devfsd or one of its children. This involves walking up the process tables. And even if it were free, there's still a problem: > I can't see a reason where it would be needed since devfsd is always > aware of the changes it makes, since it made them in the first > place. That's only really true for devfsd itself. It doesn't know what dynamically loaded extensions or scripts will do. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Thu Jun 8 00:12:54 2000 Received: by oss.sgi.com id ; Thu, 8 Jun 2000 00:12:45 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:62614 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Thu, 8 Jun 2000 00:12:30 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e585qXK18859; Wed, 7 Jun 2000 23:52:33 -0600 Date: Wed, 7 Jun 2000 23:52:33 -0600 Message-Id: <200006080552.e585qXK18859@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Johannes Erdfelt Cc: devfs@oss.sgi.com Subject: Re: small patch + question In-Reply-To: <20000607224652.B2108@valinux.com> References: <20000517161218.C15221@valinux.com> <200006080542.e585gbn18615@vindaloo.ras.ucalgary.ca> <20000607224652.B2108@valinux.com> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Johannes Erdfelt writes: > On Wed, Jun 07, 2000, Richard Gooch wrote: > > Johannes Erdfelt writes: > > > On an unrelated point, I have a question about changing permissions and > > > supression. > > > > > > I have a module which dynamically tracks permissions for USB devices > > > and applies them back to the device when it gets plugged back in. > > > > > > In the REGISTER handler, I do a chown/chmod pair (well, fchown/fchmod) > > > which then generates another CHANGE request, causing extra processing since > > > it looks like a user (admin, etc) made a change to file, when it was > > > actually generated by devfsd. > > > > > > Would it be possible for devfs (the kernel portion) to not generate > > > events when the devfsd process (or the process which has .devfsd > > > open) makes changes? > > > > This is possible, but it has a performance impact, since inode changes > > will then require a test to see if the changing process is devfsd or > > one of its children. This involves walking up the process tables. > > I was thinking of just the devfsd process. Not necessarily any children. That would require adding yet more code for a different kind of test, one which only checks for the devfsd process. So I couldn't just call my existing function. > > And even if it were free, there's still a problem: > > > > > I can't see a reason where it would be needed since devfsd is always > > > aware of the changes it makes, since it made them in the first > > > place. > > > > That's only really true for devfsd itself. It doesn't know what > > dynamically loaded extensions or scripts will do. > > Dynamically loaded extensions could be handled and scripts would > be children and not match the check. I don't see how extensions could be handled, not without imposing some kind of restriction (i.e. you must call this API to make changes) that's just prone to failure. People will forget to use devfsd_chmod() instead of chmod(2). > Probably too complicated for what it's worth anyway. Indeed. Also, it would break the idea that devfsd and any scripts it calls are all equal. This equality is important, because scripts are written to add functionality that devfsd doesn't have. They should be viewed as part of devfsd (i.e. same rights and privileges). Breaking this equality would mean when something migrates from the script to the devfsd core code, the behaviour is changed. An unwelcome surprise. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Thu Jun 8 00:12:55 2000 Received: by oss.sgi.com id ; Thu, 8 Jun 2000 00:12:45 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:62614 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Thu, 8 Jun 2000 00:12:31 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e585asR18537; Wed, 7 Jun 2000 23:36:54 -0600 Date: Wed, 7 Jun 2000 23:36:54 -0600 Message-Id: <200006080536.e585asR18537@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Johannes Erdfelt Cc: devfs@oss.sgi.com Subject: Re: small patch + question In-Reply-To: <20000517161427.D15221@valinux.com> References: <20000517161218.C15221@valinux.com> <20000517161427.D15221@valinux.com> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Johannes Erdfelt writes: > > --RnlQjJ0d97Da+TV1 > Content-Type: text/plain; charset=us-ascii > > On Wed, May 17, 2000, Johannes Erdfelt wrote: > > Here's a small patch to devfsd to add -export-dynamic while linking so > > that modules can use exported variables from the executable. Of interest > > is the syslog_is_open variable so I can use the SYSLOG() variable. > > And of course the patch (woops). OK, applied. I assume a new release isn't warranted. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Thu Jun 8 00:12:55 2000 Received: by oss.sgi.com id ; Thu, 8 Jun 2000 00:12:45 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:62614 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Thu, 8 Jun 2000 00:12:31 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e585RP818395; Wed, 7 Jun 2000 23:27:25 -0600 Date: Wed, 7 Jun 2000 23:27:25 -0600 Message-Id: <200006080527.e585RP818395@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: linux-kernel@vger.rutgers.edu, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: [PATCH] devfs v99.14 available Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Hi, all. Version 99.14 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.2/devfs-patch-current.gz NOTE: the devfs-patch-v99.x patches are maintenance patches for the 2.2.x production kernels. Devfs development is done against recent development kernels. Occasionally, the latest devfs patch for the development kernels may be backported to 2.2.x series, but this happens rarely. This is against 2.2.16. Highlights of this release: - Ported devfs-patch-v99.13 to kernel 2.2.16 Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Thu Jun 8 00:45:16 2000 Received: by oss.sgi.com id ; Thu, 8 Jun 2000 00:45:07 -0700 Received: from nat-su-33.valinux.com ([198.186.202.33]:25867 "EHLO phenoxide.su.varesearch.com") by oss.sgi.com with ESMTP id ; Thu, 8 Jun 2000 00:44:56 -0700 Received: (from jerdfelt@localhost) by phenoxide.su.varesearch.com (8.9.3/8.9.3) id WAA04854; Wed, 7 Jun 2000 22:44:59 -0700 Date: Wed, 7 Jun 2000 22:44:59 -0700 From: Johannes Erdfelt To: Richard Gooch Cc: devfs@oss.sgi.com Subject: Re: small patch + question Message-ID: <20000607224459.A2108@valinux.com> References: <20000517161218.C15221@valinux.com> <20000517161427.D15221@valinux.com> <200006080536.e585asR18537@vindaloo.ras.ucalgary.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200006080536.e585asR18537@vindaloo.ras.ucalgary.ca>; from rgooch@ras.ucalgary.ca on Wed, Jun 07, 2000 at 11:36:54PM -0600 Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing On Wed, Jun 07, 2000, Richard Gooch wrote: > Johannes Erdfelt writes: > > > > --RnlQjJ0d97Da+TV1 > > Content-Type: text/plain; charset=us-ascii > > > > On Wed, May 17, 2000, Johannes Erdfelt wrote: > > > Here's a small patch to devfsd to add -export-dynamic while linking so > > > that modules can use exported variables from the executable. Of interest > > > is the syslog_is_open variable so I can use the SYSLOG() variable. > > > > And of course the patch (woops). > > OK, applied. I assume a new release isn't warranted. Nope. It can wait. JE From owner-devfs@oss.sgi.com Thu Jun 8 00:45:16 2000 Received: by oss.sgi.com id ; Thu, 8 Jun 2000 00:45:06 -0700 Received: from nat-su-33.valinux.com ([198.186.202.33]:25867 "EHLO phenoxide.su.varesearch.com") by oss.sgi.com with ESMTP id ; Thu, 8 Jun 2000 00:44:56 -0700 Received: (from jerdfelt@localhost) by phenoxide.su.varesearch.com (8.9.3/8.9.3) id WAA04864; Wed, 7 Jun 2000 22:46:52 -0700 Date: Wed, 7 Jun 2000 22:46:52 -0700 From: Johannes Erdfelt To: Richard Gooch Cc: devfs@oss.sgi.com Subject: Re: small patch + question Message-ID: <20000607224652.B2108@valinux.com> References: <20000517161218.C15221@valinux.com> <200006080542.e585gbn18615@vindaloo.ras.ucalgary.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200006080542.e585gbn18615@vindaloo.ras.ucalgary.ca>; from rgooch@ras.ucalgary.ca on Wed, Jun 07, 2000 at 11:42:37PM -0600 Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing On Wed, Jun 07, 2000, Richard Gooch wrote: > Johannes Erdfelt writes: > > On an unrelated point, I have a question about changing permissions and > > supression. > > > > I have a module which dynamically tracks permissions for USB devices > > and applies them back to the device when it gets plugged back in. > > > > In the REGISTER handler, I do a chown/chmod pair (well, fchown/fchmod) > > which then generates another CHANGE request, causing extra processing since > > it looks like a user (admin, etc) made a change to file, when it was > > actually generated by devfsd. > > > > Would it be possible for devfs (the kernel portion) to not generate > > events when the devfsd process (or the process which has .devfsd > > open) makes changes? > > This is possible, but it has a performance impact, since inode changes > will then require a test to see if the changing process is devfsd or > one of its children. This involves walking up the process tables. I was thinking of just the devfsd process. Not necessarily any children. > And even if it were free, there's still a problem: > > > I can't see a reason where it would be needed since devfsd is always > > aware of the changes it makes, since it made them in the first > > place. > > That's only really true for devfsd itself. It doesn't know what > dynamically loaded extensions or scripts will do. Dynamically loaded extensions could be handled and scripts would be children and not match the check. Probably too complicated for what it's worth anyway. JE From owner-devfs@oss.sgi.com Thu Jun 8 00:45:16 2000 Received: by oss.sgi.com id ; Thu, 8 Jun 2000 00:45:06 -0700 Received: from nat-su-33.valinux.com ([198.186.202.33]:25867 "EHLO phenoxide.su.varesearch.com") by oss.sgi.com with ESMTP id ; Thu, 8 Jun 2000 00:44:56 -0700 Received: (from jerdfelt@localhost) by phenoxide.su.varesearch.com (8.9.3/8.9.3) id WAA04881; Wed, 7 Jun 2000 22:52:56 -0700 Date: Wed, 7 Jun 2000 22:52:56 -0700 From: Johannes Erdfelt To: Richard Gooch Cc: devfs@oss.sgi.com Subject: Re: Devfs and USB status Message-ID: <20000607225256.C2108@valinux.com> References: <200006080545.e585j5d18700@vindaloo.ras.ucalgary.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200006080545.e585j5d18700@vindaloo.ras.ucalgary.ca>; from rgooch@ras.ucalgary.ca on Wed, Jun 07, 2000 at 11:45:05PM -0600 Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing On Wed, Jun 07, 2000, Richard Gooch wrote: > Hi, Johannes. I'm wondering what's happened as a result of our > discussions a couple of months ago? You were planning on making heavy > use of devfs+devfsd in the USB code. How's that going? Slowly. I had gotten most of the code developed and working, but then I received an email from Randy Dunlap, the USB maintainer. He had a discussion with Linus about the subject. I've included the email at the end of my mail. I don't know what to do now. I've been spending some time on a white paper which describes the problems we are running into and why I wanted to use devfs to facilitate solving the problems. However, I'm unsure it will make any difference. People seem to want a hacked together kludge than something sensible (devfs IMHO). JE Message-ID: From: "Dunlap, Randy" To: "'Johannes Erdfelt'" , linux-usb@suse.com Subject: RE: [linux-usb] [exp. patch] userspace driver binding (and follow ing patches) Date: Thu, 25 May 2000 14:20:23 -0700 Hi, I believe that I owe Johannes a reply to a patch that he posted on 2000-may-04, so here's my reply. It is the policy of the linux-usb mailing list (and its maintainer) as defined and decided last Dec. 1999 to accept patches or reject them with reason. Johannes's devfs patches for USB have been especially difficult for me to decide and no doubt I have taken a long time on it. I really couldn't decide. Johannes and David Brownell had some good discussion and some good progress with JE's patch, and my thanks to David Brownell for experimenting with this patch. In the end I asked Linus about it, and he said that we can't _require_ devfs for USB operation [his reply is below], so this patch as submitted isn't acceptable [my words]. I hope that this patch decision hasn't delayed other USB implementation or patches. So we are still in need of a patch with this kind of functionality that doesn't rely on devfs. (Using usbdevfs is fine.) It seems to me that module autoloading via usbdevfs should be a high priority for us right away. We don't know whether devfs will be used for lots of PnP support in 2.5 or not, but we can't depend on it now (2.4). There are also parts of Johannes's two patch files that aren't about devfs that should be added to the kernel. Johannes, will you give me separate patches for these (preferably) or should I extract them? Linus: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Basically, we cann't require devfs for operation, it's too experimental as is. If the thing still works without devfs, it would be quite acceptable. For example, if the behaviour were to be that with regular devices you can only see _one_ mouse device (the mixed up one) etc, and in order to see multiple ones you'd have to use devfs, that would be ok, I think. But if it becomes an issue of not seeing USB devices at all unless devfs is on, that would be bad.. ~~~~~~~~~~~~~~~ some comments about JE's patches ~~~~~~~~~~~~~~~~~ _______________ [basically what I sent to Linus] _________________ Johannes has proposed a USB patch for device/driver PnP support that is based on devfs & devfsd. IMO Johannes is pushing the leading (or bleeding) edge of USB and PnP. OTOH Alan says that most initial 2.4 distributions won't have DEVFS support turned on, so Johannes' patch won't do most people any good unless they enable DEVFS support. Alan also doesn't want to base USB PnP on devfs because he wants the USB backport patch to continue to work on 2.2 and having a devfs dependency makes that messy. If we were starting from {zero, scratch}, Johannes' patch wouldn't be difficult to accept & apply. There would be no 2.2 to consider, nothing about distros moving to devfs to consider, etc. I would go with Johannes' devfs patch and have what appears to be a nice USB PnP solution, although it's unknown as to how this would fit with Linux 2.5 PnP (for USB, PCMCIA, hot-plug PCI, SCSI, 1394, etc.). It has never been my primary goal to support Linux 2.2 with USB. Having a backport patch is nice. Maybe even more than that for the distributors -- maybe Required. Maybe we need to decide how important 2.2 support is before going any further with this. Sometimes reality sets in and we have to consider things other than the ideal. I really don't want to lose any developers over this issue. We all benefit from having Johannes helping on Linux-USB. I've seen a few emails suggesting that Linux 2.5 is where full Linux PnP support will be developed. Is there reason to believe that this will be based on DEVFS or on something-yet-to-be-developed? If based on DEVFS, I guess USB can be a guinea pig for it to see how well it works, what changes it needs, etc. ~~~~~~~~~~~~~~~~~~~~~~ end ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ JE, 4/4/2000: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This is an implementation of the proposed changes I sent an email about last week. See http://www.electricrain.com/lists/archive/linux-usb/2000/03/msg00860.html for the original email and explanation. There are 2 patches. The first one is for the kernel and it is against 2.3.99-pre4-3. The second patch is for devfsd and is against the 3-FEB-2000 release. [snip] JE, 5/4/2000: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [snip] First off, I've attached a patch to completely nuke usbdevfs's VFS layer in favor of using devfs for all of that stuff. Nodes are still created, and you use the same ioctl()'s, you just use a different name and you don't have to worry about mounting an extra filesystem to get it. The patch also does a couple of other things: - Adds a new GET_DRIVER ioctl() - Set's the address for the device before grabbing the descriptors This is safe since we need to do the short descriptor read to get the maximum packet size of the control pipe, however SET_ADDRESS doesn't have a data transfer stage, so the maximum packet size is never used Also, I'd like to get my user space driver binding patch included to appropriately load and bind drivers for devices to minimize problems that the current scheme has. [snip] I'm working on another workaround which moves it from the HCD to the core so it'll work with all devices, but I've been mainly working on other issues that more important for USB as a whole than a specific device. [snip] ______________________________________ ~Randy ___________________________________________________ |Randy Dunlap Intel Corp., DAL Sr. SW Engr.| |randy.dunlap.at.intel.com 503-696-2055| |NOTE: Any views presented here are mine alone | |and may not represent the views of my employer. | |_________________________________________________| From owner-devfs@oss.sgi.com Thu Jun 8 22:35:52 2000 Received: by oss.sgi.com id ; Thu, 8 Jun 2000 22:35:41 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:31384 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Thu, 8 Jun 2000 22:35:41 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e595YkV29766; Thu, 8 Jun 2000 23:34:46 -0600 Date: Thu, 8 Jun 2000 23:34:46 -0600 Message-Id: <200006090534.e595YkV29766@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: linux-kernel@vger.rutgers.edu, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: [PATCH] devfs v168 available Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Hi, all. Version 168 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 This is against 2.4.0-test1. Highlights of this release: - Disabled multi-mount capability (use VFS bindings instead) - Updated README from master HTML file Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Fri Jun 9 09:09:33 2000 Received: by oss.sgi.com id ; Fri, 9 Jun 2000 09:09:23 -0700 Received: from firewall-in.sch57.msk.ru ([195.178.195.6]:47879 "EHLO dell.sch57.msk.ru") by oss.sgi.com with ESMTP id ; Fri, 9 Jun 2000 09:09:14 -0700 Received: from khim.UUCP (uucp@localhost) by dell.sch57.msk.ru (8.8.8/8.8.8) with UUCP id UAA24077; Fri, 9 Jun 2000 20:00:28 +0400 Received: by khim.sch57.msk.ru (dMail for DOS v2.07a2, 12Jun98); Fri, 9 Jun 2000 20:03:17 +0400 To: jerdfelt@valinux.com, rgooch@ras.ucalgary.ca Cc: devfs@oss.sgi.com References: <20000607225256.C2108@valinux.com> <200006080545.e585j5d18700@vindaloo.ras.ucalgary.ca> Message-Id: Organization: MCCME From: "Khimenko Victor" Date: Fri, 9 Jun 2000 20:03:17 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07a2] Subject: Re: Devfs and USB status Lines: 26 MIME-Version: 1.0 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 7-Jun-00 22:52 you wrote: > On Wed, Jun 07, 2000, Richard Gooch wrote: >> Hi, Johannes. I'm wondering what's happened as a result of our >> discussions a couple of months ago? You were planning on making heavy >> use of devfs+devfsd in the USB code. How's that going? > Slowly. I had gotten most of the code developed and working, but then I > received an email from Randy Dunlap, the USB maintainer. He had a > discussion with Linus about the subject. I've included the email at the > end of my mail. > I don't know what to do now. I've been spending some time on a white > paper which describes the problems we are running into and why I > wanted to use devfs to facilitate solving the problems. However, > I'm unsure it will make any difference. People seem to want a hacked > together kludge than something sensible (devfs IMHO). Looks like the only solution is to go "devfs (reiserfs, raid, etc) way": keep it as separate patch for 2.4 (2.6, 2.8) and merge in 2.5 (2.7, 2.9). Most peoples out there are NOT kernel developers. They want to hear sound, use USB mouse and not think about kernel at all. They DO NOT want to play with ALSA, devfs unless it's included in distribution by default. For them devfs requirement for USB is evil. So USB can not rely on devfs (for now) :-/ This mean: we need some kludgy solution for 2.4. It does not mean that such kludges should be with us forever. From owner-devfs@oss.sgi.com Sat Jun 10 10:46:31 2000 Received: by oss.sgi.com id ; Sat, 10 Jun 2000 10:46:22 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:53402 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Sat, 10 Jun 2000 10:46:10 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e5AHjQf13707; Sat, 10 Jun 2000 11:45:26 -0600 Date: Sat, 10 Jun 2000 11:45:26 -0600 Message-Id: <200006101745.e5AHjQf13707@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: linux-kernel@vger.rutgers.edu, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: [PATCH] devfs v99.15 available Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Hi, all. Version 99.15 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.2/devfs-patch-current.gz NOTE: the devfs-patch-v99.x patches are maintenance patches for the 2.2.x production kernels. Devfs development is done against recent development kernels. Occasionally, the latest devfs patch for the development kernels may be backported to 2.2.x series, but this happens rarely. This is against 2.2.16. Highlights of this release: - Made drivers/block/genhd.c:disk_name() friendly to RAID 0.90 patches Thanks to Arne Georg Gleditsch Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Sat Jun 10 11:00:23 2000 Received: by oss.sgi.com id ; Sat, 10 Jun 2000 11:00:13 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:56474 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Sat, 10 Jun 2000 10:59:58 -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 e5AHxAZ13937 for ; Sat, 10 Jun 2000 11:59:10 -0600 Received: from router.abc (pec-89-172.tnt6.b2.uunet.de [149.225.89.172]) by dmz1.ras.ucalgary.ca (8.10.0/8.10.0) with ESMTP id e5AHx8o16511 for ; Sat, 10 Jun 2000 11:59:09 -0600 Received: from baldauf.org (notebook.abc [192.168.1.3]) by router.abc (8.8.8/8.8.8) with ESMTP id TAA01256; Sat, 10 Jun 2000 19:58:16 +0200 Message-ID: <394281B6.DC2A6584@baldauf.org> Date: Sat, 10 Jun 2000 19:58:14 +0200 From: Xuan Baldauf Organization: Medium.net X-Mailer: Mozilla 4.73 [en] (Win98; I) X-Accept-Language: en,de-DE MIME-Version: 1.0 To: Richard Gooch CC: linux-kernel@vger.rutgers.edu, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: Patch: isdn for devfsd References: <200006101745.e5AHjQf13707@vindaloo.ras.ucalgary.ca> Content-Type: multipart/mixed; boundary="------------6CB303629C5A347A6D4483DD" Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing This is a multi-part message in MIME format. --------------6CB303629C5A347A6D4483DD Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Here a patch for devfsd-isdn-support: :o) Xuân. :o) Richard Gooch wrote: > Hi, all. Version 99.15 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.2/devfs-patch-current.gz > > NOTE: the devfs-patch-v99.x patches are maintenance patches for the > 2.2.x production kernels. Devfs development is done against recent > development kernels. Occasionally, the latest devfs patch for the > development kernels may be backported to 2.2.x series, but this > happens rarely. > > This is against 2.2.16. Highlights of this release: > > - Made drivers/block/genhd.c:disk_name() friendly to RAID 0.90 patches > Thanks to Arne Georg Gleditsch > > Regards, > > Richard.... > Permanent: rgooch@atnf.csiro.au > Current: rgooch@ras.ucalgary.ca > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.rutgers.edu > Please read the FAQ at http://www.tux.org/lkml/ --------------6CB303629C5A347A6D4483DD Content-Type: text/plain; charset=us-ascii; name="devfsd.isdn.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="devfsd.isdn.patch" diff -Nur devfsd1.3.7/devfsd.c devfsd/devfsd.c --- devfsd1.3.7/devfsd.c Fri Apr 28 07:15:30 2000 +++ devfsd/devfsd.c Sat Jun 10 19:23:30 2000 @@ -1245,6 +1245,7 @@ {"cuf/", "cuf%s"}, {"vc/", "tty%s"}, {"misc/", NULL}, + {"isdn/", NULL}, {NULL, NULL} }; --------------6CB303629C5A347A6D4483DD-- From owner-devfs@oss.sgi.com Sat Jun 10 11:17:03 2000 Received: by oss.sgi.com id ; Sat, 10 Jun 2000 11:16:53 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:59034 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Sat, 10 Jun 2000 11:16:39 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e5AIG1614257; Sat, 10 Jun 2000 12:16:01 -0600 Date: Sat, 10 Jun 2000 12:16:01 -0600 Message-Id: <200006101816.e5AIG1614257@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: linux-kernel@vger.rutgers.edu, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: devfsd-v1.3.9 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.9 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 -export-dynamic when linking devfsd - Added compatibility entries for ISDN BRI driver. Thanks to Xuan Baldauf . Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Sat Jun 10 21:05:56 2000 Received: by oss.sgi.com id ; Sat, 10 Jun 2000 21:05:46 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:38043 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Sat, 10 Jun 2000 21:05:20 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e5B41pX20906; Sat, 10 Jun 2000 22:01:51 -0600 Date: Sat, 10 Jun 2000 22:01:51 -0600 Message-Id: <200006110401.e5B41pX20906@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: "Khimenko Victor" Cc: jerdfelt@valinux.com, devfs@oss.sgi.com Subject: Re: Devfs and USB status In-Reply-To: References: <20000607225256.C2108@valinux.com> <200006080545.e585j5d18700@vindaloo.ras.ucalgary.ca> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Khimenko Victor writes: > 7-Jun-00 22:52 you wrote: > > On Wed, Jun 07, 2000, Richard Gooch wrote: > >> Hi, Johannes. I'm wondering what's happened as a result of our > >> discussions a couple of months ago? You were planning on making heavy > >> use of devfs+devfsd in the USB code. How's that going? > > > Slowly. I had gotten most of the code developed and working, but then I > > received an email from Randy Dunlap, the USB maintainer. He had a > > discussion with Linus about the subject. I've included the email at the > > end of my mail. > > > I don't know what to do now. I've been spending some time on a white > > paper which describes the problems we are running into and why I > > wanted to use devfs to facilitate solving the problems. However, > > I'm unsure it will make any difference. People seem to want a hacked > > together kludge than something sensible (devfs IMHO). > > Looks like the only solution is to go "devfs (reiserfs, raid, etc) > way": keep it as separate patch for 2.4 (2.6, 2.8) and merge in 2.5 > (2.7, 2.9). Most peoples out there are NOT kernel developers. They > want to hear sound, use USB mouse and not think about kernel at > all. They DO NOT want to play with ALSA, devfs unless it's included > in distribution by default. For them devfs requirement for USB is > evil. So USB can not rely on devfs (for now) :-/ This mean: we need > some kludgy solution for 2.4. It does not mean that such kludges > should be with us forever. I'd suggest against implementing kludged-up workarounds to devfs as "temporary solutions". It may prove to be wasted effort in the long run. Devfs is evolving into something that should be more palatable for more people. Furthermore, adding some of the features of devfs to usbdevfs is a seriously retrograde step. Why duplicate the code? I'm in the process of removing the devfs multi-mount code, which will simplify the implementation somewhat. The new VFS binding code can be used instead. So hopefully some of the detractors will be happier. Linus has also said he hopes to see devfs evolve into something better. Unfortunately, he hasn't said what, nor has he answered my hails to talk to him in person and discuss devfs developments. Maybe someone on the USB team can get his attention? Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Mon Jun 12 11:03:18 2000 Received: by oss.sgi.com id ; Mon, 12 Jun 2000 11:03:08 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:11421 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Mon, 12 Jun 2000 11:02:57 -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 e5CJ20Z32756 for ; Mon, 12 Jun 2000 13:02:00 -0600 Received: from hermes.mvista.com (gateway-490.mvista.com [63.192.220.206]) by dmz1.ras.ucalgary.ca (8.10.0/8.10.0) with ESMTP id e5CJ20o09373 for ; Mon, 12 Jun 2000 13:02:00 -0600 Received: from mvista.com (IDENT:akuster@anius.mvista.com [10.0.0.94]) by hermes.mvista.com (8.9.3/8.9.3) with ESMTP id MAA03106; Mon, 12 Jun 2000 12:00:51 -0700 Message-ID: <394533B7.42EA8669@mvista.com> Date: Mon, 12 Jun 2000 12:02:15 -0700 From: Armin Kuster Organization: Support X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20b i586) 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: devfsd-v1.3.9 available References: <200006101816.e5AIG1614257@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've just released version 1.3.9 of my devfsd (devfs > daemon) > Regards, Does the devfsd have to be running in order to take advantage ot the devfs API's? My concern is using devfs on other targets F.E. ARM, PPC... regards, -- =========================================================================== Armin Kuster MontaVista Software Inc. Customer Support Engineer 790 Potrero Avenue Phone (408) 328-0305 Sunnyvale CA 94086 Fax (408) 328-9204 e-mail: akuster@mvista.com web: www.mvista.com support e-mail: support@mvista.com =========================================================================== From owner-devfs@oss.sgi.com Mon Jun 12 13:02:30 2000 Received: by oss.sgi.com id ; Mon, 12 Jun 2000 13:02:10 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:26525 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Mon, 12 Jun 2000 13:01:47 -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 e5CKvpZ01354 for ; Mon, 12 Jun 2000 14:57:51 -0600 Received: from priv-edtnes12-hme0.telusplanet.net (edtnes12.telus.net [199.185.220.112]) by dmz1.ras.ucalgary.ca (8.10.0/8.10.0) with ESMTP id e5CKvqo10236 for ; Mon, 12 Jun 2000 14:57:52 -0600 Received: from wakko.deltatee.com ([209.115.196.25]) by priv-edtnes12-hme0.telusplanet.net (InterMail vM.4.01.02.11 201-229-116-111) with ESMTP id <20000612205748.FYES11580.priv-edtnes12-hme0.telusplanet.net@wakko.deltatee.com>; Mon, 12 Jun 2000 14:57:48 -0600 Received: from localhost (wakko.deltatee.com) [127.0.0.1] (jgg) by wakko.deltatee.com with smtp (Exim 2.11 #1) id 131bHj-0001Sv-00 (Debian); Mon, 12 Jun 2000 14:58:15 -0600 Date: Mon, 12 Jun 2000 14:58:15 -0600 (MDT) From: Jason Gunthorpe X-Sender: jgg@wakko.deltatee.com To: Armin Kuster cc: Richard Gooch , linux-kernel@vger.rutgers.edu, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: Re: devfsd-v1.3.9 available In-Reply-To: <394533B7.42EA8669@mvista.com> 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 Mon, 12 Jun 2000, Armin Kuster wrote: > > Hi, all. I've just released version 1.3.9 of my devfsd (devfs > > daemon) > > Regards, > Does the devfsd have to be running in order to take advantage ot the > devfs API's? My concern is using devfs on other targets F.E. ARM, > PPC... I have been booting an embedded ARM board for about two weeks now using devfs without devfsd. Works great, as long as you don't expect too much from things like init (which seems to get slightly confused). yellow:/tmp# ls -CF /dev console initctl| mem port pts/ tts/ zero cua/ kmem null printers/ pty/ tty full loop/ parports/ ptmx random urandom yellow:/tmp# cat /proc/cpuinfo Processor : ARM/VLSI ARM 710 rev 0 (v3l) BogoMIPS : 24.22 Hardware : CL-PS7500 Revision : 0000 Serial : 0000000000000000 Jason From owner-devfs@oss.sgi.com Mon Jun 12 21:49:43 2000 Received: by oss.sgi.com id ; Mon, 12 Jun 2000 21:49:23 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:7582 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Mon, 12 Jun 2000 21:48:52 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e5D5ln707163; Mon, 12 Jun 2000 23:47:49 -0600 Date: Mon, 12 Jun 2000 23:47:49 -0600 Message-Id: <200006130547.e5D5ln707163@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: linux-kernel@vger.rutgers.edu, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: [PATCH] devfs v169 available Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Hi, all. Version 169 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 This is against 2.4.0-test1. Highlights of this release: - Removed multi-mount code - Removed compatibility macros: VFS has changed too much Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Tue Jun 13 15:15:31 2000 Received: by oss.sgi.com id ; Tue, 13 Jun 2000 15:15:11 -0700 Received: from mx01.uni-tuebingen.de ([134.2.3.11]:54030 "EHLO mx01.uni-tuebingen.de") by oss.sgi.com with ESMTP id ; Tue, 13 Jun 2000 15:15:09 -0700 Received: from mose.informatik.uni-tuebingen.de (root@p1ks227.extern.uni-tuebingen.de [134.2.226.227]) by mx01.uni-tuebingen.de (8.9.3/8.9.3) with ESMTP id AAA23362 for ; Wed, 14 Jun 2000 00:15:05 +0200 Received: (from mrvn@localhost) by mose.informatik.uni-tuebingen.de (8.9.3/8.9.3/Debian 8.9.3-21) id AAA01363; Wed, 14 Jun 2000 00:16:48 +0200 To: devfs@oss.sgi.com Subject: OT: devfs and /proc/mounts From: Goswin Brederlow Date: 14 Jun 2000 00:16:47 +0200 In-Reply-To: Richard Gooch's message of "Sat, 10 Jun 2000 22:01:51 -0600" Message-ID: <87d7llb50w.fsf_-_@mose.informatik.uni-tuebingen.de> Lines: 23 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Capitol Reef" Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing I'm using a 2.4.0-test1-ac7 kernel with devfs mounted automatically and /etc/mtab linked to /proc/mounts. /proc/mounts now contains the following: none / shm rw 0 0 none pipe: pipefs rw 0 0 none / proc rw 0 0 /dev/ide/host0/bus0/target0/lun0/part1 / ext2 rw 0 0 none /dev devfs rw 0 0 proc /proc proc rw 0 0 Now I kind of guess what shm and the first proc are for, but what is the pipefs doing there and what is it for? Does it need to be there? The problem is that programs like df or find (probably also tar), which use setmntent and stat the mountpoint, have problems with something mounted to "pipe:", which doesn't exist. MfG Goswin From owner-devfs@oss.sgi.com Tue Jun 13 15:19:01 2000 Received: by oss.sgi.com id ; Tue, 13 Jun 2000 15:18:41 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:9631 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Tue, 13 Jun 2000 15:18:35 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e5DMI0t13329; Tue, 13 Jun 2000 16:18:00 -0600 Date: Tue, 13 Jun 2000 16:18:00 -0600 Message-Id: <200006132218.e5DMI0t13329@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Goswin Brederlow Cc: devfs@oss.sgi.com Subject: Re: OT: devfs and /proc/mounts In-Reply-To: <87d7llb50w.fsf_-_@mose.informatik.uni-tuebingen.de> References: <87d7llb50w.fsf_-_@mose.informatik.uni-tuebingen.de> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Goswin Brederlow writes: > I'm using a 2.4.0-test1-ac7 kernel with devfs mounted automatically > and /etc/mtab linked to /proc/mounts. > > /proc/mounts now contains the following: > > none / shm rw 0 0 > none pipe: pipefs rw 0 0 > none / proc rw 0 0 > /dev/ide/host0/bus0/target0/lun0/part1 / ext2 rw 0 0 > none /dev devfs rw 0 0 > proc /proc proc rw 0 0 > > Now I kind of guess what shm and the first proc are for, but what is > the pipefs doing there and what is it for? I dunno what pipefs is needed for. I haven't tracked that discussion. However, what does this have to do with devfs? Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Tue Jun 13 21:08:26 2000 Received: by oss.sgi.com id ; Tue, 13 Jun 2000 21:08:16 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:26528 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Tue, 13 Jun 2000 21:07:56 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e5E477717373; Tue, 13 Jun 2000 22:07:07 -0600 Date: Tue, 13 Jun 2000 22:07:07 -0600 Message-Id: <200006140407.e5E477717373@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: linux-kernel@vger.rutgers.edu, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: [PATCH] devfs v99.16 available Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Hi, all. Version 99.16 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.2/devfs-patch-current.gz NOTE: the devfs-patch-v99.x patches are maintenance patches for the 2.2.x production kernels. Devfs development is done against recent development kernels. Occasionally, the latest devfs patch for the development kernels may be backported to 2.2.x series, but this happens rarely. This is against 2.2.16. Highlights of this release: - Back-ported fixes for Unix98 pty handling from v161 and v162 Thanks to Christian Czezatke (xS+S, Vienna ) - Back-ported removal of unnecessary call to in Thanks to Christian Czezatke (xS+S, Vienna ) Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Thu Jun 15 10:50:10 2000 Received: by oss.sgi.com id ; Thu, 15 Jun 2000 10:50:00 -0700 Received: from [141.201.223.25] ([141.201.223.25]:2569 "EHLO bread.lowtec.com") by oss.sgi.com with ESMTP id ; Thu, 15 Jun 2000 10:49:52 -0700 Received: from localhost (dent@localhost) by bread.lowtec.com (8.9.3/8.9.3) with ESMTP id UAA18322 for ; Thu, 15 Jun 2000 20:52:00 +0200 X-Authentication-Warning: bread.lowtec.com: dent owned process doing -bs Date: Thu, 15 Jun 2000 20:52:00 +0200 (CEST) From: "Thomas 'Dent' Mirlacher" To: devfs@oss.sgi.com Subject: raw devices 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 list, i'm new here, and i'm sorry if this is a question which is already covered in some FAQ - but i didn't find it. so what's the best way to include raw disc access to the devfs? is the raw module just not registering itself (the rawctl device), or am i missing something? thanks in advance for your help ++dent -- Linux is no REVOLUTION - it's EVOLUTION at operating system level ;) From owner-devfs@oss.sgi.com Thu Jun 15 11:09:00 2000 Received: by oss.sgi.com id ; Thu, 15 Jun 2000 11:08:40 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:9892 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Thu, 15 Jun 2000 11:08:26 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e5FI7wo09486; Thu, 15 Jun 2000 12:07:58 -0600 Date: Thu, 15 Jun 2000 12:07:58 -0600 Message-Id: <200006151807.e5FI7wo09486@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: "Thomas 'Dent' Mirlacher" Cc: devfs@oss.sgi.com Subject: Re: raw devices In-Reply-To: References: Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Thomas Mirlacher writes: > hi list, > > i'm new here, and i'm sorry if this is a question which is already covered > in some FAQ - but i didn't find it. > > so what's the best way to include raw disc access to the devfs? > is the raw module just not registering itself (the rawctl device), > or am i missing something? The raw device isn't registering itself. Someone should write a patch and send it to Linus/Alan and Cc me. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Thu Jun 15 11:20:10 2000 Received: by oss.sgi.com id ; Thu, 15 Jun 2000 11:20:00 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:50715 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 15 Jun 2000 11:19:42 -0700 Received: from getafix.engr.sgi.com (getafix.engr.sgi.com [163.154.5.110]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA15042 for ; Thu, 15 Jun 2000 11:14:45 -0700 (PDT) mail_from (chait@getafix.engr.sgi.com) Received: from localhost (chait@localhost) by getafix.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id LAA10091; Thu, 15 Jun 2000 11:16:38 -0700 (PDT) Message-Id: <200006151816.LAA10091@getafix.engr.sgi.com> To: "Thomas 'Dent' Mirlacher" cc: devfs@oss.sgi.com, jwright@getafix.engr.sgi.com, mee@getafix.engr.sgi.com Subject: Re: raw devices In-reply-to: Your message of "Thu, 15 Jun 2000 20:52:00 +0200." Date: Thu, 15 Jun 2000 11:16:37 -0700 From: Chaitanya Tumuluri Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing On Thu, 15 Jun 2000 20:52:00 +0200, "Thomas 'Dent' Mirlacher" wrote: >hi list, > >i'm new here, and i'm sorry if this is a question which is already covered >in some FAQ - but i didn't find it. > >so what's the best way to include raw disc access to the devfs? >is the raw module just not registering itself (the rawctl device), >or am i missing something? > > thanks in advance for your help > > ++dent > >-- >Linux is no REVOLUTION - it's EVOLUTION at operating system level ;) Which raw i/o patch are you talking about? 2.2 or 2.3? In any event, the 2.3.99pre2 patch doesn't register itself with devfs, AFAIK. Will add it to the to do list. Cheers, -Chait. From owner-devfs@oss.sgi.com Thu Jun 15 11:22:20 2000 Received: by oss.sgi.com id ; Thu, 15 Jun 2000 11:22:10 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:49180 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 15 Jun 2000 11:21:57 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA15372 for ; Thu, 15 Jun 2000 11:16:59 -0700 (PDT) mail_from (tduffy@dbear.engr.sgi.com) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id LAA42776 for ; Thu, 15 Jun 2000 11:20:10 -0700 (PDT) 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 LAA56758; Thu, 15 Jun 2000 11:18:23 -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 LAA12417; Thu, 15 Jun 2000 11:18:21 -0700 Date: Thu, 15 Jun 2000 11:18:21 -0700 (PDT) From: Thomas Duffy To: Richard Gooch cc: "Thomas 'Dent' Mirlacher" , devfs@oss.sgi.com, Jeremy Brown Subject: Re: raw devices In-Reply-To: <200006151807.e5FI7wo09486@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 Jeremy Brown here at sgi is working on adding raw device names in devfsd -- basically, devfsd would create all the raw device names using the akward mechanism currently available and then users would not have to worry about this. I cc'd him on this message because I am not sure the timeline for this, but I think we want to get it into our 1.4 product which is tentatively scheduled for August release. -tduffy On Thu, 15 Jun 2000, Richard Gooch wrote: > Thomas Mirlacher writes: > > hi list, > > > > i'm new here, and i'm sorry if this is a question which is already covered > > in some FAQ - but i didn't find it. > > > > so what's the best way to include raw disc access to the devfs? > > is the raw module just not registering itself (the rawctl device), > > or am i missing something? > > The raw device isn't registering itself. Someone should write a patch > and send it to Linus/Alan and Cc me. > > Regards, > > Richard.... > Permanent: rgooch@atnf.csiro.au > Current: rgooch@ras.ucalgary.ca > From owner-devfs@oss.sgi.com Thu Jun 15 11:22:40 2000 Received: by oss.sgi.com id ; Thu, 15 Jun 2000 11:22:30 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:12708 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Thu, 15 Jun 2000 11:22:19 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e5FIM5g09696; Thu, 15 Jun 2000 12:22:05 -0600 Date: Thu, 15 Jun 2000 12:22:05 -0600 Message-Id: <200006151822.e5FIM5g09696@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Thomas Duffy Cc: "Thomas 'Dent' Mirlacher" , devfs@oss.sgi.com, Jeremy Brown Subject: Re: raw devices In-Reply-To: References: <200006151807.e5FI7wo09486@vindaloo.ras.ucalgary.ca> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Thomas Duffy writes: > Jeremy Brown here at sgi is working on adding raw device names in devfsd > -- basically, devfsd would create all the raw device names using the > akward mechanism currently available and then users would not have to > worry about this. Why not patch the kernel driver to create sensible raw device names? then devfsd can produce compatibility entries if required. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Thu Jun 15 12:25:02 2000 Received: by oss.sgi.com id ; Thu, 15 Jun 2000 12:24:51 -0700 Received: from [141.201.223.20] ([141.201.223.20]:7177 "EHLO bread.lowtec.com") by oss.sgi.com with ESMTP id ; Thu, 15 Jun 2000 12:24:37 -0700 Received: from localhost (dent@localhost) by bread.lowtec.com (8.9.3/8.9.3) with ESMTP id WAA18600; Thu, 15 Jun 2000 22:26:14 +0200 X-Authentication-Warning: bread.lowtec.com: dent owned process doing -bs Date: Thu, 15 Jun 2000 22:26:14 +0200 (CEST) From: "Thomas 'Dent' Mirlacher" To: Thomas Duffy cc: Richard Gooch , devfs@oss.sgi.com, Jeremy Brown Subject: Re: raw devices In-Reply-To: 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 Thu, 15 Jun 2000, Thomas Duffy wrote: > Jeremy Brown here at sgi is working on adding raw device names in devfsd > -- basically, devfsd would create all the raw device names using the > akward mechanism currently available and then users would not have to > worry about this. > > I cc'd him on this message because I am not sure the timeline for this, > but I think we want to get it into our 1.4 product which is tentatively > scheduled for August release. ok, great to hear - do you have a planned layout (by means of where do they appear in the devfs), or will the manich schme something like rdisc for a raw disc (which will probably the easiest for apps (just add an 'r' to the selected interface). > > > so what's the best way to include raw disc access to the devfs? > > > is the raw module just not registering itself (the rawctl device), > > > or am i missing something? > > > > The raw device isn't registering itself. Someone should write a patch > > and send it to Linus/Alan and Cc me. so since jeremy is already working on this, i guess it would be just overhead to write a patch by myself. ++dent -- Thomas Mirlacher Student of ComputerScience, University of Salzburg dent@cosy.sbg.ac.at http://www.cosy.sbg.ac.at/~dent From owner-devfs@oss.sgi.com Thu Jun 15 12:28:21 2000 Received: by oss.sgi.com id ; Thu, 15 Jun 2000 12:28:01 -0700 Received: from [141.201.223.20] ([141.201.223.20]:7945 "EHLO bread.lowtec.com") by oss.sgi.com with ESMTP id ; Thu, 15 Jun 2000 12:27:47 -0700 Received: from localhost (dent@localhost) by bread.lowtec.com (8.9.3/8.9.3) with ESMTP id WAA18610; Thu, 15 Jun 2000 22:29:25 +0200 X-Authentication-Warning: bread.lowtec.com: dent owned process doing -bs Date: Thu, 15 Jun 2000 22:29:25 +0200 (CEST) From: "Thomas 'Dent' Mirlacher" To: Richard Gooch cc: Thomas Duffy , devfs@oss.sgi.com, Jeremy Brown Subject: Re: raw devices In-Reply-To: <200006151822.e5FIM5g09696@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 Thu, 15 Jun 2000, Richard Gooch wrote: > Thomas Duffy writes: > > Jeremy Brown here at sgi is working on adding raw device names in devfsd > > -- basically, devfsd would create all the raw device names using the > > akward mechanism currently available and then users would not have to > > worry about this. > > Why not patch the kernel driver to create sensible raw device names? > then devfsd can produce compatibility entries if required. since the rawdevices are 'new' at least they appeared only in the recent distributions (and redhat is using another scheme as proposed by the kernel docs), i don't think compatibility entries are required. but this means to have thw raw-stuff registering to the devfs quite soon, before too much apps are depending on the (kind of messed up) current naming scheme. ++dent -- Thomas Mirlacher Student of ComputerScience, University of Salzburg dent@cosy.sbg.ac.at http://www.cosy.sbg.ac.at/~dent From owner-devfs@oss.sgi.com Thu Jun 15 21:16:18 2000 Received: by oss.sgi.com id ; Thu, 15 Jun 2000 21:15:58 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:9637 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Thu, 15 Jun 2000 21:15:46 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e5G4FbT17285; Thu, 15 Jun 2000 22:15:37 -0600 Date: Thu, 15 Jun 2000 22:15:37 -0600 Message-Id: <200006160415.e5G4FbT17285@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: devfs@oss.sgi.com, linux-fsdevel@vger.rutgers.edu Cc: linux-kernel@vger.rutgers.edu Subject: [RFC] Devfs API changes: READ OR SUFFER Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Hi, all. It's been brought to my attention that has more parameters than it really needs (thanks, Al:-). So I'd like to know how much pain it would cause to change the API for this function. This is the best time to do it, before 2.4 is released. IF I GET NO RESPONSE, I'LL ASSUME NO-ONE CARES! And the next patch will change the API. The specific parameters I'm planning on removing are: - namelen: this is a minor optimsation that we don't really need (it may in fact be a de-optimisation on register-starved machines) - uid, gid: the only value that is ever passed is 0. Any other values would imply kernel/driver knowledge of /etc/passwd and /etc/group and/or some other kind of configuration file. If you really want a different uig/gid, use devfsd (which can change things before anything else in userspace can access the inode). For Unix98 pty's, an extra flag bit will suffice which will use current->uig/gid instead of 0. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Fri Jun 16 08:56:41 2000 Received: by oss.sgi.com id ; Fri, 16 Jun 2000 08:56:31 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:58021 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Fri, 16 Jun 2000 08:56:16 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e5GFsbY22716; Fri, 16 Jun 2000 09:54:37 -0600 Date: Fri, 16 Jun 2000 09:54:37 -0600 Message-Id: <200006161554.e5GFsbY22716@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: linux-kernel@vger.rutgers.edu, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: [PATCH] devfs v170 available Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Hi, all. Version 170 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 This is against 2.4.0-test1. Highlights of this release: - Updated README from master HTML file - Merged devfs inode into devfs entry Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Mon Jun 19 02:53:21 2000 Received: by oss.sgi.com id ; Mon, 19 Jun 2000 02:53:10 -0700 Received: from africon.co.za ([196.25.68.66]:53508 "EHLO mail1.int.africon.co.za") by oss.sgi.com with ESMTP id ; Mon, 19 Jun 2000 02:53:04 -0700 Received: by MAIL1 with Internet Mail Service (5.5.2650.21) id ; Mon, 19 Jun 2000 11:53:41 +0200 Message-ID: From: Jan-Albert Venter To: "'devfs@oss.sgi.com'" Subject: First time setup issues. Date: Mon, 19 Jun 2000 11:53:38 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Hi, following the instructions in the devfs doc's (downloaded from the homepage) I got most of my system working fine. There are however two things I couldn't do, 1) normal users cannot log on through the console, after logging in the console is cleared and a new login prompt appears I could however get root logon's working again. 2) using su normal_username I confirmed that I could not get startx to work from a user account, I tried to apply the patch as described in the doc's without success For the moment that's the only things I have had problems with. I am using RedHat 6.2 and kernel 2.4test1 TIA A.J. Venter Chairperson - Pretoria Linux Users Group http://www.plug.za.org Technician Africon CCS 082 494 54003 Room E103 From owner-devfs@oss.sgi.com Mon Jun 19 03:22:21 2000 Received: by oss.sgi.com id ; Mon, 19 Jun 2000 03:22:11 -0700 Received: from africon.co.za ([196.25.68.66]:45324 "EHLO mail1.int.africon.co.za") by oss.sgi.com with ESMTP id ; Mon, 19 Jun 2000 03:21:45 -0700 Received: by MAIL1 with Internet Mail Service (5.5.2650.21) id ; Mon, 19 Jun 2000 12:22:31 +0200 Message-ID: From: Jan-Albert Venter To: "'devfs@oss.sgi.com'" Subject: RE: First time setup issues. Date: Mon, 19 Jun 2000 12:22:28 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Sorry for the repost, I forgot another question, having done this, what happened to my old /dev files and entries, can i delete them ? how do I do that ? A.J. Venter Chairperson - Pretoria Linux Users Group http://www.plug.za.org Technician Africon CCS 082 494 54003 Room E103 -----Original Message----- From: Jan-Albert Venter Sent: 19 June 2000 11:54 To: 'devfs@oss.sgi.com' Subject: First time setup issues. Hi, following the instructions in the devfs doc's (downloaded from the homepage) I got most of my system working fine. There are however two things I couldn't do, 1) normal users cannot log on through the console, after logging in the console is cleared and a new login prompt appears I could however get root logon's working again. 2) using su normal_username I confirmed that I could not get startx to work from a user account, I tried to apply the patch as described in the doc's without success For the moment that's the only things I have had problems with. I am using RedHat 6.2 and kernel 2.4test1 TIA A.J. Venter Chairperson - Pretoria Linux Users Group http://www.plug.za.org Technician Africon CCS 082 494 54003 Room E103 From owner-devfs@oss.sgi.com Mon Jun 19 12:48:45 2000 Received: by oss.sgi.com id ; Mon, 19 Jun 2000 12:48:35 -0700 Received: from mx02.uni-tuebingen.de ([134.2.3.12]:6917 "EHLO mx02.uni-tuebingen.de") by oss.sgi.com with ESMTP id ; Mon, 19 Jun 2000 12:48:22 -0700 Received: from mose.informatik.uni-tuebingen.de (root@p1ks172.extern.uni-tuebingen.de [134.2.226.172]) by mx02.uni-tuebingen.de (8.9.3/8.9.3) with ESMTP id VAA31806; Mon, 19 Jun 2000 21:48:19 +0200 Received: (from mrvn@localhost) by mose.informatik.uni-tuebingen.de (8.9.3/8.9.3/Debian 8.9.3-21) id VAA25987; Mon, 19 Jun 2000 21:50:01 +0200 To: Jan-Albert Venter Cc: "'devfs@oss.sgi.com'" Subject: Re: First time setup issues. References: From: Goswin Brederlow Date: 19 Jun 2000 21:50:01 +0200 In-Reply-To: Jan-Albert Venter's message of "Mon, 19 Jun 2000 11:53:38 +0200" Message-ID: <87ya418n86.fsf@mose.informatik.uni-tuebingen.de> Lines: 37 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Capitol Reef" Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing >>>>> " " == Jan-Albert Venter writes: > Hi, following the instructions in the devfs doc's (downloaded > from the homepage) I got most of my system working fine. There > are however two things I couldn't do, > 1) normal users cannot log on through the console, after > logging in the console is cleared and a new login prompt > appears I could however get root logon's working again. Did you change /etc/securetty and /etc/inittab? If you use /dev/vc/? instead of /dev/tty? in both everything should work (even without devfsd). > 2) using su normal_username I confirmed that I could not get > startx to work from a user account, I tried to apply the patch > as described in the doc's without success Hmm, sorry, no clue. I use a framebuffer and the X for framebuffer. Works perfect on /dev/fb/0. > For the moment that's the only things I have had problems with. > I am using RedHat 6.2 and kernel 2.4test1 > Sorry for the repost, I forgot another question, having done > this, what happened to my old /dev files and entries, can i > delete them ? how do I do that ? When you have the devfs to be mounted automatically at bootup you can delet the files in dev, but better move the old directory to /dev.old and make a new /dev (for testing if it realy works). To do that, you need to unmount the devfs (hope you can do that, maybe only in single user mode). If nothing works, boot a rescue disk and move dev to dev.old and make a new directory /dev. May the Source be with you. Goswin From owner-devfs@oss.sgi.com Mon Jun 19 13:20:35 2000 Received: by oss.sgi.com id ; Mon, 19 Jun 2000 13:20:16 -0700 Received: from firewall-in.sch57.msk.ru ([195.178.195.6]:49928 "EHLO dell.sch57.msk.ru") by oss.sgi.com with ESMTP id ; Mon, 19 Jun 2000 13:19:52 -0700 Received: from khim.UUCP (uucp@localhost) by dell.sch57.msk.ru (8.8.8/8.8.8) with UUCP id AAA08023; Tue, 20 Jun 2000 00:09:42 +0400 Received: by khim.sch57.msk.ru (dMail for DOS v2.07a2, 12Jun98); Tue, 20 Jun 2000 00:09:22 +0400 To: goswin.brederlow@student.uni-tuebingen.de, JAVenter@africon.co.za Cc: devfs@oss.sgi.com References: <87ya418n86.fsf@mose.informatik.uni-tuebingen.de> Message-Id: Organization: MCCME From: "Khimenko Victor" Date: Tue, 20 Jun 2000 00:09:22 +0400 (MSD) X-Mailer: dMail [Demos Mail for DOS v2.07a2] Subject: Re: First time setup issues. Lines: 19 MIME-Version: 1.0 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 19-Jun-00 21:50 you wrote: >> For the moment that's the only things I have had problems with. >> I am using RedHat 6.2 and kernel 2.4test1 >> Sorry for the repost, I forgot another question, having done >> this, what happened to my old /dev files and entries, can i >> delete them ? how do I do that ? > When you have the devfs to be mounted automatically at bootup you can > delet the files in dev, but better move the old directory to /dev.old > and make a new /dev (for testing if it realy works). To do that, you > need to unmount the devfs (hope you can do that, maybe only in single > user mode). If nothing works, boot a rescue disk and move dev to > dev.old and make a new directory /dev. Unfortunatelly it's the only choice :-/ Not even in single mode you can unmount /dev (init and kernel itself needs it - that's why it's automounted in kernel and not from init scripts, BTW). From owner-devfs@oss.sgi.com Tue Jun 20 08:22:16 2000 Received: by oss.sgi.com id ; Tue, 20 Jun 2000 08:22:06 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:52139 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Tue, 20 Jun 2000 08:21:48 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e5KFKuh32738; Tue, 20 Jun 2000 09:20:56 -0600 Date: Tue, 20 Jun 2000 09:20:56 -0600 Message-Id: <200006201520.e5KFKuh32738@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: linux-kernel@vger.rutgers.edu, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: [PATCH] devfs v171 available Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Hi, all. Version 171 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 This is against 2.4.0-test2-pre3. Highlights of this release: - Updated sample modules.conf - Removed dead code in which used to call - Ported to kernel 2.4.0-test2-pre3 Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Wed Jun 21 05:16:24 2000 Received: by oss.sgi.com id ; Wed, 21 Jun 2000 05:16:14 -0700 Received: from neper.ethz.ch ([129.132.61.59]:58379 "EHLO neper.ethz.ch") by oss.sgi.com with ESMTP id ; Wed, 21 Jun 2000 05:16:08 -0700 Received: from cate (helo=localhost) by neper.ethz.ch with local-esmtp (Exim 3.12 #1 (Debian)) id 134jPA-00026F-00 for ; Wed, 21 Jun 2000 14:14:52 +0200 Date: Wed, 21 Jun 2000 14:14:52 +0200 (CEST) From: Giacomo Catenazzi To: devfs@oss.sgi.com Subject: Possible problems of /dev/discs/disc? name scheme In-Reply-To: <20000621120920Z42363-29270+97@oss.sgi.com> 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! I've a IDE hard disk in /dev/discs/disc0 and when pluged also a IOMAGE external zip drive (Paralel port with SCSI drivers) in /dev/discs/disc1. Problem: If I decide to install a new IDE harddisk, all my configurations are wrong. I don't see in documentation how to force the new drive IDE to be disc2. There are a simpler methods? How to handle this? giacomo From owner-devfs@oss.sgi.com Wed Jun 21 08:20:36 2000 Received: by oss.sgi.com id ; Wed, 21 Jun 2000 08:20:26 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:24749 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Wed, 21 Jun 2000 08:20:14 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e5LFKCb13136; Wed, 21 Jun 2000 09:20:12 -0600 Date: Wed, 21 Jun 2000 09:20:12 -0600 Message-Id: <200006211520.e5LFKCb13136@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Giacomo Catenazzi Cc: devfs@oss.sgi.com Subject: Re: Possible problems of /dev/discs/disc? name scheme In-Reply-To: References: <20000621120920Z42363-29270+97@oss.sgi.com> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Giacomo Catenazzi writes: > Hi! > > I've a IDE hard disk in /dev/discs/disc0 and when pluged also a IOMAGE > external zip drive (Paralel port with SCSI drivers) in /dev/discs/disc1. > > Problem: > If I decide to install a new IDE harddisk, all my configurations are > wrong. > I don't see in documentation how to force the new drive IDE to be disc2. > > There are a simpler methods? How to handle this? Use the names under /dev/ide, of course. And if they are too long, use devfsd to access shorter names. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Wed Jun 21 10:07:47 2000 Received: by oss.sgi.com id ; Wed, 21 Jun 2000 10:07:26 -0700 Received: from neper.ethz.ch ([129.132.61.59]:14604 "EHLO neper.ethz.ch") by oss.sgi.com with ESMTP id ; Wed, 21 Jun 2000 10:07:09 -0700 Received: from cate (helo=localhost) by neper.ethz.ch with local-esmtp (Exim 3.12 #1 (Debian)) id 134nwg-0002EM-00; Wed, 21 Jun 2000 19:05:46 +0200 Date: Wed, 21 Jun 2000 19:05:46 +0200 (CEST) From: Giacomo Catenazzi To: Richard Gooch cc: devfs@oss.sgi.com Subject: Re: Possible problems of /dev/discs/disc? name scheme In-Reply-To: <200006211520.e5LFKCb13136@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 Wed, 21 Jun 2000, Richard Gooch wrote: > Giacomo Catenazzi writes: > > Hi! > > > > I've a IDE hard disk in /dev/discs/disc0 and when pluged also a IOMAGE > > external zip drive (Paralel port with SCSI drivers) in /dev/discs/disc1. > > > > Problem: > > If I decide to install a new IDE harddisk, all my configurations are > > wrong. > > I don't see in documentation how to force the new drive IDE to be disc2. > > > > There are a simpler methods? How to handle this? > > Use the names under /dev/ide, of course. And if they are too long, use > devfsd to access shorter names. > Ok. But why do /dev/discs/* exist? IMHO people use (will use) /dev/discs to configure their box. Only after some time they upgrade the system, and the translation /dev/discs in /dev/{ide,scsi} will be difficult. It should be a method to force discs to be loaded in a user choice order giacomo From owner-devfs@oss.sgi.com Wed Jun 21 10:12:46 2000 Received: by oss.sgi.com id ; Wed, 21 Jun 2000 10:12:26 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:34733 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Wed, 21 Jun 2000 10:12:11 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e5LHC3S14577; Wed, 21 Jun 2000 11:12:03 -0600 Date: Wed, 21 Jun 2000 11:12:03 -0600 Message-Id: <200006211712.e5LHC3S14577@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Giacomo Catenazzi Cc: devfs@oss.sgi.com Subject: Re: Possible problems of /dev/discs/disc? name scheme In-Reply-To: References: <200006211520.e5LFKCb13136@vindaloo.ras.ucalgary.ca> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Giacomo Catenazzi writes: > > > On Wed, 21 Jun 2000, Richard Gooch wrote: > > > Giacomo Catenazzi writes: > > > Hi! > > > > > > I've a IDE hard disk in /dev/discs/disc0 and when pluged also a IOMAGE > > > external zip drive (Paralel port with SCSI drivers) in /dev/discs/disc1. > > > > > > Problem: > > > If I decide to install a new IDE harddisk, all my configurations are > > > wrong. > > > I don't see in documentation how to force the new drive IDE to be disc2. > > > > > > There are a simpler methods? How to handle this? > > > > Use the names under /dev/ide, of course. And if they are too long, use > > devfsd to access shorter names. > > > > Ok. > But why do /dev/discs/* exist? Because Linus wanted them for "simple" systems. > IMHO people use (will use) /dev/discs to configure their box. Only > after some time they upgrade the system, and the translation > /dev/discs in /dev/{ide,scsi} will be difficult. It should be a > method to force discs to be loaded in a user choice order It's up to distribution vendors to decide what they want to encourage (i.e. use as the default). If it turns out that /dev/discs/ turns out to be of minor practical value, feel free to tell Linus he was wrong. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Wed Jun 21 10:22:26 2000 Received: by oss.sgi.com id ; Wed, 21 Jun 2000 10:22:16 -0700 Received: from nat-su-33.valinux.com ([198.186.202.33]:16401 "EHLO phenoxide.su.varesearch.com") by oss.sgi.com with ESMTP id ; Wed, 21 Jun 2000 10:22:06 -0700 Received: (from jerdfelt@localhost) by phenoxide.su.varesearch.com (8.9.3/8.9.3) id KAA07115 for devfs@oss.sgi.com; Wed, 21 Jun 2000 10:22:04 -0700 Date: Wed, 21 Jun 2000 10:22:04 -0700 From: Johannes Erdfelt To: devfs@oss.sgi.com Subject: [draft] Hotswap and Linux Message-ID: <20000621102204.A6504@valinux.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing This is a little white paper that I've been working on about Linux and Hot-Swap and all of the associated problems. It's a first draft and I'd appreciate any feedback. --------------------------------------------------------------------- 1. Introduction I wrote this small white paper about hot-swap and Linux because in dealing with the problem with my work for Linux USB, I saw a significant amount of misunderstanding about the topic within the kernel development community. I've been developer working on USB support for Linux for the past year when the first driver went into the main kernel tree. I have written a significant portion of the code for the USB support in Linux. I'm trying to make this white paper generic enough to explain and tackle the hot-swap problems in Linux, but I'm most familiar with USB and thusly much of the paper will revolve around my experience with USB in particular. Note: I will mention permissions extensively. When I say this I mean both permissions (read, write, etc) and ownership (uid, gid) for the device node. 2. Hot-Swap Interfaces A hot-swap interface is any interface to a computer which you can plug and unplug devices while the machine is running. Insertion and removal does not necessarily need to happen while the machine is running, it can happen while the machine is off or in a power saving mode. There are a couple of commonly seen hot-swap interfaces on today's PCs. Some are generally seen on desktops (USB, IEEE 1394) or notebooks (PCMCIA, USB, IEEE 1394) while some may be seen on servers (Hot-Swap PCI, SCSI). However, as is often the case with the computer industry, technologies blur and USB is being seen on servers and Hot-Swap PCI and Hot-Swap SCSI technologies will eventually find their way to desktops. PCMCIA, or more specifically CardBus, is essentially a form of Hot-Swap PCI. However, they are different enough to mention seperately. Most of the interfaces are busses, allowing multiple devices to be connected. However, things like parport could also be considered a hot-swap interface. 2.1 PCMCIA This was one of the first hot-swap interfaces that came to PC's. It is a compact form factor system bus interface. It looks like an ISA or PCI bus (greatly simplified description) to the system. It is a part of the system bus. 2.2 SCSI I'm not an expert on SCSI, but I know that SCSI has supported hot-swap devices for a while in some situations. It is a higher level bus than the system bus. 2.3 Hot-Swap PCI Hot-Swap PCI is relatively recent which is mainly seen in servers. It simply adds Hot-Swap capability to PCI (correct?) PCMCIA (CardBus) and Hot-Swap PCI are very similar technologies. It is a part of the system bus. 2.4 IEEE 1394 This is commonly called by it's trade names Firewire (Apple) or iLink (Sony). It is very similar to USB but is not as widely adopted. It is a higher level bus than the system bus. 2.5 USB Universal Serial Bus was originally introduced a couple of years ago and has recently seen widespread adoption (iMac, etc). It is a higher level bus than the system bus. 3. Linux and Hot-Swap problems Unix and more specifically Linux handle hot-swap devices very poorly. Much of the architecture of the OS assumes static or semi-static hardware configurations. This has not been a problem with Linux until recently as hot-swap interfaces are a relatively recent addition to the kernel. 3.1 Device Naming Devices are named on a first come, first served basis. For instance, when the OS probes for SCSI devices, the first hard drive is assigned major/minor 8/0. The second harddrive is assigned major/minor 8/16. Traditional device nodes under Linux for these devices are /dev/sda and /dev/sdb respectively. When a device can be inserted or removed randomly, as in the case of a hot-swap interface, the probing order becomes random. Since Linux still uses a first come first served naming scheme, the device nodes name can be essentially random. The name is not guaranteed to be the same each time the device is inserted. Most applications are configured with static device names. Using hot-swap devices with these applications is troublesome. 3.2 Device Permissions Linux and most every other Unix, stores permissions for a device in the filesystem. Those are associated with the name of the device (/dev/sda). Since we cannot guarantee the same name each time a device is inserted (see 3.1), we cannot guarantee the device has the correct or same permissions. Tracking devices should be done by tracking characteristics of the device not the name of the device node corresponding to the device. 3.3 Enumeration and Driver Binding Many of today's interfaces offer complicated device structure. Some allow multiple logical functions in one physical device, along with multiple interfaces of varying complexity. Selecting the correct configuration parameters can be complicated. USB has the notion of configurations, interfaces, alternate settings and endpoints. Choosing which configuration or alternate setting to use, or what drivers to bind to each interface is complicated and involves user defined policy. 3.4 Logical Function to Physical Device Association Given a logical function of a device (say a SCSI drive, /dev/sdb) I cannot determine what physical device it is. For instance, I plug in a USB floppy drive. It appears as SCSI device /dev/sdb. I cannot accurately determine that /dev/sdb is associated with the device I just plugged in. 3.5 Userspace API Hot-Swap interfaces that are not system busses can often export a userspace visible API which can move complex code out of the kernel core and into userspace for a variety of reasons. There are many complicated issues with this that are interface specific. 4. Existing Solutions The problem of hot-swap has been tackled in the past at varying levels of complexity and varying levels of effectiveness. 4.1 PCMCIA/Carbus PCMCIA (and Carbus, however I will use PCMCIA to cover both technologies) has been supported by Linux for a couple of releases and has been the mostly widely used hot-swap interface. It thusly has ran into many of these problems for a while and a series of solutions have been developed with a varying degree of effectiveness. The core of their solution is the Card Manager. The PCMCIA card manager is notified by the kernel when a device insertion or removal occurs on any PCMCIA bus. It obtains from the kernel information about the device. It then executes an arbitrary algorithm to select the driver, loads a kernel module if necessary for the driver, and then binds the device to the driver. It can also execute programs (shell scripts being the most common) to configure the device in a flexible manner. 4.1.1 PCMCIA and Device Naming The shell scipts used to configure devices can be setup to create symlinks to keep one name for a device. This has the unfortunate side-effect of hardcoding names in shell scripts. It does not dynamically handle multiple similar devices. 4.1.2 PCMCIA and Device Permissions The same shell scripts that configure the device, can be used to create and apply permissions to device nodes. This has the same problem as Device Naming in that it requires hard coded configuration in shell scripts. 4.1.3 PCMCIA and Enumeration and Driver Binding As explained earlier, the Card Manager works with the kernel to enumerate and bind drivers to devices. 4.1.4 PCMCIA and Logical Function to Physical Device Association >From David Hinds: "Each socket has a minor device that cardmgr, etc use for the ioctl interface and to watch for card status events. The DS_GET_DEVICE_INFO ioctl gives a list of device descriptors associated with that socket. So it is domain specific in that you know in advance what physical device you're asking about." 4.1.5 PCMCIA and Userspace API Since PCMCIA is a system bus, it uses the same architecture defined access to devices. This includes IRQ's, DMA channels, I/O ports, memory ranges, etc. The existing userspace API's for this are used. The existing API is limited to I/O port and memory access. 4.2 scsidev scsidev scans /proc/scsi and creates device nodes in /dev dynamically depending on the devices on the SCSI busses. 4.3 Anymore? I don't know of any others. Any help? 5. USB Related Problems These are problems not necessarily related to the hot-swap nature of USB, but are important to understand for making decisions about appropriate solutions. 5.1 Complex Structure of USB Devices This was touched on in section 3.3 (Enumeration and Driver Binding). Each USB device can have multiple configurations. Only one configuration can be active at once. Each configuration has multiple interfaces. Each interface offers a logical function of the device. They are all active at once. Each interface has an alternate setting. Alternate settings select how much bandwidth a device uses, programming interface, etc. Only one alternate setting can be active at a time per interface. Each alternate setting has 1 or more endpoints. To make things more complicated, the entire device has one control endpoint, shared among every interface. This control interface is required to configure generic device parameters as well as parameters specific to each interface. Since each interface is a logical function of the device, separate permissions are required. Thusly, multiple device nodes are required for one device. Tracking permissions for the device then entails tracking the device and the permissions for each interface. A quick summary, one device node is not sufficient to describe the device and the layout of the device can wildly change from device to device and configuration to configuration. 5.2 Userspace API This was touched on in section 3.5 (Userspace API). PCMCIA and Hot-Swap PCI do not have userspace API's because they are system busses and are complicated to support correctly and guarantee security of the system. USB, IEEE 1394 and SCSI are higher level busses and do not suffer from the problems that system busses have with respect to userspace access. USB has usbdevfs. There are two portions to this. The first is the virtual filesystem portion which dynamically creates and deletes device nodes (actually files, since no major/minor is needed). This is needed because of the problem described in section 5.1. The second portion is the actual file operations. This is a series of open(), ioctl(), read(), write() and close() functions which provide a variety of operations to userspace programs. The existing userspace solution overloads one device node with ioctl's for each transfer type and feature for all endpoints (and thusly interfaces). The existing implemented solution will not be the final solution since it has a variety of problems. 6. My Solution for USB I've been working on this problem with respect to USB for the past couple of months. I've had many an email discussion with many people about this. The solution I've worked on does not solve problem 3.1 (Device naming) yet. However, I attempted to design a solution which does not preclude solving this in the future. This solution is implemented using devfs and devfsd. 6.1 Required Features for the solution Some people have had the misconception that this locks everyone into devfs to use USB. This is not the case. It locks us into a certain feature set that must be supported. In the case right now, devfs is the only solution which offers all of the infrastructure needed. I cannot see how hot-swap can be implemented in a clean way without these requirements. 6.1.1 Dynamic creation of device nodes Once configurations and alternate settings are selected, the number of interfaces, endpoints can radically change. 6.1.2 No fixed limit on device nodes The structure and layout of device nodes is sparse and complicated quickly outgrowing the entire major/minor space as currently implemented. This is required to solve the problem described in section 4.2 6.1.3 VFS intercepts for common syscalls (chmod, chown, etc) To properly track device permissions, we need to know when permissions are changed for device nodes so the permissions can be saved in a database along with other identifying information about the device. This is required to solve the problem described in section 3.2 6.1.4 VFS intercepts to load modules on demand Part of the design will track devices and their logical functions. The VFS can intercept open() calls for devices and load modules on demand. 6.2 Goals There were goals I strived to meet while I create this solutions 6.2.1 Minimal code duplication More and more hot-swap interfaces are coming up and they will all be supported. Each solution will have common features which overlap with all of the other solutions. For instance, notification of insertion and removal to userspace. PCMCIA already has this and USB needs it as well. This also minimizes the impact into unswappable kernel memory and kernel image size. 6.2.2 Intuitive and Clean Architecture Some other solutions had been suggested to dynamically negotiate minor numbers between kernel and user space for device nodes. This is not clean nor intuitive and is just a kludge. (Nor does this solution meet all of the requirements) The solution must be designed to stand up for the future. 6.2.3 Userfriendly Solution To meet this goal, I used gphoto as my test application. I have written code for USB support which has been adopted by the gphoto development team. A user should be able to plug in his camera, and change permissions at most once. It should present the user with cameras on the bus (to the extent that gphoto knows about it) and be able to use it without an overhead of administration each time the camera is connected. 6.3 What I did NOT attempt to solve I did not attempt to solve device naming yet. This is a problem, but the best solution that was offered that did not require kernel interaction was symlinks. This could become unwieldly with the configurations of some systems. Requiring kernel side support may be a requirement unfortunately. I welcome any thoughts on this topic. Also, please don't confuse logical device naming (/dev/sda, /dev/sdb) with physical device naming (/dev/usb/bus1/device1). There is no solution to solving USB physical device naming, nor is there much desire to do so. 6.4 Description of solution The core of the solution is devfs and devfsd. Using devfs allows us to meet goals 6.2.1 (Code Duplication) and 6.2.2 (Intuitive and Clean Architecture) immediately. devfs centralizes much of the common code, such as the kernel to userspace channel to communicate device insertions, removals, chmod calls, etc. It also avoids creating extra VFS' for each hot-swap bus like usbdevfs is currently implemented. It also allows us to easily solve problems 5.1 (Complex structure of USB devices) and 5.2 (Userspace API), which are related. The solution I propose removes the virtual filesystem portion of usbdevfs and keeps the file operations only. Most of the smarts are in devfsd. I've used the devfsd MFUNCTION to intercept REGISTER, UNREGISTER and CHANGE events. This allows us to see the insertion and removal of the device, changes to the permissions of the device, as well as open() calls on devices with modules that are not loaded. 6.4.1 USB and Logical Function to Physical Device Association Using a design from David Hinds (maintainer of the Linux PCMCIA code) I propose we create a generic ioctl() interface which can be used to retrieve physical device data for a given logical device. This data will domain specific and specific to each hot-swap interface. An alternative solution is to use devfs to create logical device nodes as a bus specific node, and create symlinks (/dev/scsi/host0/bus0/target0 -> /dev/usb/device1/scsi/target0 or something similar). Both solutions have strengths and weaknesses. An alternative solution may also be better. I am confident there is a solution to this problem. 6.4.2 Processing on REGISTER events When a REGISTER event occurs, the module obtains the descriptors for the device and parses them, determining which configurations, interfaces and alternate settings are available on the device. It then executes an arbitrary algorithm (not explained here for brevity) to select a configuration, then select alternate settings and drivers for each interface. The software then programs the active configuration and the active alternate setting for each interface. If the driver must be loaded at insertion time, instead of at use time, the driver will be loaded, binds the driver to the interfaces necessary and activates the interface. The module then obtains unique or semi-unique characteristics from the device and retrieves any previously saved permissions for the device. If no information is retrieved from the local database, default values from the configuration can be applied to the device. Lastly, a script is executed to perform any local device configuration necessary. For instance, a script can be used to configure an ethernet device. 6.4.3 Processing on UNREGISTER events On an UNREGISTER event, the device is deleted from all internal lists. 6.4.4 Processing on CHANGE events On a CHANGE event, unique and semi-unique characteristics are obtained from the device and saved in a database along with the new permissions for later retrieval. 7. Future work The work I've done is not just applicable to USB. Many other systems can use similar algorithms and code. Although I specifically focused on Hot-Swap interfaces, all interfaces can be used with the proposed solution since their configuration can be changed when the power is off. Since this is required of Hot-Swap interfaces, "normal" interfaces can be treated the same but with a subset of functionality (not Hot-Swap). 7.1 PCMCIA/Cardbus A solution similar to this could be implemented to replace the card manager and centralize duplicated code and interfaces. David Hinds has expressed interest in working on a common solution for hot-swap interfaces. My solution has involved some ideas from him, but he probably isn't comfortable with it yet since we have not talked about it or any specific solutions. 7.2 SCSI Many, if not all, modern SCSI devices have a unique identifiers which could be used to devices. This could be used to track permissions on SCSI generic devices (CD burners, scanners, etc) as well as the logical function. 7.3 PCI The same driver binding code could be used with a different algorithm to automatically load and bind drivers for hot-swap PCI devices. This, as mentioned previously, ties into PCMCIA/Cardbus. 7.4 ALSA A similar, but different, problem exists for ALSA. Most devices supported under ALSA export many interfaces to control the device. To appropriately solve this problem, the ALSA team overloads /proc with the device nodes it needs. Permissions aren't tracked for the device nodes. 8. Closing Remarks I expect tweaks to be made when I get input from the kernel developer community at large, including those other subsystem that may be affected including PCMCIA, Hot-Swap PCI, IEEE1394 and SCSI. Hot-swap support is necessary for Linux. I don't think anyone will disagree that the current framework for hot-swap interfaces is severely lacking and requires a significant amount of work to help solve many of the problems discussed. I also want to reiterate that while I am actively pushing devfs right now, that is because it's the best solution available. If an alternative solution is developed, and is better, then I am interested in hearing about it. Also, please help clear up some of the terminology and descriptions. I admit my english and explanations can suck. JE From owner-devfs@oss.sgi.com Wed Jun 21 17:42:40 2000 Received: by oss.sgi.com id ; Wed, 21 Jun 2000 17:42:30 -0700 Received: from mx02.uni-tuebingen.de ([134.2.3.12]:55054 "EHLO mx02.uni-tuebingen.de") by oss.sgi.com with ESMTP id ; Wed, 21 Jun 2000 17:42:03 -0700 Received: from mose.informatik.uni-tuebingen.de (root@p1ks018.extern.uni-tuebingen.de [134.2.226.18]) by mx02.uni-tuebingen.de (8.9.3/8.9.3) with ESMTP id CAA06958; Thu, 22 Jun 2000 02:41:41 +0200 Received: (from mrvn@localhost) by mose.informatik.uni-tuebingen.de (8.9.3/8.9.3/Debian 8.9.3-21) id CAA03538; Thu, 22 Jun 2000 02:43:02 +0200 To: Giacomo Catenazzi Cc: devfs@oss.sgi.com Subject: Re: Possible problems of /dev/discs/disc? name scheme References: From: Goswin Brederlow Date: 22 Jun 2000 02:42:49 +0200 In-Reply-To: Giacomo Catenazzi's message of "Wed, 21 Jun 2000 14:14:52 +0200 (CEST)" Message-ID: <87k8fi4kc6.fsf@mose.informatik.uni-tuebingen.de> Lines: 27 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Capitol Reef" Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing >>>>> " " == Giacomo Catenazzi writes: > Hi! I've a IDE hard disk in /dev/discs/disc0 and when pluged > also a IOMAGE external zip drive (Paralel port with SCSI > drivers) in /dev/discs/disc1. > Problem: If I decide to install a new IDE harddisk, all my > configurations are wrong. I don't see in documentation how to > force the new drive IDE to be disc2. > There are a simpler methods? How to handle this? The best way to handle stuff like this I found is to use lables. Stick e2lables on all your filesystems and mount them by lable. If you sort the drives differently (like when adding a drive), the lables will be the same and everything works fine. Only problem would be swap. I though about using disk lables to create /dev/discs//partX and /dev/discs//, but never got around to do it yet. MfG Goswin From owner-devfs@oss.sgi.com Wed Jun 21 22:19:51 2000 Received: by oss.sgi.com id ; Wed, 21 Jun 2000 22:19:41 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:10418 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Wed, 21 Jun 2000 22:19:20 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e5M5Ih219421; Wed, 21 Jun 2000 23:18:43 -0600 Date: Wed, 21 Jun 2000 23:18:43 -0600 Message-Id: <200006220518.e5M5Ih219421@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: linux-kernel@vger.rutgers.edu, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: [PATCH] devfs v172 available Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Hi, all. Version 172 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 This is against 2.4.0-test2-pre8. Highlights of this release: - Changed interface to - Changed interface to Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Thu Jun 22 05:49:34 2000 Received: by oss.sgi.com id ; Thu, 22 Jun 2000 05:49:24 -0700 Received: from africon.co.za ([196.25.68.66]:23054 "EHLO mail1.int.africon.co.za") by oss.sgi.com with ESMTP id ; Thu, 22 Jun 2000 05:49:14 -0700 Received: by MAIL1 with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Jun 2000 14:49:53 +0200 Message-ID: From: Jan-Albert Venter Cc: devfs@oss.sgi.com Subject: RE: First time setup issues. Date: Thu, 22 Jun 2000 14:49:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" To: unlisted-recipients:; (no To-header on input) Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Hi, new litle problem, when trying to mount my floppy on either /dev/fd0 or /dev/floppy/(anything tried them all) I get an error of /dev/fd0 has wrong major or minor number I thought major and minor numbers didn't exist in devfs. How now ? A.J. Venter Chairperson - Pretoria Linux Users Group http://www.plug.za.org Technician Africon CCS 082 494 54003 Room E103 From owner-devfs@oss.sgi.com Thu Jun 22 22:19:24 2000 Received: by oss.sgi.com id ; Thu, 22 Jun 2000 22:19:14 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:57524 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Thu, 22 Jun 2000 22:18:58 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e5N5HxQ31291; Thu, 22 Jun 2000 23:17:59 -0600 Date: Thu, 22 Jun 2000 23:17:59 -0600 Message-Id: <200006230517.e5N5HxQ31291@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: linux-kernel@vger.rutgers.edu, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: [PATCH] devfs v173 available Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Hi, all. Version 173 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 This is against 2.4.0-test2-pre11. Highlights of this release: - Simplified interface to - Simplified interface to - Simplified interface to Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Sat Jun 24 12:22:30 2000 Received: by oss.sgi.com id ; Sat, 24 Jun 2000 12:22:20 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:6839 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Sat, 24 Jun 2000 12:21:52 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e5OJLGX12117; Sat, 24 Jun 2000 13:21:16 -0600 Date: Sat, 24 Jun 2000 13:21:16 -0600 Message-Id: <200006241921.e5OJLGX12117@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Johannes Erdfelt Cc: devfs@oss.sgi.com Subject: Re: [draft] Hotswap and Linux In-Reply-To: <20000621102204.A6504@valinux.com> References: <20000621102204.A6504@valinux.com> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Johannes Erdfelt writes: > This is a little white paper that I've been working on about Linux and > Hot-Swap and all of the associated problems. > > It's a first draft and I'd appreciate any feedback. This is good work. Could you please make this available as a nice HTML document and put it up on the WWW somewhere? I'd like to link the devfs FAQ to it. I have some minor nits to pick: > 2. Hot-Swap Interfaces > > A hot-swap interface is any interface to a computer which you can plug > and unplug devices while the machine is running. Insertion and removal > does not necessarily need to happen while the machine is running, it can ^^^^ ^^ I think "do" and "they" are more correct. > happen while the machine is off or in a power saving mode. > > 2.3 Hot-Swap PCI > > Hot-Swap PCI is relatively recent which is mainly seen in servers. It ^^^^^ "and" > 3.4 Logical Function to Physical Device Association > > Given a logical function of a device (say a SCSI drive, /dev/sdb) I cannot > determine what physical device it is. > > For instance, I plug in a USB floppy drive. It appears as SCSI device ^^^^^^^^^^ I'd suggest "corresponds to", so that it drives home the point that without devfs, device nodes do not "appear" when you plug devices in. > 4.2 scsidev > > scsidev scans /proc/scsi and creates device nodes in /dev dynamically > depending on the devices on the SCSI busses. Might be worth highlighting that it's only good for SCSI, and isn't conducive to adapting to other device types (I've got more detail in the devfs FAQ). > 6.1 Required Features for the solution > > Some people have had the misconception that this locks everyone into devfs > to use USB. This is not the case. It locks us into a certain feature set > that must be supported. > > In the case right now, devfs is the only solution which offers all of the > infrastructure needed. > > I cannot see how hot-swap can be implemented in a clean way without these > requirements. "without these required features" may be better. > 6.1.1 Dynamic creation of device nodes > > Once configurations and alternate settings are selected, the number of > interfaces, endpoints can radically change. ^ "and" > 6.1.2 No fixed limit on device nodes > > The structure and layout of device nodes is sparse and complicated append comma > quickly outgrowing the entire major/minor space as currently implemented. > > This is required to solve the problem described in section 4.2 > > 6.1.4 VFS intercepts to load modules on demand > > Part of the design will track devices and their logical functions. The > VFS can intercept open() calls for devices and load modules on demand. Don't you really mean stat(2) calls (in fact, inode lookups)? > 6.2 Goals > > There were goals I strived to meet while I create this solutions ^ singular > 6.2.1 Minimal code duplication > > More and more hot-swap interfaces are coming up and they will all be > supported. Each solution will have common features which overlap with > all of the other solutions. For instance, notification of insertion and > removal to userspace. PCMCIA already has this and USB needs it as well. > > This also minimizes the impact into unswappable kernel memory and kernel ^^^^ "on" > 6.2.2 Intuitive and Clean Architecture > > Some other solutions had been suggested to dynamically negotiate minor > numbers between kernel and user space for device nodes. This is not clean > nor intuitive and is just a kludge. (Nor does this solution meet all of > the requirements) It would help to list those proposed solutions and explain what's wrong with them. I'll probably steal bits of said material for the devfs FAQ. > 6.3 What I did NOT attempt to solve > > I did not attempt to solve device naming yet. This is a problem, but > the best solution that was offered that did not require kernel > interaction was symlinks. This could become unwieldly with the > configurations of some systems. Requiring kernel side support may be > a requirement unfortunately. I welcome any thoughts on this topic. Can you explain what the problems are with symlinks, and what kind of kernel solution you suggest? > 6.4 Description of solution [...] > Most of the smarts are in devfsd. I've used the devfsd MFUNCTION to > intercept REGISTER, UNREGISTER and CHANGE events. This allows us to > see the insertion and removal of the device, changes to the permissions > of the device, as well as open() calls on devices with modules that > are not loaded. Again, don't you really mean inode lookups, rather than open(2)? > 6.4.1 USB and Logical Function to Physical Device Association > > Using a design from David Hinds (maintainer of the Linux PCMCIA code) I > propose we create a generic ioctl() interface which can be used to > retrieve physical device data for a given logical device. This data will missing "be" > domain specific and specific to each hot-swap interface. > > An alternative solution is to use devfs to create logical device nodes > as a bus specific node, and create symlinks (/dev/scsi/host0/bus0/target0 > -> /dev/usb/device1/scsi/target0 or something similar). This is the solution I favour. It makes it easy for the user to inspect the way things are connected (both physically and logically). Presenting this information via the filesystem is the most flexible and convenient method. BTW: it's more likely to be: /dev/scsi/host0 -> /dev/pci/slot1/fn1 or some such (for PCI). This is something that is on my ToDo list. > Both solutions have strengths and weaknesses. An alternative solution may > also be better. I am confident there is a solution to this problem. Can you detail the pros and cons? > 7.1 PCMCIA/Cardbus > > A solution similar to this could be implemented to replace the card > manager and centralize duplicated code and interfaces. > > David Hinds has expressed interest in working on a common solution for > hot-swap interfaces. My solution has involved some ideas from him, but > he probably isn't comfortable with it yet since we have not talked about > it or any specific solutions. Will you and David be going to OLS? What about other people who care about hot-plug interfaces? If people are going to OLS, we should arrange to meet up and thrash out the issues. If people can manage it, come a day or two early or stay on for a day or two (the conference itself is likely to leave little time). Otherwise, we should try and arrange some other meeting somewhere do discuss things. Perhaps SGI would be interested in hosting it? > 7.2 SCSI > > Many, if not all, modern SCSI devices have a unique identifiers which > could be used to devices. This could be used to track permissions on ^ missing "identify" > SCSI generic devices (CD burners, scanners, etc) as well as the logical > function. > > 8. Closing Remarks > > I expect tweaks to be made when I get input from the kernel developer > community at large, including those other subsystem that may be ^ plural > affected including PCMCIA, Hot-Swap PCI, IEEE1394 and SCSI. [...] > I also want to reiterate that while I am actively pushing devfs right now, > that is because it's the best solution available. If an alternative > solution is developed, and is better, then I am interested in hearing > about it. It may be worth stating that many "alternatives" have been proposed, but they don't address all the problems that devfs solves. A few words that firmly discourage time-wasting "solutions" and debates which don't actually solve the problems. I've seen plenty of posts where people don't actually want to solve the problems, they just want to throw out devfs. > Also, please help clear up some of the terminology and descriptions. I > admit my english and explanations can suck. Actaully, your document read very well. I'm just a picky bastard :-) Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Mon Jun 26 15:16:40 2000 Received: by oss.sgi.com id ; Mon, 26 Jun 2000 15:16:31 -0700 Received: from nat-su-33.valinux.com ([198.186.202.33]:15111 "EHLO phenoxide.su.varesearch.com") by oss.sgi.com with ESMTP id ; Mon, 26 Jun 2000 15:15:58 -0700 Received: (from jerdfelt@localhost) by phenoxide.su.varesearch.com (8.9.3/8.9.3) id PAA16755; Mon, 26 Jun 2000 15:15:23 -0700 Date: Mon, 26 Jun 2000 15:15:23 -0700 From: Johannes Erdfelt To: Richard Gooch Cc: devfs@oss.sgi.com Subject: Re: [draft] Hotswap and Linux Message-ID: <20000626151523.P5810@valinux.com> References: <20000621102204.A6504@valinux.com> <200006241921.e5OJLGX12117@vindaloo.ras.ucalgary.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200006241921.e5OJLGX12117@vindaloo.ras.ucalgary.ca>; from rgooch@ras.ucalgary.ca on Sat, Jun 24, 2000 at 01:21:16PM -0600 Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing On Sat, Jun 24, 2000, Richard Gooch wrote: > Johannes Erdfelt writes: > > This is a little white paper that I've been working on about Linux and > > Hot-Swap and all of the associated problems. > > > > It's a first draft and I'd appreciate any feedback. > > This is good work. Could you please make this available as a nice HTML > document and put it up on the WWW somewhere? I'd like to link the > devfs FAQ to it. I shall. I've gotten a couple of requests for HTML versions. I have it at http://johannes.erdfelt.com/hotswap.txt and I'll most likely create an HTML version (and abandon a text version) at http://johannes.erdfelt.com/hotswap.html [grammar/spelling/english nits deleted] Thanks. I'll make these fixes. > > 4.2 scsidev > > > > scsidev scans /proc/scsi and creates device nodes in /dev dynamically > > depending on the devices on the SCSI busses. > > Might be worth highlighting that it's only good for SCSI, and isn't > conducive to adapting to other device types (I've got more detail in > the devfs FAQ). Will do. I'll add a link to the devfs FAQ as well. > > quickly outgrowing the entire major/minor space as currently implemented. > > > > This is required to solve the problem described in section 4.2 > > > > 6.1.4 VFS intercepts to load modules on demand > > > > Part of the design will track devices and their logical functions. The > > VFS can intercept open() calls for devices and load modules on demand. > > Don't you really mean stat(2) calls (in fact, inode lookups)? Perhaps. stat(2) I would think would not require a driver to be loaded, but I'm not familiar with the specific problems. > > 6.2.2 Intuitive and Clean Architecture > > > > Some other solutions had been suggested to dynamically negotiate minor > > numbers between kernel and user space for device nodes. This is not clean > > nor intuitive and is just a kludge. (Nor does this solution meet all of > > the requirements) > > It would help to list those proposed solutions and explain what's > wrong with them. I'll probably steal bits of said material for the > devfs FAQ. Will do. > > 6.3 What I did NOT attempt to solve > > > > I did not attempt to solve device naming yet. This is a problem, but > > the best solution that was offered that did not require kernel > > interaction was symlinks. This could become unwieldly with the > > configurations of some systems. Requiring kernel side support may be > > a requirement unfortunately. I welcome any thoughts on this topic. > > Can you explain what the problems are with symlinks, and what kind of > kernel solution you suggest? The general problem is with symlinks pointing to symlinks pointing to symlinks. Having a whole mess of symlinks would be messy. I want to see them used, but not abused. > > 6.4 Description of solution > [...] > > Most of the smarts are in devfsd. I've used the devfsd MFUNCTION to > > intercept REGISTER, UNREGISTER and CHANGE events. This allows us to > > see the insertion and removal of the device, changes to the permissions > > of the device, as well as open() calls on devices with modules that > > are not loaded. > > Again, don't you really mean inode lookups, rather than open(2)? Perhaps, see above. > > domain specific and specific to each hot-swap interface. > > > > An alternative solution is to use devfs to create logical device nodes > > as a bus specific node, and create symlinks (/dev/scsi/host0/bus0/target0 > > -> /dev/usb/device1/scsi/target0 or something similar). > > This is the solution I favour. It makes it easy for the user to > inspect the way things are connected (both physically and logically). > Presenting this information via the filesystem is the most flexible > and convenient method. > BTW: it's more likely to be: > /dev/scsi/host0 -> /dev/pci/slot1/fn1 > or some such (for PCI). This is something that is on my ToDo list. How would trees be handled? /dev/pci/slot0/fn1/usb0/device2/scsi0 Might get a bit ugly. > > Both solutions have strengths and weaknesses. An alternative solution may > > also be better. I am confident there is a solution to this problem. > > Can you detail the pros and cons? I'll expand that section. > > 7.1 PCMCIA/Cardbus > > > > A solution similar to this could be implemented to replace the card > > manager and centralize duplicated code and interfaces. > > > > David Hinds has expressed interest in working on a common solution for > > hot-swap interfaces. My solution has involved some ideas from him, but > > he probably isn't comfortable with it yet since we have not talked about > > it or any specific solutions. > > Will you and David be going to OLS? What about other people who care > about hot-plug interfaces? If people are going to OLS, we should > arrange to meet up and thrash out the issues. If people can manage it, > come a day or two early or stay on for a day or two (the conference > itself is likely to leave little time). > > Otherwise, we should try and arrange some other meeting somewhere do > discuss things. Perhaps SGI would be interested in hosting it? I hadn't planned to go to OLS, but I have been encouraged to go by a couple of other developers. I'll check with my management to see if I can get the company to send me. I don't suspect it will be a problem if it's a formal BoF or something similar. > > affected including PCMCIA, Hot-Swap PCI, IEEE1394 and SCSI. > [...] > > I also want to reiterate that while I am actively pushing devfs right now, > > that is because it's the best solution available. If an alternative > > solution is developed, and is better, then I am interested in hearing > > about it. > > It may be worth stating that many "alternatives" have been proposed, > but they don't address all the problems that devfs solves. A few words > that firmly discourage time-wasting "solutions" and debates which > don't actually solve the problems. > > I've seen plenty of posts where people don't actually want to solve > the problems, they just want to throw out devfs. Agreed. I'll spend more time explaining alternative proposed solutions in addition to the existing implemented solutions I have listed. > > Also, please help clear up some of the terminology and descriptions. I > > admit my english and explanations can suck. > > Actaully, your document read very well. I'm just a picky bastard :-) I appreciate all of the feedback. The english is minor but is needed. I have gotten more feedback I have expected from a variety of people. I'll be working this week to incorporate all of the suggestions and come out with a new version which I'll invite people on linux-kernel to comment on. JE From owner-devfs@oss.sgi.com Mon Jun 26 19:09:11 2000 Received: by oss.sgi.com id ; Mon, 26 Jun 2000 19:09:01 -0700 Received: from demai05.mw.mediaone.net ([24.131.1.56]:38555 "EHLO demai05.mw.mediaone.net") by oss.sgi.com with ESMTP id ; Mon, 26 Jun 2000 19:08:49 -0700 Received: from deimos.ceddec.com (nic-30-c66-230.mw.mediaone.net [24.30.66.230]) by demai05.mw.mediaone.net (8.8.7/8.8.7) with ESMTP id WAA17744 for ; Mon, 26 Jun 2000 22:08:47 -0400 (EDT) Received: (from nobody@localhost) by deimos.ceddec.com (8.9.3/8.9.3) id WAA13749 for devfs@oss.sgi.com; Mon, 26 Jun 2000 22:09:07 -0400 Date: Mon, 26 Jun 2000 22:09:07 -0400 From: Tom Zerucha To: devfs@oss.sgi.com Subject: cdwriting using IDE under devfs? Message-ID: <20000626220907.A13742@deimos.mw.mediaone.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing I am using 2.4.0test1-ac22 and can't seem to find the right combination to get my cdwriter to appear as a scsi drive. Any one do this (with devfs on earlier kernels)? From owner-devfs@oss.sgi.com Mon Jun 26 21:46:31 2000 Received: by oss.sgi.com id ; Mon, 26 Jun 2000 21:46:21 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:55226 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Mon, 26 Jun 2000 21:45:55 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e5R4jjg08453; Mon, 26 Jun 2000 22:45:45 -0600 Date: Mon, 26 Jun 2000 22:45:45 -0600 Message-Id: <200006270445.e5R4jjg08453@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Tom Zerucha Cc: devfs@oss.sgi.com Subject: Re: cdwriting using IDE under devfs? In-Reply-To: <20000626220907.A13742@deimos.mw.mediaone.net> References: <20000626220907.A13742@deimos.mw.mediaone.net> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Tom Zerucha writes: > I am using 2.4.0test1-ac22 and can't seem to find the right > combination to get my cdwriter to appear as a scsi drive. > > Any one do this (with devfs on earlier kernels)? Did this work before or not? If you load the sg driver, your device should appear under the /dev/scsi hierarchy. Does it? Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Mon Jun 26 22:06:12 2000 Received: by oss.sgi.com id ; Mon, 26 Jun 2000 22:06:01 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:57274 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Mon, 26 Jun 2000 22:05:46 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e5R558U08717; Mon, 26 Jun 2000 23:05:08 -0600 Date: Mon, 26 Jun 2000 23:05:08 -0600 Message-Id: <200006270505.e5R558U08717@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: linux-kernel@vger.rutgers.edu, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: [PATCH] devfs v174 available Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Hi, all. Version 174 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 This is against 2.4.0-test3-pre1. Highlights of this release: - Updated README from master HTML file Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Mon Jun 26 22:39:01 2000 Received: by oss.sgi.com id ; Mon, 26 Jun 2000 22:38:51 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:60602 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Mon, 26 Jun 2000 22:38:33 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e5R5cUp09103; Mon, 26 Jun 2000 23:38:30 -0600 Date: Mon, 26 Jun 2000 23:38:30 -0600 Message-Id: <200006270538.e5R5cUp09103@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Johannes Erdfelt Cc: devfs@oss.sgi.com Subject: Re: [draft] Hotswap and Linux In-Reply-To: <20000626151523.P5810@valinux.com> References: <20000621102204.A6504@valinux.com> <200006241921.e5OJLGX12117@vindaloo.ras.ucalgary.ca> <20000626151523.P5810@valinux.com> Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Johannes Erdfelt writes: > On Sat, Jun 24, 2000, Richard Gooch wrote: > > Johannes Erdfelt writes: > > > This is a little white paper that I've been working on about Linux and > > > Hot-Swap and all of the associated problems. > > > > > > It's a first draft and I'd appreciate any feedback. > > > > This is good work. Could you please make this available as a nice HTML > > document and put it up on the WWW somewhere? I'd like to link the > > devfs FAQ to it. > > I shall. I've gotten a couple of requests for HTML versions. I have it > at http://johannes.erdfelt.com/hotswap.txt and I'll most likely create > an HTML version (and abandon a text version) at > http://johannes.erdfelt.com/hotswap.html Thanks. > > > quickly outgrowing the entire major/minor space as currently implemented. > > > > > > This is required to solve the problem described in section 4.2 > > > > > > 6.1.4 VFS intercepts to load modules on demand > > > > > > Part of the design will track devices and their logical functions. The > > > VFS can intercept open() calls for devices and load modules on demand. > > > > Don't you really mean stat(2) calls (in fact, inode lookups)? > > Perhaps. stat(2) I would think would not require a driver to be > loaded, but I'm not familiar with the specific problems. If the inode doesn't exist, then any attempt to reference it by name (stat(2), open(2), chown(2) and so on) will cause an inode lookup. If the device entry hasn't been registered, this will cause a LOOKUP event to be sent to devfsd. If the inode does exist (or the device entry has been registered), then there is no need to load a module upon open(2), as the module is already loaded (otherwise the device entry wouldn't exist). > > > 6.3 What I did NOT attempt to solve > > > > > > I did not attempt to solve device naming yet. This is a problem, but > > > the best solution that was offered that did not require kernel > > > interaction was symlinks. This could become unwieldly with the > > > configurations of some systems. Requiring kernel side support may be > > > a requirement unfortunately. I welcome any thoughts on this topic. > > > > Can you explain what the problems are with symlinks, and what kind of > > kernel solution you suggest? > > The general problem is with symlinks pointing to symlinks pointing > to symlinks. Having a whole mess of symlinks would be messy. I want > to see them used, but not abused. Agreed. I see two levels of indirection, which I think is reasonable, given what we're trying to represent: /dev/discs/disc0 -> /dev/scsi/host0/bus0/target0/lun0 /dev/scsi/host0 -> /dev/bus/pci/slot1/fn1 > > > domain specific and specific to each hot-swap interface. > > > > > > An alternative solution is to use devfs to create logical device nodes > > > as a bus specific node, and create symlinks (/dev/scsi/host0/bus0/target0 > > > -> /dev/usb/device1/scsi/target0 or something similar). > > > > This is the solution I favour. It makes it easy for the user to > > inspect the way things are connected (both physically and logically). > > Presenting this information via the filesystem is the most flexible > > and convenient method. > > BTW: it's more likely to be: > > /dev/scsi/host0 -> /dev/pci/slot1/fn1 > > or some such (for PCI). This is something that is on my ToDo list. > > How would trees be handled? > > /dev/pci/slot0/fn1/usb0/device2/scsi0 > > Might get a bit ugly. /dev/discs/disc0 -> /dev/scsi/host0/bus0/target0/lun0 /dev/scsi/host0 -> /dev/usb/device2/scsi0 If you want to expose which USB controller is being used, then: /dev/scsi/host0 -> /dev/usb/controller0/device2/scsi0 /dev/usb/controller0 -> /dev/pci/slot1/fn1 > > Will you and David be going to OLS? What about other people who care > > about hot-plug interfaces? If people are going to OLS, we should > > arrange to meet up and thrash out the issues. If people can manage it, > > come a day or two early or stay on for a day or two (the conference > > itself is likely to leave little time). > > > > Otherwise, we should try and arrange some other meeting somewhere do > > discuss things. Perhaps SGI would be interested in hosting it? > > I hadn't planned to go to OLS, but I have been encouraged to go by a > couple of other developers. > > I'll check with my management to see if I can get the company to > send me. Larry hasn't spent all those buckets of money yet, has he? I'm sure VA can afford it :-) > I don't suspect it will be a problem if it's a formal BoF or > something similar. Given that I expect the conference to have a tight schedule, and that we probably need more than an hour to thrash out the ideas, I'd rather do it just before or after the conference. I figure I can get the Linuxcare people to provide us with some space for an afternoon. > I have gotten more feedback I have expected from a variety of > people. I'll be working this week to incorporate all of the > suggestions and come out with a new version which I'll invite people > on linux-kernel to comment on. Will you be passing the next draft to the devfs list for comment before unleashing it on linux-kernel? Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Tue Jun 27 08:25:07 2000 Received: by oss.sgi.com id ; Tue, 27 Jun 2000 08:24:57 -0700 Received: from demai05.mw.mediaone.net ([24.131.1.56]:22211 "EHLO demai05.mw.mediaone.net") by oss.sgi.com with ESMTP id ; Tue, 27 Jun 2000 08:24:38 -0700 Received: from deimos.ceddec.com (nic-30-c66-230.mw.mediaone.net [24.30.66.230]) by demai05.mw.mediaone.net (8.8.7/8.8.7) with ESMTP id KAA12212; Tue, 27 Jun 2000 10:53:29 -0400 (EDT) Received: (from nobody@localhost) by deimos.ceddec.com (8.9.3/8.9.3) id KAA00947; Tue, 27 Jun 2000 10:54:03 -0400 Date: Tue, 27 Jun 2000 10:54:02 -0400 From: Tom Zerucha To: Richard Gooch Cc: Tom Zerucha , devfs@oss.sgi.com Subject: Re: cdwriting using IDE under devfs? Message-ID: <20000627105402.A879@deimos.mw.mediaone.net> References: <20000626220907.A13742@deimos.mw.mediaone.net> <200006270445.e5R4jjg08453@vindaloo.ras.ucalgary.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200006270445.e5R4jjg08453@vindaloo.ras.ucalgary.ca>; from rgooch@ras.ucalgary.ca on Mon, Jun 26, 2000 at 10:45:45PM -0600 Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing On Mon, Jun 26, 2000 at 10:45:45PM -0600, Richard Gooch wrote: > Tom Zerucha writes: > > I am using 2.4.0test1-ac22 and can't seem to find the right > > combination to get my cdwriter to appear as a scsi drive. > > > > Any one do this (with devfs on earlier kernels)? > > Did this work before or not? This is the first time I've tried it with devfs + linux 2.4.0test1 The no-devfs 2.4.0test1 worked (see below) > If you load the sg driver, your device should appear under the > /dev/scsi hierarchy. Does it? It doesn't thought it appears it wants to load something. I have all my IDE devices as modules (yes, ide-mod.o ide-probe-mod.o ide-disk.o ide-cd.o and ide-scsi.o). There does seem to be some operational problems depending on the order of the modules - you need ide-cd, ide-probe, and ide-scsi in that order. Actually it seemed to work - I say seemed because as I was trying it last night, (you get the messages when probing ide-scsi), but I got a kernel panic. I have modified modules.conf to use ide-scsi for the scsi controller card but I don't know if that is right or not. I wasn't getting this far without a bus controller card, but it kpanics. Normally it simply says scsi: 1 host a lot (for each probe in cdrecord -scanbus) - it found the CDs this time. Part of it might still be the IDE driver, but I think the devfs load-unload is interacting with that in some way. From owner-devfs@oss.sgi.com Tue Jun 27 09:47:41 2000 Received: by oss.sgi.com id ; Tue, 27 Jun 2000 09:47:30 -0700 Received: from thalia.fm.intel.com ([132.233.247.11]:39692 "EHLO thalia.fm.intel.com") by oss.sgi.com with ESMTP id ; Tue, 27 Jun 2000 09:47:07 -0700 Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.30 2000/06/08 18:25:35 dmccart Exp $) with SMTP id QAA29586; Tue, 27 Jun 2000 16:48:01 GMT Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.204 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 27 Jun 2000 16:47:07 0000 (GMT) Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 27 Jun 2000 09:47:04 -0700 Message-ID: From: "Dunlap, Randy" To: "'Johannes Erdfelt'" , devfs@oss.sgi.com Subject: RE: [draft] Hotswap and Linux Date: Tue, 27 Jun 2000 09:46:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Hi Johannes, I'm replying to your original posting. I know that Richard G. replied with some comments & changes, but I haven't looked at his comments in any detail, so some of mine may be repeats (or conflicts) with his. Lots of these changes are just typos. > -----Original Message----- > From: Johannes Erdfelt [mailto:jerdfelt@valinux.com] > Sent: Wednesday, June 21, 2000 10:22 AM > To: devfs@oss.sgi.com > Subject: [draft] Hotswap and Linux > > ... > > 2. Hot-Swap Interfaces > > A hot-swap interface is any interface to a computer which you can plug INSERT: into^ > and unplug devices while the machine is running. Insertion and removal > does not necessarily need to happen while the machine is ... > However, as is often the case with the computer industry, technologies > blur and USB is being seen on servers and Hot-Swap PCI and > Hot-Swap SCSI > technologies will eventually find their way to desktops. > PCMCIA, or more > specifically CardBus, is essentially a form of Hot-Swap PCI. However, > they are different enough to mention seperately. CHANGE: separately. > > Most of the interfaces are busses, allowing multiple devices to be > connected. However, things like parport could also be considered a > hot-swap interface. > > 2.1 PCMCIA > ... > > 2.2 SCSI > > I'm not an expert on SCSI, but I know that SCSI has supported hot-swap > devices for a while in some situations. > > It is a higher level bus than the system bus. ADD (with your choice of editing): It is a separate (or secondary) bus that attaches to the system bus. > > 2.3 Hot-Swap PCI > > Hot-Swap PCI is relatively recent which is mainly seen in servers. It EDIT: ^a ^technology s/which/that/ > simply adds Hot-Swap capability to PCI (correct?) > > PCMCIA (CardBus) and Hot-Swap PCI are very similar technologies. ADD: except that PCI hot-plug is defined as an orderly removal and insertion technology, with full hardware and software approval of the slot power-off/on and possible driver removal and reloading, while PCMCIA cards can be removed/inserted by user actions without prior software approval or coordination. > > It is a part of the system bus. > > 2.4 IEEE 1394 > > This is commonly called by it's trade names Firewire (Apple) EDIT: ^remove "'" > or iLink (Sony). > It is very similar to USB but is not as widely adopted. > > It is a higher level bus than the system bus. ADD (with your choice of editing): It is a separate (or secondary) bus that attaches to the system bus. > > 2.5 USB > > Universal Serial Bus was originally introduced a couple of > years ago and EDIT: s/a couple of/several/ > has recently seen widespread adoption (iMac, etc). EDIT: add to iMac: Sun, Intel platforms > > It is a higher level bus than the system bus. ADD (with your choice of editing): It is a separate (or secondary) bus that attaches to the system bus. ... > > 3.1 Device Naming > > Devices are named on a first come, first served basis. For EDIT: first-come, first-served > instance, when > the OS probes for SCSI devices, the first hard drive is > assigned major/minor > 8/0. The second harddrive is assigned major/minor 8/16. EDIT: hard drive > Traditional device > nodes under Linux for these devices are /dev/sda and /dev/sdb > respectively. > > When a device can be inserted or removed randomly, as in the case of a > hot-swap interface, the probing order becomes random. Since > Linux still > uses a first come first served naming scheme, the device EDIT: first-come first-served > nodes name can be essentially random. EDIT: node names > ... > > 3.2 Device Permissions > > Linux and most every other Unix, stores permissions for a EDIT: ^remove comma > device in the > filesystem. Those are associated with the name of the device > (/dev/sda). > > Since we cannot guarantee the same name each time a device is > inserted (see > 3.1), we cannot guarantee the device has the correct or same > permissions. > > Tracking devices should be done by tracking characteristics > of the device EDIT: ^add comma; maybe add examples: such as a serial number or disk label > not the name of the device node corresponding to the device. > > 3.3 Enumeration and Driver Binding > > Many of today's interfaces offer complicated device > structure. Some allow EDIT: ^add: 's' (such as PCI configuration space, USB descriptors, and PCMCIA/CardBus Card Information Structure) > multiple logical functions in one physical device, along with multiple > interfaces of varying complexity. > > Selecting the correct configuration parameters can be complicated. USB > has the notion of configurations, interfaces, alternate settings and > endpoints. Choosing which configuration or alternate setting > to use, or > what drivers to bind to each interface is complicated and involves EDIT: driver > user defined policy. EDIT: ^user-defined > > 3.4 Logical Function to Physical Device Association > > Given a logical function of a device (say a SCSI drive, QUESTION: ^name ? > /dev/sdb) I cannot EDIT: ^insert comma > determine what physical device it is. > ... > > 3.5 Userspace API > > Hot-Swap interfaces that are not system busses can often > export a userspace EDIT: ^should be hyphenated (userspace-visible) > visible API which can move complex code out of the kernel > core and into > userspace for a variety of reasons. > ... > > 4. Existing Solutions > > The problem of hot-swap has been tackled in the past at varying levels > of complexity and varying levels of effectiveness. > > 4.1 PCMCIA/Carbus EDIT: CardBus > > PCMCIA (and Carbus, however I will use PCMCIA to cover both EDIT: CardBus; however, > technologies) > has been supported by Linux for a couple of releases and has been the > mostly widely used hot-swap interface. It thusly has ran into many of > these problems for a while and a series of solutions have > been developed > with a varying degree of effectiveness. > > The core of their solution is the Card Manager. > > The PCMCIA card manager is notified by the kernel when a EDIT: Card Manager > device insertion > or removal occurs on any PCMCIA bus. It obtains from the ... > > 4.1.2 PCMCIA and Device Permissions > > The same shell scripts that configure the device, can be used EDIT: ^delete comma > to create and apply permissions to device nodes. > > This has the same problem as Device Naming in that it requires hard EDIT: change to: hard-coded > coded configuration in shell scripts. > ... > > 4.1.5 PCMCIA and Userspace API > > Since PCMCIA is a system bus, it uses the same architecture defined EDIT: architecture-defined > access to devices. This includes IRQ's, DMA channels, I/O > ports, memory > ranges, etc. The existing userspace API's for this are used. > > The existing API is limited to I/O port and memory access. > ... > > 5.1 Complex Structure of USB Devices > > This was touched on in section 3.3 (Enumeration and Driver Binding). > > Each USB device can have multiple configurations. Only one > configuration > can be active at once. Each configuration has multiple > interfaces. Each > interface offers a logical function of the device. They are all active > at once. Each interface has an alternate setting. Alternate settings CHANGE (?): I'd say: They can all be active simultaneously. > select how much bandwidth a device uses, programming interface, etc. EDIT: s/device/interface/ > Only one alternate setting can be active at a time per interface. Each > alternate setting has 1 or more endpoints. > ... > > Since each interface is a logical function of the device, separate > permissions are required. Thusly, multiple device nodes are required EDIT: Thus, ^possibly > for one device. > > Tracking permissions for the device then entails tracking the device > and the permissions for each interface. > > A quick summary, one device node is not sufficient to EDIT: summary: One device node generally is not... > describe the device > and the layout of the device can wildly change from device to > device and configuration to configuration. > > 5.2 Userspace API > ... > > The existing userspace solution overloads one device node with ioctl's > for each transfer type and feature for all endpoints (and thusly > interfaces). The existing implemented solution will not be the final > solution since it has a variety of problems. NEEDS TO BE SUBSTANTIATED: ^, some of which are.... > ... > > 6.1 Required Features for the solution > > Some people have had the misconception that this locks > everyone into devfs > to use USB. This is not the case. It locks us into a certain > feature set that must be supported. AGREED. > > In the case right now, devfs is the only solution which EDIT: The case right now is that devfs is... > offers all of the infrastructure needed. > > I cannot see how hot-swap can be implemented in a clean way > without these requirements. > > 6.1.1 Dynamic creation of device nodes > > Once configurations and alternate settings are selected, the number of > interfaces, endpoints can radically change. EDIT: s/,/ &/ > > 6.1.2 No fixed limit on device nodes > > The structure and layout of device nodes is sparse and complicated EDIT: ^add comma > quickly outgrowing the entire major/minor space as currently > implemented. > > This is required to solve the problem described in section 4.2 EDIT: end with "4.2." > > 6.1.3 VFS intercepts for common syscalls (chmod, chown, etc) > > To properly track device permissions, we need to know when permissions > are changed for device nodes so the permissions can be saved in a > database along with other identifying information about the device. > > This is required to solve the problem described in section 3.2 EDIT: end with "3.2." > > 6.1.4 VFS intercepts to load modules on demand > > Part of the design will track devices and their logical functions. The > VFS can intercept open() calls for devices and load modules on demand. > > 6.2 Goals > > There were goals I strived to meet while I create this solutions EDIT: created this solution. > > 6.2.1 Minimal code duplication > ... > > This also minimizes the impact into unswappable kernel memory EDIT: s/into/to/ > and kernel image size. > > 6.2.2 Intuitive and Clean Architecture > > Some other solutions had been suggested to dynamically negotiate minor > numbers between kernel and user space for device nodes. This > is not clean > nor intuitive and is just a kludge. (Nor does this solution > meet all of the requirements) EDIT: requirements.) > > The solution must be designed to stand up for the future. > ... > > 6.4 Description of solution > > The core of the solution is devfs and devfsd. Using devfs allows us to > meet goals 6.2.1 (Code Duplication) and 6.2.2 (Intuitive and Clean > Architecture) immediately. > > devfs centralizes much of the common code, such as the kernel > to userspace EDIT: kernel-to-userspace > channel to communicate device insertions, removals, chmod > calls, etc. It > also avoids creating extra VFS' for each hot-swap bus like usbdevfs is > currently implemented. > ... > > 6.4.1 USB and Logical Function to Physical Device Association > > Using a design from David Hinds (maintainer of the Linux > PCMCIA code) I > propose we create a generic ioctl() interface which can be used to > retrieve physical device data for a given logical device. > This data will EDIT: s/will/will be/ > domain specific and specific to each hot-swap interface. > > An alternative solution is to use devfs to create logical device nodes > as a bus specific node, and create symlinks EDIT: as bus-specific nodes, > (/dev/scsi/host0/bus0/target0 > -> /dev/usb/device1/scsi/target0 or something similar). > ... > > 6.4.2 Processing on REGISTER events > > When a REGISTER event occurs, the module obtains the QUESTION: ^What module? > descriptors for the > device and parses them, determining which configurations, > interfaces and > alternate settings are available on the device. It then executes an > arbitrary algorithm (not explained here for brevity) to select a > configuration, then select alternate settings and drivers for each > interface. The software then programs the active configuration and the > active alternate setting for each interface. QUESTION: But the to-be-loaded driver can modify the interface selection? > > If the driver must be loaded at insertion time, instead of at > use time, > the driver will be loaded, binds the driver to the interfaces necessary EDIT: bound to the interfaces necessary > and activates the interface. EDIT: and the interface activated. > ... > > 7. Future work > > The work I've done is not just applicable to USB. Many other > systems can use similar algorithms and code. EDIT: s|systems|I/O subsystems| > ... > > 7.2 SCSI > > Many, if not all, modern SCSI devices have a unique identifiers which EDIT: ^delete 'a' > could be used to devices. This could be used to track permissions on EDIT: ^insert: identify; s/This/These/ > SCSI generic devices (CD burners, scanners, etc) as well as > the logical function. > ... > > 7.4 ALSA > > A similar, but different, problem exists for ALSA. Most > devices supported > under ALSA export many interfaces to control the device. To > appropriately > solve this problem, the ALSA team overloads /proc with the EDIT: change to "To solve this problem appropriately," > device nodes it > needs. Permissions aren't tracked for the device nodes. > > 8. Closing Remarks > > I expect tweaks to be made when I get input from the kernel developer > community at large, including those other subsystem that may be EDIT: subsystems > affected including PCMCIA, Hot-Swap PCI, IEEE1394 and SCSI. > ... > > Also, please help clear up some of the terminology and descriptions. I > admit my english and explanations can suck. EDIT: English > > JE I think that you are off to a very good start here. Have you sent this to Johnny ? @mot.com, who did the PCI hot-swap implementation last year? And the 1394 people? What are your next steps for this? HTH. ~Randy ___________________________________________________ |Randy Dunlap Intel Corp., DAL Sr. SW Engr.| |randy.dunlap.at.intel.com 503-696-2055| |NOTE: Any views presented here are mine alone | |and may not represent the views of my employer. | |_________________________________________________| From owner-devfs@oss.sgi.com Thu Jun 29 22:13:52 2000 Received: by oss.sgi.com id ; Thu, 29 Jun 2000 22:13:42 -0700 Received: from vindaloo.ras.ucalgary.ca ([136.159.55.21]:16832 "EHLO vindaloo.ras.ucalgary.ca") by oss.sgi.com with ESMTP id ; Thu, 29 Jun 2000 22:13:31 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id e5U5DaZ14024; Thu, 29 Jun 2000 23:13:36 -0600 Date: Thu, 29 Jun 2000 23:13:36 -0600 Message-Id: <200006300513.e5U5DaZ14024@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: "Dunlap, Randy" Cc: "'Johannes Erdfelt'" , devfs@oss.sgi.com Subject: RE: [draft] Hotswap and Linux In-Reply-To: References: Sender: owner-devfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;devfs-outgoing Randy Dunlap writes: > Hi Johannes, > > I'm replying to your original posting. > I know that Richard G. replied with some comments & > changes, but I haven't looked at his comments in any > detail, so some of mine may be repeats (or conflicts) > with his. Lots of these changes are just typos. I just had a quick glance at your comments, and I still have nits to pick ;-) > > 6.2.1 Minimal code duplication > > > ... > > > > This also minimizes the impact into unswappable kernel memory > EDIT: s/into/to/ Actually, that should read: "minimises the impact on unswappable...". > > 6.4.1 USB and Logical Function to Physical Device Association > > > > Using a design from David Hinds (maintainer of the Linux > > PCMCIA code) I > > propose we create a generic ioctl() interface which can be used to > > retrieve physical device data for a given logical device. > > This data will > EDIT: s/will/will be/ Should be: "These data will be...". Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca