Am Sonntag, 9. Dezember 2001 05:46 schrieb David Brownell:
> > > Today that's a two level action. Devices' "true names" are
> > > triples {char or block, major, minor}, which make a finite
> > > set of names (16 bits today, 32 bits soonish) exposed
> > > as "dev_t" to userland ... for some devices, but not all
> > > (consider network interfaces). In some cases "devfs"
> > > might assign those "true names" for you.
> >
> > Where is the sense of having these, if you can't keep them stable anyway
> > ? (Except for backwards compatibility)
>
> That topic has been discussed on LKML from time to time.
> Linus is currently talking about abolishing them in the 2.5
> series, as you may know. Radical change is in the air.
Any further comment on that is like discussing religion ;-)
[..]
> > What for ? What's wrong with using a name the kernel provides ?
> > If you really, really want other names, symlinks can be used.
>
> The issue is that it "chooses" the name (a policy function)
> and thereby complicates things. Since there's got to be a
> policy stage in userland anyway, why not have it make the
> WHOLE policy choice instead just "what symlink?".
>
> That is, turn it around. Why should the kernel do this at all?
Because it allows the system to work under rough conditions.
If the kernel chooses, publishes and recognises names on its own, the system
retaines some function in emergency, after the user space support has crashed.
If the policy demon chooses a name, there needs to be some sort of callback
or a mknod. That is a brittle scheme which requires tight synchronisation
between kernel and demon to avoid race conditions.
The stages of device detection and device configuration should be as divorced
as possible.
> Those policies have always been in userland -- except for
> networking devices, where problems come up because the
> interface names are so sensitive to how the kernel is linked
> and configured. Hotplugging only adds one new requirement:
> that the choices must be "dynamic", rather than "static" when
> distributions create their /dev/* device trees. (That "static"
> model started when UNIX had eight bit UIDs and no GIDs...)
>
> The exception is "devfs", which hasn't been widely popular;
> in part that's because of the names it chose.
And in part due to some races.
> > > If the hotplug events were reported at that level, I could imagine
> > > several modes of hotplugging: one where all "function level"
> > > name bindings were chosen by user mode policy actions,
> > > another where they were chosen by kernel policy and then
> > > maybe tweaked later (as today, even with devfs), and perhaps
> > > more ideally one where there was some degree of cooperation
> > > to get rid of that "tweak it later" race.
> >
> > It seems to me that this scheme introduces unnecessarily complex
> > callbacks to kernel space into the picture.
>
> Which one, why? Clearly not that second mode, since it's basically
> what happens today. I didn't describe how the other modes might work.
> What design were you thinking of? Sounds like it can be improved ... :)
Chosing names.
> > There is an issue with the logical name depending on the drivers loaded.
> > So indeed a two level scheme would serve better.
>
> Or in fact, "which driver is selected", and (as maybe you meant)
Yes
> "what other modules got to initialize first".
>
> But to repeat, today Linux (all UNIXes) works with such a two level
> scheme for device naming -- my question is how hotplugging should
> benefit from changes coming in 2.5, since we know that some some
> changes in those areas are on the way.
Firstly we are not yet sure what the Alpha Penguin will do,
and secondly IMHO we should first discuss needs and consequences.
What we know is that the kernel is not planed to work with major:minor.
It'll just publish unique, but variable numbers to user space. If we decide
that we need stable names, we have implicitely decided that we need a system
to assign those to unstable numbers.
I just don't see how we can make a truly robust system with this scheme.
Regards
Oliver
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
