* devfs
@ 2002-11-12 9:32 Ian Molton
2002-11-12 9:43 ` devfs Xavier Bestel
0 siblings, 1 reply; 30+ messages in thread
From: Ian Molton @ 2002-11-12 9:32 UTC (permalink / raw)
To: linux-kernel
On 11 Nov 2002 20:50:39 -0500
Robert Love <rml@tech9.net> wrote:
> On Mon, 2002-11-11 at 20:32, Ryan Anderson wrote:
>
> > From an outsider point of view (and because nobody else responded),
> > I think the big question here would be: Would you use it after this
> > cleanup?
> >
> > If you say yes, I'd say that's a good sign in its favor.
>
> Good heuristic, except Al would not use devfs in either case :)
Personally I love devfs. I've not looked at its internals, but its never
failed me yet, and I like the way /dev only contains stuff that actually
exists.
And if Al doesnt like the code... hes free to reimplement it...
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: devfs 2002-11-12 9:32 devfs Ian Molton @ 2002-11-12 9:43 ` Xavier Bestel 2002-11-12 9:49 ` devfs john slee ` (2 more replies) 0 siblings, 3 replies; 30+ messages in thread From: Xavier Bestel @ 2002-11-12 9:43 UTC (permalink / raw) To: Ian Molton; +Cc: Linux Kernel Mailing List Le mar 12/11/2002 à 10:32, Ian Molton a écrit : > On 11 Nov 2002 20:50:39 -0500 > Robert Love <rml@tech9.net> wrote: > > > On Mon, 2002-11-11 at 20:32, Ryan Anderson wrote: > > > > > From an outsider point of view (and because nobody else responded), > > > I think the big question here would be: Would you use it after this > > > cleanup? > > > > > > If you say yes, I'd say that's a good sign in its favor. > > > > Good heuristic, except Al would not use devfs in either case :) > > Personally I love devfs. I've not looked at its internals, but its never > failed me yet, and I like the way /dev only contains stuff that actually > exists. I'm wondering if a totally userspace solution could replace devs ? Something using hotplug + sysfs and creating directories/nodes as they appear on the system. This way, the policy (how do I name what) could be moved out of the kernel. Xav ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: devfs 2002-11-12 9:43 ` devfs Xavier Bestel @ 2002-11-12 9:49 ` john slee 2002-11-12 10:01 ` devfs Sean Neakums 2002-11-12 10:05 ` devfs Xavier Bestel 2002-11-12 10:04 ` devfs Alexander Viro 2002-11-12 15:40 ` devfs Greg KH 2 siblings, 2 replies; 30+ messages in thread From: john slee @ 2002-11-12 9:49 UTC (permalink / raw) To: Xavier Bestel; +Cc: Ian Molton, Linux Kernel Mailing List On Tue, Nov 12, 2002 at 10:43:41AM +0100, Xavier Bestel wrote: > I'm wondering if a totally userspace solution could replace devs ? > Something using hotplug + sysfs and creating directories/nodes as they > appear on the system. This way, the policy (how do I name what) could be > moved out of the kernel. curious! you mean similar to (and a logical extension of) the 'disks' command in solaris? at least i think thats what its called... j. -- toyota power: http://indigoid.net/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: devfs 2002-11-12 9:49 ` devfs john slee @ 2002-11-12 10:01 ` Sean Neakums 2002-11-12 12:51 ` devfs Oliver Neukum 2002-11-12 10:05 ` devfs Xavier Bestel 1 sibling, 1 reply; 30+ messages in thread From: Sean Neakums @ 2002-11-12 10:01 UTC (permalink / raw) To: linux-kernel commence john slee quotation: > On Tue, Nov 12, 2002 at 10:43:41AM +0100, Xavier Bestel wrote: >> I'm wondering if a totally userspace solution could replace devs ? >> Something using hotplug + sysfs and creating directories/nodes as >> they appear on the system. This way, the policy (how do I name >> what) could be moved out of the kernel. > > curious! you mean similar to (and a logical extension of) the > 'disks' command in solaris? at least i think thats what its > called... Except that a /sbin/hotplug er, "solution", would be dynamic. I had always assumed in the back of my mind that such a solution would make devfs go away some day, although I don't think I actually read about it anywhere. Actually, here's a question: are /sbin/hotplug upcalls serialized in some fashion? I'd hate to online a thousand devices in my disk array and have the machine forkbomb itself. -- / | [|] Sean Neakums | Questions are a burden to others; [|] <sneakums@zork.net> | answers a prison for oneself. \ | ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: devfs 2002-11-12 10:01 ` devfs Sean Neakums @ 2002-11-12 12:51 ` Oliver Neukum 2002-11-13 10:48 ` hotplug (was devfs) Nick Craig-Wood 0 siblings, 1 reply; 30+ messages in thread From: Oliver Neukum @ 2002-11-12 12:51 UTC (permalink / raw) To: Sean Neakums, linux-kernel > Actually, here's a question: are /sbin/hotplug upcalls serialized in > some fashion? I'd hate to online a thousand devices in my disk array > and have the machine forkbomb itself. Nope, no serialisation. You don't have any guarantee even that addition will be delivered before removal. Regards Oliver ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: hotplug (was devfs) 2002-11-12 12:51 ` devfs Oliver Neukum @ 2002-11-13 10:48 ` Nick Craig-Wood 2002-11-13 17:02 ` Greg KH 0 siblings, 1 reply; 30+ messages in thread From: Nick Craig-Wood @ 2002-11-13 10:48 UTC (permalink / raw) To: Oliver Neukum; +Cc: Sean Neakums, linux-kernel On Tue, Nov 12, 2002 at 01:51:08PM +0100, Oliver Neukum wrote: > > Actually, here's a question: are /sbin/hotplug upcalls serialized in > > some fashion? I'd hate to online a thousand devices in my disk array > > and have the machine forkbomb itself. > > Nope, no serialisation. You don't have any guarantee even that > addition will be delivered before removal. And that is why (we finally discovered) we were getting non-deterministic device numbering of USB nodes. We have machines with 6 x 4 port USB <-> serial converters attached. These would get randomly assigned usb device ids and hence random /dev/ttyUSB nodes. Not very useful when there is a load of different things attached to the 24 serial ports! Sometimes we also found that one of the devices wouldn't get initialised properly. We fixed these problems by removing hotplug and loading the relevant kernel modules in the correct order and voila a perfectly deterministic order for the /dev/ttyUSBs with all devices initialised. Plugging in our USB bus with 24 devices on it does indeed produce a mini-forkbomb effect ;-) (Especially since these Keyspan devices are initialised twice - once without firmware and once with firmware.) So - perhaps hotplug ought to be serialised? -- Nick Craig-Wood ncw1@axis.demon.co.uk ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: hotplug (was devfs) 2002-11-13 10:48 ` hotplug (was devfs) Nick Craig-Wood @ 2002-11-13 17:02 ` Greg KH 2002-11-13 18:06 ` Nick Craig-Wood 2002-11-14 11:46 ` Oliver Neukum 0 siblings, 2 replies; 30+ messages in thread From: Greg KH @ 2002-11-13 17:02 UTC (permalink / raw) To: Nick Craig-Wood; +Cc: Oliver Neukum, Sean Neakums, linux-kernel On Wed, Nov 13, 2002 at 10:48:09AM +0000, Nick Craig-Wood wrote: > > We fixed these problems by removing hotplug and loading the relevant > kernel modules in the correct order and voila a perfectly > deterministic order for the /dev/ttyUSBs with all devices initialised. deterministic for you :) What hotplug will do is allow you to assign a /dev entry to a specific device, so that you can go off of the topology, and not just the order in which the devices are found. That is how this problem will be solved properly. > Plugging in our USB bus with 24 devices on it does indeed produce a > mini-forkbomb effect ;-) (Especially since these Keyspan devices are > initialised twice - once without firmware and once with firmware.) > > So - perhaps hotplug ought to be serialised? No, it's not needed for this problem. There has been talk of serializing stuff in userspace, which is the proper way to handle some of the remove before add was seen problems. thanks, greg k-h ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: hotplug (was devfs) 2002-11-13 17:02 ` Greg KH @ 2002-11-13 18:06 ` Nick Craig-Wood 2002-11-13 18:04 ` Greg KH 2002-11-14 11:46 ` Oliver Neukum 1 sibling, 1 reply; 30+ messages in thread From: Nick Craig-Wood @ 2002-11-13 18:06 UTC (permalink / raw) To: Greg KH; +Cc: Oliver Neukum, Sean Neakums, linux-kernel On Wed, Nov 13, 2002 at 09:02:04AM -0800, Greg KH wrote: > On Wed, Nov 13, 2002 at 10:48:09AM +0000, Nick Craig-Wood wrote: > > > > We fixed these problems by removing hotplug and loading the relevant > > kernel modules in the correct order and voila a perfectly > > deterministic order for the /dev/ttyUSBs with all devices initialised. > > deterministic for you :) Indeed! It was deterministic in the sense of 1) I booted the machine 10 times and the devices came up in the same order ;-) 2) the order of the devices was related to the usb topology, like this (these are usb bus positions as noted by hub.c) 1/1 <- hub1 1/1/1 <- keyspan 1 /dev/ttyUSB0..3 1/1/2 <- keyspan 2 /dev/ttyUSB4..7 1/1/3 <- keyspan 3 /dev/ttyUSB8..11 1/1/4 <- hub2 1/1/4/1 <- keyspan 4 /dev/ttyUSB12..15 1/1/4/2 <- keyspan 5 /dev/ttyUSB16..19 1/1/4/3 <- keyspan 6 /dev/ttyUSB20..23 That seemed like a sensible order to me! > What hotplug will do is allow you to assign a /dev entry to a specific > device, so that you can go off of the topology, and not just the order > in which the devices are found. That is how this problem will be > solved properly. So I'll be able to say usb bus1/1/4/1 port 3 should be /dev/ttyUSB15 and it will always be that port? That would be perfect. > > Plugging in our USB bus with 24 devices on it does indeed produce a > > mini-forkbomb effect ;-) (Especially since these Keyspan devices are > > initialised twice - once without firmware and once with firmware.) > > > > So - perhaps hotplug ought to be serialised? > > No, it's not needed for this problem. There has been talk of > serializing stuff in userspace, which is the proper way to handle some > of the remove before add was seen problems. Userspace serialisation would have solved this problem for us too I think without the extra mapping mechanism. -- Nick Craig-Wood ncw1@axis.demon.co.uk ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: hotplug (was devfs) 2002-11-13 18:06 ` Nick Craig-Wood @ 2002-11-13 18:04 ` Greg KH 0 siblings, 0 replies; 30+ messages in thread From: Greg KH @ 2002-11-13 18:04 UTC (permalink / raw) To: Nick Craig-Wood; +Cc: Oliver Neukum, Sean Neakums, linux-kernel On Wed, Nov 13, 2002 at 06:06:06PM +0000, Nick Craig-Wood wrote: > > So I'll be able to say usb bus1/1/4/1 port 3 should be /dev/ttyUSB15 > and it will always be that port? That would be perfect. Yes, that is the goal. thanks, greg k-h ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: hotplug (was devfs) 2002-11-13 17:02 ` Greg KH 2002-11-13 18:06 ` Nick Craig-Wood @ 2002-11-14 11:46 ` Oliver Neukum 1 sibling, 0 replies; 30+ messages in thread From: Oliver Neukum @ 2002-11-14 11:46 UTC (permalink / raw) To: Greg KH, Nick Craig-Wood; +Cc: Sean Neakums, linux-kernel > > So - perhaps hotplug ought to be serialised? > > No, it's not needed for this problem. There has been talk of > serializing stuff in userspace, which is the proper way to handle some > of the remove before add was seen problems. We may need some kind of load control. The thought of firing up hundreds of hotplug scripts simultaneously is not pretty. Regards Oliver ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: devfs 2002-11-12 9:49 ` devfs john slee 2002-11-12 10:01 ` devfs Sean Neakums @ 2002-11-12 10:05 ` Xavier Bestel 1 sibling, 0 replies; 30+ messages in thread From: Xavier Bestel @ 2002-11-12 10:05 UTC (permalink / raw) To: john slee; +Cc: Ian Molton, Linux Kernel Mailing List Le mar 12/11/2002 à 10:49, john slee a écrit : > On Tue, Nov 12, 2002 at 10:43:41AM +0100, Xavier Bestel wrote: > > I'm wondering if a totally userspace solution could replace devs ? > > Something using hotplug + sysfs and creating directories/nodes as they > > appear on the system. This way, the policy (how do I name what) could be > > moved out of the kernel. > > curious! you mean similar to (and a logical extension of) the 'disks' > command in solaris? at least i think thats what its called... I don't know solaris (from an admin POV), but I meant something like, well, devfs. On top of which we could add feature like device naming stability across system upgrades (I know solaris does that). Xav ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: devfs 2002-11-12 9:43 ` devfs Xavier Bestel 2002-11-12 9:49 ` devfs john slee @ 2002-11-12 10:04 ` Alexander Viro 2002-11-12 10:25 ` devfs Ian Molton 2002-11-12 11:29 ` devfs Helge Hafting 2002-11-12 15:40 ` devfs Greg KH 2 siblings, 2 replies; 30+ messages in thread From: Alexander Viro @ 2002-11-12 10:04 UTC (permalink / raw) To: Xavier Bestel; +Cc: Ian Molton, Linux Kernel Mailing List On 12 Nov 2002, Xavier Bestel wrote: > I'm wondering if a totally userspace solution could replace devs ? > Something using hotplug + sysfs and creating directories/nodes as they > appear on the system. This way, the policy (how do I name what) could be > moved out of the kernel. Guys, may I remind you that Oct 31 had been more than a week ago? Devfs *is* a race-ridden pile of crap, but we are in a goddamn feature freeze, so let's get real. Interfaces can and should be cleaned up. Ditto for semantics of registering/unregistering - that allows to make glue in drivers more straightforward. Majestic flamewars about removing the thing completely/ moving it to userland/etc. are exercises in masturbation by that point. Again, WE ARE IN FEATURE FREEZE. Now, does somebody have technical comments on the proposed changes? ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: devfs 2002-11-12 10:04 ` devfs Alexander Viro @ 2002-11-12 10:25 ` Ian Molton 2002-11-12 10:46 ` devfs Dave Jones 2002-11-12 11:29 ` devfs Helge Hafting 1 sibling, 1 reply; 30+ messages in thread From: Ian Molton @ 2002-11-12 10:25 UTC (permalink / raw) To: Alexander Viro; +Cc: xavier.bestel, linux-kernel On Tue, 12 Nov 2002 05:04:41 -0500 (EST) Alexander Viro <viro@math.psu.edu> wrote: > Again, WE ARE IN FEATURE FREEZE. > > Now, does somebody have technical comments on the proposed > changes? And since when did feature freeze affect, as the guy said, *purely* userspace implementations? (can it be done with current hotplug/sysfs?) ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: devfs 2002-11-12 10:25 ` devfs Ian Molton @ 2002-11-12 10:46 ` Dave Jones 2002-11-12 11:08 ` devfs Ian Molton ` (2 more replies) 0 siblings, 3 replies; 30+ messages in thread From: Dave Jones @ 2002-11-12 10:46 UTC (permalink / raw) To: Ian Molton; +Cc: Alexander Viro, xavier.bestel, linux-kernel On Tue, Nov 12, 2002 at 10:25:35AM +0000, Ian Molton wrote: > > Again, WE ARE IN FEATURE FREEZE. > And since when did feature freeze affect, as the guy said, *purely* > userspace implementations? Since it would a *feature* to move it out of kernel space. To reiterate : _FEATURE_ _FREEZE_. Nothing[1] new[2] should be going into mainline at this point. We should now be in the stabilising period, where we don't require testers to have to upgrade their userspace every fortnight. Dave [1] Rusty's modules rewrite and whatever else Linus queed up seems to have exemption from this rule. Hopefully there isn't too much of this stuff. [2] Where 'new' can also mean 'bloody large reimplementation' -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: devfs 2002-11-12 10:46 ` devfs Dave Jones @ 2002-11-12 11:08 ` Ian Molton 2002-11-12 11:24 ` devfs Rando Christensen 2002-11-12 14:53 ` devfs Alan Cox 2 siblings, 0 replies; 30+ messages in thread From: Ian Molton @ 2002-11-12 11:08 UTC (permalink / raw) To: Dave Jones; +Cc: viro, xavier.bestel, linux-kernel On Tue, 12 Nov 2002 10:46:50 +0000 Dave Jones <davej@codemonkey.org.uk> wrote: > > And since when did feature freeze affect, as the guy said, *purely* > > userspace implementations? > > Since it would a *feature* to move it out of kernel space. > To reiterate : _FEATURE_ _FREEZE_. Nothing[1] new[2] > should be going into mainline at this point. nothing new WOULD be going in. nor would devfs need to move out - just disable it. It *is* still an option, is it not? > We should now be in the stabilising period, where we don't require > testers to have to upgrade their userspace every fortnight. its not a kernel issue anymore, if its totally in userspace, is it? ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: devfs 2002-11-12 10:46 ` devfs Dave Jones 2002-11-12 11:08 ` devfs Ian Molton @ 2002-11-12 11:24 ` Rando Christensen 2002-11-12 13:30 ` devfs Alexander Viro 2002-11-12 14:53 ` devfs Alan Cox 2 siblings, 1 reply; 30+ messages in thread From: Rando Christensen @ 2002-11-12 11:24 UTC (permalink / raw) To: Dave Jones; +Cc: spyro, viro, xavier.bestel, linux-kernel Tue, 12 Nov 2002 10:46:50 +0000: Dave Jones (Dave Jones <davej@codemonkey.org.uk>): > On Tue, Nov 12, 2002 at 10:25:35AM +0000, Ian Molton wrote: > > > Again, WE ARE IN FEATURE FREEZE. > > And since when did feature freeze affect, as the guy said, *purely* > > userspace implementations? > Since it would a *feature* to move it out of kernel space. > To reiterate : _FEATURE_ _FREEZE_. Nothing[1] new[2] > should be going into mainline at this point. Well, it does make sense to start planning out what might be done to devfs in the /next/ devel kernel, then. If one were so inclined, they could have a stable enough system for it ready for inclusion next time around, depending on who they get to test it. Clean up the devfs API for now, and start working on what might eventually replace it- Whether that's devfs2 or a purely userspace implementation or something new and wacky is up to whoever writes it. Rather than saying "Devfs sucks, and we can't do anything about it other than fix it's more minor problems because we're in feature freeze", we should be saying "devfs sucks; we're a little late for feature freeze, so let's clean up what we can and work on something much better for the next time around." Devfs as it is now is a nice idea, to me. It's an extremely organized /dev which is also an accurate portrayal of what's available to use on a particular machine. I'd hate to see it just ripped out entirely, and while they've never affected me, I've heard of many issues with it. I'd like to hear what ideas people may have /for/ a future replacement. -- < There is a light that shines on the frontier > < And maybe someday, We're gonna be there. > < Rando Christensen / rando@babblica.net > ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: devfs 2002-11-12 11:24 ` devfs Rando Christensen @ 2002-11-12 13:30 ` Alexander Viro 0 siblings, 0 replies; 30+ messages in thread From: Alexander Viro @ 2002-11-12 13:30 UTC (permalink / raw) To: Rando Christensen; +Cc: Dave Jones, spyro, xavier.bestel, linux-kernel On Tue, 12 Nov 2002, Rando Christensen wrote: > Rather than saying "Devfs sucks, and we can't do anything about it other > than fix it's more minor problems because we're in feature freeze", we > should be saying "devfs sucks; we're a little late for feature freeze, > so let's clean up what we can and work on something much better for the > next time around." Whatever is going to happen with devfs, believe me, the first thing you'll need is stable glue in drivers - as simple and natural from the driver POV as possible. Complexity of doing development in 2.6 will directly depend on the amount of code in drivers touched by patches. BTDT - one can carry (and gradually merge) deep rewrites of core code during -STABLE if it's done carefully. But as soon as your patchset hits the drivers - you are in for a world of pain just porting it to next versions. _That_ is critical - get interfaces right in -CURRENT, so that further work would not cross these boundaries; then work in the resulting areas becomes independent. And in situations like that of devfs, simple rules for callers are pretty much the main criteria - if users of the interface have to jump through some hoops, it's a sign that interface needs changes... ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: devfs 2002-11-12 10:46 ` devfs Dave Jones 2002-11-12 11:08 ` devfs Ian Molton 2002-11-12 11:24 ` devfs Rando Christensen @ 2002-11-12 14:53 ` Alan Cox 2002-11-12 15:37 ` devfs Ian Molton 2 siblings, 1 reply; 30+ messages in thread From: Alan Cox @ 2002-11-12 14:53 UTC (permalink / raw) To: Dave Jones Cc: Ian Molton, Alexander Viro, xavier.bestel, Linux Kernel Mailing List On Tue, 2002-11-12 at 10:46, Dave Jones wrote: > On Tue, Nov 12, 2002 at 10:25:35AM +0000, Ian Molton wrote: > > > Again, WE ARE IN FEATURE FREEZE. > > And since when did feature freeze affect, as the guy said, *purely* > > userspace implementations? > > Since it would a *feature* to move it out of kernel space. > To reiterate : _FEATURE_ _FREEZE_. Nothing[1] new[2] > should be going into mainline at this point. Who cares. You can do most of it already with hotplug and the remaining bits are very much "oops should tell hotplug" bug fixes nothing more. Alan ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: devfs 2002-11-12 14:53 ` devfs Alan Cox @ 2002-11-12 15:37 ` Ian Molton 0 siblings, 0 replies; 30+ messages in thread From: Ian Molton @ 2002-11-12 15:37 UTC (permalink / raw) To: Alan Cox; +Cc: davej, viro, xavier.bestel, linux-kernel On 12 Nov 2002 14:53:38 +0000 Alan Cox <alan@lxorguk.ukuu.org.uk> wrote: > > Since it would a *feature* to move it out of kernel space. > > To reiterate : _FEATURE_ _FREEZE_. Nothing[1] new[2] > > should be going into mainline at this point. > > Who cares. You can do most of it already with hotplug and the > remaining bits are very much "oops should tell hotplug" bug fixes > nothing more. The more I think about this userspace devfs, the more I like it. simple, clean, AND doesnt affect the kernel. Pure coding beauty. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: devfs 2002-11-12 10:04 ` devfs Alexander Viro 2002-11-12 10:25 ` devfs Ian Molton @ 2002-11-12 11:29 ` Helge Hafting 1 sibling, 0 replies; 30+ messages in thread From: Helge Hafting @ 2002-11-12 11:29 UTC (permalink / raw) To: Alexander Viro, Xavier Bestel; +Cc: linux-kernel Alexander Viro wrote: > > On 12 Nov 2002, Xavier Bestel wrote: > > > I'm wondering if a totally userspace solution could replace devs ? > > Something using hotplug + sysfs and creating directories/nodes as they > > appear on the system. This way, the policy (how do I name what) could be > > moved out of the kernel. > > Guys, may I remind you that Oct 31 had been more than a week ago? > Devfs *is* a race-ridden pile of crap, but we are in a goddamn feature > freeze, so let's get real. > A kernel feature freeze don't apply to a pure userspace implemetation, so let him try. :-) It won't affect the current devfs code, it'll simply be configured out. /dev on tmpfs, populated by hotplug. Could be interesting to see. [...] > Now, does somebody have technical comments on the proposed changes? Only the obvious - a cleanup is generally good and so is getting rid of unused parameters. Helge Hafting ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: devfs 2002-11-12 9:43 ` devfs Xavier Bestel 2002-11-12 9:49 ` devfs john slee 2002-11-12 10:04 ` devfs Alexander Viro @ 2002-11-12 15:40 ` Greg KH 2 siblings, 0 replies; 30+ messages in thread From: Greg KH @ 2002-11-12 15:40 UTC (permalink / raw) To: Xavier Bestel; +Cc: Ian Molton, Linux Kernel Mailing List On Tue, Nov 12, 2002 at 10:43:41AM +0100, Xavier Bestel wrote: > > I'm wondering if a totally userspace solution could replace devs ? > Something using hotplug + sysfs and creating directories/nodes as they > appear on the system. This way, the policy (how do I name what) could be > moved out of the kernel. Yes, that is _exactly_ what I am working on doing, and have stated as such on this list a number of times in the past. As for it being after the feature freeze comment, like Alan noted, everything is already present to do this, it's just going to take some more notifiers being added and some userspace code written. And no, even if all of this gets done, I would not want to remove devfs from the kernel, yet :) thanks, greg k-h ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: cerberus errors on 2.4.19 (ide dma related)
@ 2002-08-18 9:10 Alexander Viro
2002-08-18 9:16 ` Ed Sweetman
0 siblings, 1 reply; 30+ messages in thread
From: Alexander Viro @ 2002-08-18 9:10 UTC (permalink / raw)
To: Ed Sweetman; +Cc: linux-kernel
On 18 Aug 2002, Ed Sweetman wrote:
> (overview written in hindsight of writing email)
> I ran all these tests on ide/host2/bus0/target0/lun0/part1
Don't be silly - if you want to test anything, devfs is the last thing
you want on the system.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: cerberus errors on 2.4.19 (ide dma related) 2002-08-18 9:10 cerberus errors on 2.4.19 (ide dma related) Alexander Viro @ 2002-08-18 9:16 ` Ed Sweetman 2002-08-18 18:10 ` Ed Sweetman 0 siblings, 1 reply; 30+ messages in thread From: Ed Sweetman @ 2002-08-18 9:16 UTC (permalink / raw) To: Alexander Viro; +Cc: linux-kernel On Sun, 2002-08-18 at 05:10, Alexander Viro wrote: > > > On 18 Aug 2002, Ed Sweetman wrote: > > > (overview written in hindsight of writing email) > > I ran all these tests on ide/host2/bus0/target0/lun0/part1 > > Don't be silly - if you want to test anything, devfs is the last thing > you want on the system. > > OK, i can remove devfs, but I dont really see how that would make dma transfers (memory) become corrupted and pio mode transfers (memory) to not. I'm going to remove it, but i dont see how it's going to affect what's going on. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: cerberus errors on 2.4.19 (ide dma related) 2002-08-18 9:16 ` Ed Sweetman @ 2002-08-18 18:10 ` Ed Sweetman 2002-08-18 18:20 ` Sean Neakums 0 siblings, 1 reply; 30+ messages in thread From: Ed Sweetman @ 2002-08-18 18:10 UTC (permalink / raw) To: Alexander Viro; +Cc: linux-kernel It appears i'm completely unable to not use devfs. Attempting to run the kernel without mounting devfs results in it still being mounted or if not compiled in, locks up during boot. Attempts to run the kernel and mv /dev does not work, umounting /dev does not work and rm'ing /dev does not work. I cant create the non-devfs nodes while devfs is mounted and i cant boot the kernel without devfs. It seems that no uninstall procedure has been made and i've read the documentation that comes with the kernel about devfs and it says nothing about how to move back to the old device nodes from devfs. anyone have any suggestions? On Sun, 2002-08-18 at 05:16, Ed Sweetman wrote: > On Sun, 2002-08-18 at 05:10, Alexander Viro wrote: > > > > > > On 18 Aug 2002, Ed Sweetman wrote: > > > > > (overview written in hindsight of writing email) > > > I ran all these tests on ide/host2/bus0/target0/lun0/part1 > > > > Don't be silly - if you want to test anything, devfs is the last thing > > you want on the system. > > > > > > > OK, i can remove devfs, but I dont really see how that would make dma > transfers (memory) become corrupted and pio mode transfers (memory) to > not. > > I'm going to remove it, but i dont see how it's going to affect what's > going on. > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: cerberus errors on 2.4.19 (ide dma related) 2002-08-18 18:10 ` Ed Sweetman @ 2002-08-18 18:20 ` Sean Neakums 2002-08-18 18:29 ` Ed Sweetman 0 siblings, 1 reply; 30+ messages in thread From: Sean Neakums @ 2002-08-18 18:20 UTC (permalink / raw) To: linux-kernel commence Ed Sweetman quotation: > It appears i'm completely unable to not use devfs. Attempting to > run the kernel without mounting devfs results in it still being > mounted or if not compiled in, locks up during boot. Attempts to > run the kernel and mv /dev does not work, umounting /dev does not > work and rm'ing /dev does not work. I cant create the non-devfs > nodes while devfs is mounted and i cant boot the kernel without > devfs. It seems that no uninstall procedure has been made and i've > read the documentation that comes with the kernel about devfs and it > says nothing about how to move back to the old device nodes from > devfs. > > anyone have any suggestions? Where does the boot hang? If it comaplains about not being able to open /dev/console or some other device node, it may be that your /dev has no nodes in it. This happened to me when I eradicated devfs (I got fed up of fighting with devfsd to get my permission changes to stick, and had reshuffled FSes in the meantime) and so I booted from a rescue disk, mounted my root FS and recreated the device nodes in /mnt/dev. -- / | [|] Sean Neakums | Questions are a burden to others; [|] <sneakums@zork.net> | answers a prison for oneself. \ | ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: cerberus errors on 2.4.19 (ide dma related) 2002-08-18 18:20 ` Sean Neakums @ 2002-08-18 18:29 ` Ed Sweetman 2002-08-18 18:36 ` Sean Neakums 0 siblings, 1 reply; 30+ messages in thread From: Ed Sweetman @ 2002-08-18 18:29 UTC (permalink / raw) To: Sean Neakums; +Cc: linux-kernel I know i have no device nodes. I removed them all before installing devfs. the devfs documentation says it doesn't need to have devfs mounted to work, but this doesn't seem to be true at all. Hence my confusion. I know i can go download a bootable iso and get that burned and working but I shouldn't have to do that. On Sun, 2002-08-18 at 14:20, Sean Neakums wrote: > commence Ed Sweetman quotation: > > > It appears i'm completely unable to not use devfs. Attempting to > > run the kernel without mounting devfs results in it still being > > mounted or if not compiled in, locks up during boot. Attempts to > > run the kernel and mv /dev does not work, umounting /dev does not > > work and rm'ing /dev does not work. I cant create the non-devfs > > nodes while devfs is mounted and i cant boot the kernel without > > devfs. It seems that no uninstall procedure has been made and i've > > read the documentation that comes with the kernel about devfs and it > > says nothing about how to move back to the old device nodes from > > devfs. > > > > anyone have any suggestions? > > Where does the boot hang? If it comaplains about not being able to > open /dev/console or some other device node, it may be that your /dev > has no nodes in it. This happened to me when I eradicated devfs (I > got fed up of fighting with devfsd to get my permission changes to > stick, and had reshuffled FSes in the meantime) and so I booted from a > rescue disk, mounted my root FS and recreated the device nodes in > /mnt/dev. > > -- > / | > [|] Sean Neakums | Questions are a burden to others; > [|] <sneakums@zork.net> | answers a prison for oneself. > \ | > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: cerberus errors on 2.4.19 (ide dma related) 2002-08-18 18:29 ` Ed Sweetman @ 2002-08-18 18:36 ` Sean Neakums 2002-08-18 21:53 ` Barry K. Nathan 0 siblings, 1 reply; 30+ messages in thread From: Sean Neakums @ 2002-08-18 18:36 UTC (permalink / raw) To: linux-kernel commence Ed Sweetman quotation: > On Sun, 2002-08-18 at 14:20, Sean Neakums wrote: >> commence Ed Sweetman quotation: >> >> > It appears i'm completely unable to not use devfs. Attempting to >> > run the kernel without mounting devfs results in it still being >> > mounted or if not compiled in, locks up during boot. Attempts to >> > run the kernel and mv /dev does not work, umounting /dev does not >> > work and rm'ing /dev does not work. I cant create the non-devfs >> > nodes while devfs is mounted and i cant boot the kernel without >> > devfs. It seems that no uninstall procedure has been made and i've >> > read the documentation that comes with the kernel about devfs and it >> > says nothing about how to move back to the old device nodes from >> > devfs. >> > >> > anyone have any suggestions? >> >> Where does the boot hang? If it comaplains about not being able to >> open /dev/console or some other device node, it may be that your /dev >> has no nodes in it. This happened to me when I eradicated devfs (I >> got fed up of fighting with devfsd to get my permission changes to >> stick, and had reshuffled FSes in the meantime) and so I booted from a >> rescue disk, mounted my root FS and recreated the device nodes in >> /mnt/dev. >> > > I know i have no device nodes. I removed them all before installing > devfs. You must have been really keen on devfs. > the devfs documentation says it doesn't need to have devfs mounted > to work, but this doesn't seem to be true at all. If it does say exactly that, then it is outrageously wrong. > Hence my confusion. I know i can go download a bootable iso and get > that burned and working but I shouldn't have to do that. Uh, you deleted your devices nodes, and now you want to boot the system without devfs. You have to do precisely that, or something equivalent. -- / | [|] Sean Neakums | Questions are a burden to others; [|] <sneakums@zork.net> | answers a prison for oneself. \ | ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: cerberus errors on 2.4.19 (ide dma related) 2002-08-18 18:36 ` Sean Neakums @ 2002-08-18 21:53 ` Barry K. Nathan 2002-08-18 22:26 ` devfs Ed Sweetman 0 siblings, 1 reply; 30+ messages in thread From: Barry K. Nathan @ 2002-08-18 21:53 UTC (permalink / raw) To: linux-kernel On Sun, Aug 18, 2002 at 07:36:47PM +0100, Sean Neakums wrote: > commence Ed Sweetman quotation: [snip] > > the devfs documentation says it doesn't need to have devfs mounted > > to work, but this doesn't seem to be true at all. > > If it does say exactly that, then it is outrageously wrong. Starting at line 722 of linux-2.4.19/Documentation/filesystems/devfs/README: > In general, a kernel built with CONFIG_DEVFS_FS=y but without mounting > devfs onto /dev is completely safe, and requires no > configuration changes. I skimmed through the documentation and it appears to assume that you're not deleting all the stuff in /dev before switching over to devfs. > > Hence my confusion. I know i can go download a bootable iso and get > > that burned and working but I shouldn't have to do that. > > Uh, you deleted your devices nodes, and now you want to boot the > system without devfs. You have to do precisely that, or something > equivalent. Right, there's no way around that. If you deleted everything in /dev -- which you're not supposed to do -- then there's no way for anything to find any devices if devfs isn't enabled. (And you should have a rescue CD around anyway -- you never know when you might need it! BTW, what distribution are you (Ed) using? Some distributions have special boot options you can use when booting their install CDs to get into a rescue mode.) In any event, it might be a good idea to make the documentation a bit more explicit about this, and I might send a patch to the mailing list later today. -Barry K. Nathan <barryn@pobox.com> ^ permalink raw reply [flat|nested] 30+ messages in thread
* devfs 2002-08-18 21:53 ` Barry K. Nathan @ 2002-08-18 22:26 ` Ed Sweetman 2002-08-18 22:47 ` devfs Sean Neakums ` (2 more replies) 0 siblings, 3 replies; 30+ messages in thread From: Ed Sweetman @ 2002-08-18 22:26 UTC (permalink / raw) To: Barry K. Nathan; +Cc: linux-kernel On Sun, 2002-08-18 at 17:53, Barry K. Nathan wrote: > On Sun, Aug 18, 2002 at 07:36:47PM +0100, Sean Neakums wrote: > > commence Ed Sweetman quotation: > [snip] > > > the devfs documentation says it doesn't need to have devfs mounted > > > to work, but this doesn't seem to be true at all. > > > > If it does say exactly that, then it is outrageously wrong. > > Starting at line 722 of > linux-2.4.19/Documentation/filesystems/devfs/README: > > > In general, a kernel built with CONFIG_DEVFS_FS=y but without mounting > > devfs onto /dev is completely safe, and requires no > > configuration changes. > > I skimmed through the documentation and it appears to assume that you're > not deleting all the stuff in /dev before switching over to devfs. This has nothing to do with not mounting devfs and still using devfs to work with devices. If devfs is not mounted but you're still using devfs, you shouldn't need anything in /dev. The documentation says you can use devfs without mounting and This is what i'm saying is problematic and doesn't seem possible in normal usage. It's an optional config so are we using devfs when we dont mount it or not? and if not, then why make not mounting it an option ? If it's using the old device files in /dev then how can it be using devfs and how can accessing physical inodes on the disk be intentional to devfs? > Right, there's no way around that. If you deleted everything in /dev -- > which you're not supposed to do -- then there's no way for anything to > find any devices if devfs isn't enabled. (And you should have a rescue > CD around anyway -- you never know when you might need it! BTW, what > distribution are you (Ed) using? Some distributions have special boot > options you can use when booting their install CDs to get into a rescue > mode.) > > In any event, it might be a good idea to make the documentation a bit > more explicit about this, and I might send a patch to the mailing > list later today. I'm not talking about booting without devfs enabled being the problem, i know booting without devfs enabled I'll have issues booting the system without physical /dev entries, i was referring to having devfs enabled and not mounting it. Which according to the documentation should be perfectly functional and valid. This is not the case though. devfs should not require the old /dev entries at all since it doesn't use them so why would keeping them be required at all when using it (not counting the "if i want to not use devfs" argument). This is what should be cleared up in the documentation. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: devfs 2002-08-18 22:26 ` devfs Ed Sweetman @ 2002-08-18 22:47 ` Sean Neakums 2002-08-18 23:03 ` devfs Alexander Viro 2002-08-18 23:18 ` devfs Barry K. Nathan 2 siblings, 0 replies; 30+ messages in thread From: Sean Neakums @ 2002-08-18 22:47 UTC (permalink / raw) To: linux-kernel commence Ed Sweetman quotation: > On Sun, 2002-08-18 at 17:53, Barry K. Nathan wrote: >> On Sun, Aug 18, 2002 at 07:36:47PM +0100, Sean Neakums wrote: >> > commence Ed Sweetman quotation: >> [snip] >> > > the devfs documentation says it doesn't need to have devfs mounted >> > > to work, but this doesn't seem to be true at all. >> > >> > If it does say exactly that, then it is outrageously wrong. >> >> Starting at line 722 of >> linux-2.4.19/Documentation/filesystems/devfs/README: >> >> > In general, a kernel built with CONFIG_DEVFS_FS=y but without mounting >> > devfs onto /dev is completely safe, and requires no >> > configuration changes. >> >> I skimmed through the documentation and it appears to assume that you're >> not deleting all the stuff in /dev before switching over to devfs. > > This has nothing to do with not mounting devfs and still using devfs to > work with devices. If you don't mount devfs, you are not using it to "work with devices". You use your existing device nodes, unless you deleted them, in which case you are in trouble, as you discovered. > If devfs is not mounted but you're still using devfs, you shouldn't > need anything in /dev. If devfs is not mounted, you are not "using it". > The documentation says you can use devfs without mounting [...] It does not. It says that if devfs is built as part of your kernel's configuration and you do not mount it, everything works as before. For everythign to work as before, your device nodes need to be present. > and This is what i'm saying is problematic and doesn't seem possible > in normal usage. It's an optional config so are we using devfs when > we dont mount it or not? and if not, then why make not mounting it > an option ? I can imagine it being useful for for vendors. Makes it easy to make devfs usage a simple selection a install time without needsing to ship two different kernels. > If it's using the old device files in /dev then how can it be using > devfs and how can accessing physical inodes on the disk be > intentional to devfs? Dunno what you mean here. >> Right, there's no way around that. If you deleted everything in /dev -- >> which you're not supposed to do -- then there's no way for anything to >> find any devices if devfs isn't enabled. (And you should have a rescue >> CD around anyway -- you never know when you might need it! BTW, what >> distribution are you (Ed) using? Some distributions have special boot >> options you can use when booting their install CDs to get into a rescue >> mode.) >> >> In any event, it might be a good idea to make the documentation a bit >> more explicit about this, and I might send a patch to the mailing >> list later today. > > I'm not talking about booting without devfs enabled being the problem, i > know booting without devfs enabled I'll have issues booting the system > without physical /dev entries, i was referring to having devfs enabled > and not mounting it. Which according to the documentation should be > perfectly functional and valid. This is not the case though. BECAUSE YOU DELETED YOUR DEVICE NODES. > devfs should not require the old /dev entries at all since it > doesn't use them so why would keeping them be required at all when > using it (not counting the "if i want to not use devfs" argument). > This is what should be cleared up in the documentation. devfs does not require your old devices nodes. Nowhere does the documentation say that it does. HOWEVER, if you want to boot a devfs-capable kernel and not mount devfs (or simply boot a kernel with no devfs capability at all), you have to have SOMETHING in /dev, i.e. a set of standard device nodes. -- / | [|] Sean Neakums | Questions are a burden to others; [|] <sneakums@zork.net> | answers a prison for oneself. \ | ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: devfs 2002-08-18 22:26 ` devfs Ed Sweetman 2002-08-18 22:47 ` devfs Sean Neakums @ 2002-08-18 23:03 ` Alexander Viro 2002-08-18 23:15 ` devfs Ed Sweetman 2002-08-19 1:06 ` devfs Olivier Galibert 2002-08-18 23:18 ` devfs Barry K. Nathan 2 siblings, 2 replies; 30+ messages in thread From: Alexander Viro @ 2002-08-18 23:03 UTC (permalink / raw) To: Ed Sweetman; +Cc: Barry K. Nathan, linux-kernel On 18 Aug 2002, Ed Sweetman wrote: > This has nothing to do with not mounting devfs and still using devfs to > work with devices. If devfs is not mounted but you're still using > devfs, you shouldn't need anything in /dev. The documentation says you > can use devfs without mounting and This is what i'm saying is > problematic and doesn't seem possible in normal usage. It's an > optional config so are we using devfs when we dont mount it or not? > and if not, then why make not mounting it an option ? What? If program calls open("/dev/zero",...) and there's no such file, how the fuck would having devfs enabled help you? Come on, use common sense - devfs provides a tree with some device nodes. You can mount it wherever you want (or not mount it anywhere). Just as with any other filesystem. If you mount it on /dev - well, duh, you see that tree on /dev. If you do not - you see whatever is in /dev on underlying fs. If program wants to access a device, it opens that device. Just as any other file. By name. There is nothing magical about names that begin with /dev/ - it's just a conventional place for device nodes. devfs "mount" option is an idiotic kludge that makes _kernel_ mount it on /dev after the root fs had been mounted. Why it had been introduced is a great mistery, since the normal way is to have a corresponding line in /etc/fstab and have userland mount whatever it needs. Said option is, indeed, not required for anything - in a sense that it does nothing that system wouldn't be perfectly capable of in regular ways. But you _do_ need stuff in /dev, no matter what filesystem it comes from. Kernel doesn't need it, but userland programs expect to find it there. If you had deleted device nodes from underlying /dev and do not care to mount something on top of it - well, there won't be anything in that directory. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: devfs 2002-08-18 23:03 ` devfs Alexander Viro @ 2002-08-18 23:15 ` Ed Sweetman 2002-08-21 4:49 ` devfs Richard Gooch 2002-08-19 1:06 ` devfs Olivier Galibert 1 sibling, 1 reply; 30+ messages in thread From: Ed Sweetman @ 2002-08-18 23:15 UTC (permalink / raw) To: Alexander Viro; +Cc: Barry K. Nathan, linux-kernel On Sun, 2002-08-18 at 19:03, Alexander Viro wrote: > > > On 18 Aug 2002, Ed Sweetman wrote: > > > This has nothing to do with not mounting devfs and still using devfs to > > work with devices. If devfs is not mounted but you're still using > > devfs, you shouldn't need anything in /dev. The documentation says you > > can use devfs without mounting and This is what i'm saying is > > problematic and doesn't seem possible in normal usage. It's an > > optional config so are we using devfs when we dont mount it or not? > > and if not, then why make not mounting it an option ? > > What? If program calls open("/dev/zero",...) and there's no such file, > how the fuck would having devfs enabled help you? > > Come on, use common sense - devfs provides a tree with some device nodes. > You can mount it wherever you want (or not mount it anywhere). Just as > with any other filesystem. > > If you mount it on /dev - well, duh, you see that tree on /dev. If you > do not - you see whatever is in /dev on underlying fs. > > If program wants to access a device, it opens that device. Just as any > other file. By name. There is nothing magical about names that begin > with /dev/ - it's just a conventional place for device nodes. > > devfs "mount" option is an idiotic kludge that makes _kernel_ mount > it on /dev after the root fs had been mounted. Why it had been > introduced is a great mistery, since the normal way is to have a > corresponding line in /etc/fstab and have userland mount whatever > it needs. > > Said option is, indeed, not required for anything - in a sense that > it does nothing that system wouldn't be perfectly capable of in regular > ways. > > But you _do_ need stuff in /dev, no matter what filesystem it comes > from. Kernel doesn't need it, but userland programs expect to find > it there. If you had deleted device nodes from underlying /dev and > do not care to mount something on top of it - well, there won't be > anything in that directory. > Ok, that all makes sense. I removed the dev entries because they weren't needed by me anymore but I suppose it doesn't hurt anything to just keep them there anyways so I've fixed all that. Either way, removing devfs did nothing but apparently it was asked to be done to allow better testing and/or debugging to be done. But i've yet to get any reason why I removed devfs to investigate promise ide controller's dma related memory failures. I've removed devfs and replaced the old /dev entries, no problem. I'm not getting off topic about that. It's all done so i'm waiting for the next step here. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: devfs 2002-08-18 23:15 ` devfs Ed Sweetman @ 2002-08-21 4:49 ` Richard Gooch 2002-08-21 5:03 ` devfs Ed Sweetman 0 siblings, 1 reply; 30+ messages in thread From: Richard Gooch @ 2002-08-21 4:49 UTC (permalink / raw) To: Ed Sweetman; +Cc: linux-kernel Ed Sweetman writes: > Ok, that all makes sense. I removed the dev entries because they > weren't needed by me anymore but I suppose it doesn't hurt anything > to just keep them there anyways so I've fixed all that. Either way, > removing devfs did nothing but apparently it was asked to be done to > allow better testing and/or debugging to be done. But i've yet to > get any reason why I removed devfs to investigate promise ide > controller's dma related memory failures. I've removed devfs and > replaced the old /dev entries, no problem. I'm not getting off > topic about that. It's all done so i'm waiting for the next step > here. It seems the reason you removed devfs is that you followed Al's bad advice: Alexander Viro writes: > Don't be silly - if you want to test anything, devfs is the last > thing you want on the system. In fact, devfs works quite robustly for many people, and wasn't involved in the IDE problems you were having. Al is an absolutist: if it's not 100% provably correct, it falls into his other category, "spawn of satan". So next time someone claims devfs is causing you problems, treat it with the skepticism it deserves. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: devfs 2002-08-21 4:49 ` devfs Richard Gooch @ 2002-08-21 5:03 ` Ed Sweetman 0 siblings, 0 replies; 30+ messages in thread From: Ed Sweetman @ 2002-08-21 5:03 UTC (permalink / raw) To: Richard Gooch; +Cc: linux-kernel On Wed, 2002-08-21 at 00:49, Richard Gooch wrote: > It seems the reason you removed devfs is that you followed Al's bad > advice: > Alexander Viro writes: > > Don't be silly - if you want to test anything, devfs is the last > > thing you want on the system. > > In fact, devfs works quite robustly for many people, and wasn't > involved in the IDE problems you were having. Al is an absolutist: if > it's not 100% provably correct, it falls into his other category, > "spawn of satan". > > So next time someone claims devfs is causing you problems, treat it > with the skepticism it deserves. > > Regards, > > Richard.... Ok, well the more happy the people who have the ability to know what the problem is the better so despite a simple usb issue, moving out of devfs wasn't a hassle. I'm willing to move back to vanilla if it helps in chasing a problem down. I'm just kind of disappointed that the discussion of me playing around with devfs got more attention from the ide guys than the actual problem since it seems to be strictly DMA related and not a drive problem so if it's chipset conflicts it should be documented either in the good-bad firmware so the kernel disables dma on boot of this particular promise chipset when this particular via chipset is present or in the HELP for the config option so at least users are aware that drive corruption has been known to happen on the linux promise driver when dma is enabled on some via chipsets. That is unless it's a fixable problem. Which i rather hope it is. neither the abit motherboard or promise controller card are uncommon. But since nobody i know has via + promise setups I cant ask them to run the cerberus test to see the same behavior to see the extent of the promise + via problems or if it's even got anything to do with via. (shrugs) ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: devfs 2002-08-18 23:03 ` devfs Alexander Viro 2002-08-18 23:15 ` devfs Ed Sweetman @ 2002-08-19 1:06 ` Olivier Galibert 2002-08-19 2:01 ` devfs Greg KH 1 sibling, 1 reply; 30+ messages in thread From: Olivier Galibert @ 2002-08-19 1:06 UTC (permalink / raw) To: linux-kernel On Sun, Aug 18, 2002 at 07:03:42PM -0400, Alexander Viro wrote: > devfs "mount" option is an idiotic kludge that makes _kernel_ mount > it on /dev after the root fs had been mounted. Why it had been > introduced is a great mistery, since the normal way is to have a > corresponding line in /etc/fstab and have userland mount whatever > it needs. I've been wondering, imagine that in the future we have a working dynamic device filesystem (be it devfs, driverfs, whatever) nice enough that we don't want a disk-based /dev anymore. How are we supposed to mount it so that the kernel's open("/dev/console") succeeds? OG. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: devfs 2002-08-19 1:06 ` devfs Olivier Galibert @ 2002-08-19 2:01 ` Greg KH 0 siblings, 0 replies; 30+ messages in thread From: Greg KH @ 2002-08-19 2:01 UTC (permalink / raw) To: Olivier Galibert, linux-kernel On Sun, Aug 18, 2002 at 09:06:18PM -0400, Olivier Galibert wrote: > > I've been wondering, imagine that in the future we have a working > dynamic device filesystem (be it devfs, driverfs, whatever) nice > enough that we don't want a disk-based /dev anymore. How are we > supposed to mount it so that the kernel's open("/dev/console") > succeeds? initramfs might already contain a minimial /dev that has those kinds of entries in it. thanks, greg k-h ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: devfs 2002-08-18 22:26 ` devfs Ed Sweetman 2002-08-18 22:47 ` devfs Sean Neakums 2002-08-18 23:03 ` devfs Alexander Viro @ 2002-08-18 23:18 ` Barry K. Nathan 2 siblings, 0 replies; 30+ messages in thread From: Barry K. Nathan @ 2002-08-18 23:18 UTC (permalink / raw) To: Ed Sweetman; +Cc: Barry K. Nathan, linux-kernel On Sun, Aug 18, 2002 at 06:26:35PM -0400, Ed Sweetman wrote: > On Sun, 2002-08-18 at 17:53, Barry K. Nathan wrote: [snip] > > Starting at line 722 of > > linux-2.4.19/Documentation/filesystems/devfs/README: > > > > > In general, a kernel built with CONFIG_DEVFS_FS=y but without mounting > > > devfs onto /dev is completely safe, and requires no > > > configuration changes. > > > > I skimmed through the documentation and it appears to assume that you're > > not deleting all the stuff in /dev before switching over to devfs. > > This has nothing to do with not mounting devfs and still using devfs to > work with devices. If devfs is not mounted but you're still using > devfs, you shouldn't need anything in /dev. IMO the combination of common sense and a little Linux/Unix knowledge would suggest that you can't use a filesystem if it's not mounted. (Also, see my next paragraph in this message.) > The documentation says you > can use devfs without mounting No, that's not what it says. It says that you can run a kernel with devfs enabled but not mounted. This does not imply that devfs is in use and providing the device nodes, just that it is enabled and present in the event that it should be mounted. > and This is what i'm saying is > problematic and doesn't seem possible in normal usage. It's an > optional config so are we using devfs when we dont mount it or not? > and if not, then why make not mounting it an option ? Why make not mounting it an option? There's more than one reason. You might want to wait until well into the boot process before mounting it (I think this one's mentioned in the documentation but I'm not 100% sure). You might also want to temporarily disable devfs mounting to avoid a security hole in the event that one is found in devfs, until an updated kernel is available (this actually happened earlier this year with recent Mandrake Linux releases that use devfs by default). > If it's using the old device files in /dev then how can it be using > devfs and how can accessing physical inodes on the disk be intentional > to devfs? If it's using the old /dev nodes then it's not using devfs -- but you can switch over later after or during boot. > > In any event, it might be a good idea to make the documentation a bit > > more explicit about this, and I might send a patch to the mailing > > list later today. > > I'm not talking about booting without devfs enabled being the problem, i > know booting without devfs enabled I'll have issues booting the system > without physical /dev entries, i was referring to having devfs enabled > and not mounting it. Which according to the documentation should be > perfectly functional and valid. This is not the case though. devfs > should not require the old /dev entries at all since it doesn't use them > so why would keeping them be required at all when using it (not counting > the "if i want to not use devfs" argument). This is what should be > cleared up in the documentation. I believe you misunderstood the existing documentation. Nonetheless it probably should be clarified, and I'm about to send a patch to the mailing list. -Barry K. Nathan <barryn@pobox.com> ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2002-11-14 11:40 UTC | newest] Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-11-12 9:32 devfs Ian Molton 2002-11-12 9:43 ` devfs Xavier Bestel 2002-11-12 9:49 ` devfs john slee 2002-11-12 10:01 ` devfs Sean Neakums 2002-11-12 12:51 ` devfs Oliver Neukum 2002-11-13 10:48 ` hotplug (was devfs) Nick Craig-Wood 2002-11-13 17:02 ` Greg KH 2002-11-13 18:06 ` Nick Craig-Wood 2002-11-13 18:04 ` Greg KH 2002-11-14 11:46 ` Oliver Neukum 2002-11-12 10:05 ` devfs Xavier Bestel 2002-11-12 10:04 ` devfs Alexander Viro 2002-11-12 10:25 ` devfs Ian Molton 2002-11-12 10:46 ` devfs Dave Jones 2002-11-12 11:08 ` devfs Ian Molton 2002-11-12 11:24 ` devfs Rando Christensen 2002-11-12 13:30 ` devfs Alexander Viro 2002-11-12 14:53 ` devfs Alan Cox 2002-11-12 15:37 ` devfs Ian Molton 2002-11-12 11:29 ` devfs Helge Hafting 2002-11-12 15:40 ` devfs Greg KH -- strict thread matches above, loose matches on Subject: below -- 2002-08-18 9:10 cerberus errors on 2.4.19 (ide dma related) Alexander Viro 2002-08-18 9:16 ` Ed Sweetman 2002-08-18 18:10 ` Ed Sweetman 2002-08-18 18:20 ` Sean Neakums 2002-08-18 18:29 ` Ed Sweetman 2002-08-18 18:36 ` Sean Neakums 2002-08-18 21:53 ` Barry K. Nathan 2002-08-18 22:26 ` devfs Ed Sweetman 2002-08-18 22:47 ` devfs Sean Neakums 2002-08-18 23:03 ` devfs Alexander Viro 2002-08-18 23:15 ` devfs Ed Sweetman 2002-08-21 4:49 ` devfs Richard Gooch 2002-08-21 5:03 ` devfs Ed Sweetman 2002-08-19 1:06 ` devfs Olivier Galibert 2002-08-19 2:01 ` devfs Greg KH 2002-08-18 23:18 ` devfs Barry K. Nathan
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).