> Well, he still has a point. There are two subsystems with widly overlapping
> functions. I must say, I feel this is not good. Yet, I have no clue what to
> do. Any ideas ?
I think about security and device naming models here...
Hardware access is classically privileged, for all kinds of fine reasons.
Done in-kernel, by trustworthy code. (Normally one says "trusted code",
but that's the issue: not all code that's "trusted" is actually worthy of that
trust. Consider IIS, or your favorite bug-ridden software ... :)
Device drivers exist to make sure that hardware access is done in safe
ways, that don't corrupt the environment and which are controllable by the
system operator. It's a relatively modern notion that they might work in
user mode, in classically "untrustworthy" code, or under control of the
end user (also classically "untrustworthy"). Sure, some operating systems
ran drivers in non-kernel rings, giving user code with even fewer privileges.
Hardware today doesn't tend to handle that kind of model though, and
don't get me started on technology models ignoring folk using the tech
(to exclusively benefit other people).
What I'm getting at is that here's a place where stepping back to look at
the real problem -- and see how it's solved in other places! -- may be a
good idea.
- Where else does Linux use user mode drivers?
* Frame buffer access for performance: DRI, DRM.
* Printers, mostly (nowadays) using a serial byte-stream
model to less performance-sensitive rendering systems.
* Scanners (SANE) using serial byte-stream models
* Various serial devices (most digital cameras :) that
use serial byte-stream models.
* ... surely a few others, but notice that pattern.
- Where do other UNIXes use them?
* Same as Linux
* ... any notable differences?
- How about non-POSIXey systems like Win32, Mac, BeOS?
* ... not just ones that keep apps from touching hardware ...
One complication for USB -- not shared with any of the more
traditional device models! -- is hotplugging. Devices can be,
and are, added/removed at any time. They can move around.
The primary policy hook for security is to name a device. But
hotplugging means those names can change...
There needs to be some step that says "here's a new device,
how should it be exposed for general use?" And the answer
to that question needs to include permissions. I suppose we
should assume those still get associated with device names,
so as not to rock the boat too much.
Of course they don't _always_ move around, and in cases
where the device doesn't move (tree of USB devices that's
set up and not changed, maybe) it'd be a good idea to save
those answers and expect them to work next time around.
That relies on user space tools having stable names for
USB (and other hotpluggable) devices; we don't have those
today, due to "usbdevfs" limitations. (The Java USB APIs
layer such names on top, but with some difficulty.)
In fact you can look at that "device config is stable" setup
as the traditional hardware norm, the one for which today's
major/minor and /dev/* (even "devfs") naming scheme was
designed.
That's just some musings on the problem, which I'm hoping
may help trigger useful insights from other folk. No answers
yet, beyond saying that the unstable naming in "usbdevfs"
is part of the problem.
- Dave
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
