devfs

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...

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

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/

commence john slee quotation:

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;
[|] <[email protected]>     |      answers a prison for oneself.
 \                          |

Nope, no serialisation. You don't have any guarantee even that addition will be delivered before removal.

Regards
Oliver

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
[email protected]

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.

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

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!

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.

Userspace serialisation would have solved this problem for us too I think without the extra mapping mechanism.

Nick Craig-Wood
[email protected]

Yes, that is the goal.

thanks,

greg k-h

We may need some kind of load control.
The thought of firing up hundreds of hotplug scripts simultaneously is not pretty.

Regards
Oliver

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

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?

And since when did feature freeze affect, as the guy said, *purely* userspace implementations?

(can it be done with current hotplug/sysfs?)

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

nothing new WOULD be going in. nor would devfs need to move out - just disable it. It *is* still an option, is it not?

its not a kernel issue anymore, if its totally in userspace, is it?

Tue, 12 Nov 2002 10:46:50 +0000: Dave Jones (Dave Jones <[email protected]>):

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 / [email protected]    >

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...

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

The more I think about this userspace devfs, the more I like it. simple, clean, AND doesnt affect the kernel.

Pure coding beauty.

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.

[...]

Only the obvious - a cleanup is generally good and so is getting rid of unused parameters.

Helge Hafting

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