> > What I was getting at is that assigning names at the "logical"
> > layer, where function matters, changes in a hotpluggable world.
> >
> > Assigning those function-based names in the kernel is part
> > of the problem: it can maybe make a decent first guess,
> > but before the device is advertised to the world, something
> > smarter (like a user mode policy agent) may need to apply
> > some real intelligence to the problem.
>
> Why can't the kernel export all possible names?
It can. I think that's a "practically infinite" set, yes? :)
What it _does_ export is the names that it's told to export.
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.
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
use them, and the other policies also need to match. Exporting
devices over the network is IMO best done as a function-aware
service, but that's a separate discussion.
In 2.5 such approaches may be more doable. The "device
filesystem" looks to be purely at the physical layer. It could hold
the "true name", export it to userland policy agents that work
much more consistently than dev_t does.
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.
- Dave
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
