> Aside from maintaining thousands of device nodes, you cannot
> know in advance what e.g. /dev/sg3 refers to, when USB comes into
> the play.
> /dev/video0 being the camera peeking into the hall, is different from
> that into the bathroom ;-)
I try not to stay at that sort of hotel, personally.
> > > To handle permissions together with
> > > hotplugging a demon must be running. And it needs kernel hooks to
> > > work without races.
> >
> > The last time this came up, I don't recall any
> > races being identified. If the device node starts
> > with, say, root ownership and permision 0600, and
> > some process comes by (say, around login time)
> > and chowns it to "oliver", what's the race?
>
> The race is there as soon as a device is removed and another added.
I think I see what you mean, but please elaborate.
The last time that issue came up, folk pointed out
that if the file descriptor remains open, it should
not suddenly begin referring to a different object
(security problem, huge) ... so there are some ways
that this can safely be addressed.
> > printer to identify itself. A USB utility was recently posted
> > to do that with the IEEE-1284 printer IDs, for example.
>
> In this particular example that is practical. In the general case you
> are duplicating drivers in user space, which is suboptimal.
Or you could get rid of the kernel code in some cases,
which often wins points in beauty contests.
> > > There is no sense in duplicating devfs+devfsd.
> >
> > Of course not. You can do it with a much smaller framework
> > already! http://linux-usb.sourceforge.net/usb-admin.html
> > has more information about how USB device plugin can make
> > Linux "do the right thing" (load driver etc) ... all you
> > need to do is hook up a shell script to do the fixup that's
> > right for your particular system.
>
> Interresting page. Thanks for the pointer.
>
> But these solutions
>
> a) require usbdevfs
Well, not the "kUSBD" implementation. I've certainly
been quite successful at using that without usbdevfs
in the vicinity. (I think most non-embedded systems
will want it just to get some help in troubleshooting.)
> b) suffer from the race mentioned above (at a smaller window)
I hate to say it ... but again: not the "kUSBD" implementation.
The reason I hate to say it is that it's actually hijacking
the "khubd" thread. Which means that those policy agent
scripts had really better not take a lot of time to figure
what drivers to modprobe. Still ... no trouble so far, and
it does address the problem you mentioned. (Plus I wonder
if maybe the early time-critical parts of USB enumeration
shouldn't be asynchronously driven, anyway.)
Oh -- and not the "jUSBD" implementation either! It keeps
the file descriptor open, and Thomas Sailer has promised that
will suffice to keep that USB address from getting reclaimed.
[ Raising an interesting question about Denial of Service
attacks and why the filenames need to encode USB addresses,
but let's not take that debate on for now. ]
> And usbdevfs, in spite of claims to the contrary, is a form of devfs.
So long as you say "a form of" ... agreed. The problem spaces
being explored are not identical, and there's important stuff
to be learned (over the next year) about the differences.
> > Oh -- and that one works for the cases that the 2.4 devfs
> > will not solve, such as USB devices which don't have any
> > dedicated device nodes on the filesystem. Mice, keyboards,
> > and so on (in typical configurations).
>
> You are right. An extension to the devfs+devfsd scheme is needed.
See above. If it's working now, I think the "need" may
not be all that strong ... :-)
> IMHO kmod should load the drivers upon device plugging.
Nah, that'd mean too much policy knowledge inside the kernel.
The sort of stuff that changes a lot, and administrators need
to be able to update the policies.
The most I could justify the kernel getting involved is
telling some user mode service something about the new
devices that appear. The "kUSBD" approach tells that
service by running a program. (Which is straightforward,
though clearly not the only solution.)
Now to be sure, it's "kmod" which runs that program, but
it's the program which will consult a database to figure
out what the heck to do with this new device, and maybe
then issue "modprobe" ... :-)
- Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
