> > 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.
> > Then those devices (again, not all of them) are exported
> > to userland by "mknod" (VFS names, practically infinite).
> > Again, "devfs" might do that for you.
> >
> > (Most char/block device drivers expect to have only one
> > mknod, else device locking/open/close/security models
> > start to break. Maybe that's what you were getting at...)
> >
> > > The agent could then decide
> > > which device to make accessible (by giving permissions) and use it to do
> > > any configuration/mounting/export over network ...
> >
> > Instead of "give permissions" there, think "publish names"
> > with permissions as only one part of the access policy being
> > described. (Look at the "mknod" parameters... this is at that
> > logical/functional level, not at the physical level.) Such names
> > need to be chosen to make sense to the applications that will
>
> 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?
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.
> > 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 ... :)
> 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)
"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.
- Dave
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
