Am Sonntag, 9. Dezember 2001 01:21 schrieb David Brownell:
> > > 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.
The number of names is not as high as one might think.
Let me list naming schemes
a)physical bus location
b)serial number
c)vendor/product id + running number
d)logical kernel driver + serial number
> 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)
> 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.
Important is that you have a choice to use the name based on the
characteristics you need. You just have to be consistent with the name you
use in most cases, though not all.
[..]
> 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.
If you let the kernel set initial permissions there is no race. A device with
permissions 000 (or network: down) is not there effectively. There might be
an issue with mountable block devices, though.
There is an issue with the logical name depending on the drivers loaded.
So indeed a two level scheme would serve better.
Regards
Oliver
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
