> > That was the intention. And the /proc/bus/usb/devices was exactly
> > meant to wake up that daemon. Beginnings of such a daemon are
> > in the usb.in.tum.de CVS, feel free to continue working on it...
The current Java USB code (http://jusb.sourceforge.net)
has similar functionality: a daemon thread notifies
interested parties about device add/remove.
The "fun" bit is that the viewer app now updates itself
as you plug and unplug devices ... a live USB display!
But the specific relevance here is that it's easy to
write and plug in a module that can spawn other programs
when new devices show up. Shell scripts, for example.
> So IMHO its best to follow the PCMCIA model which is
>
> kernel->user message (or poll and scan)
> Run the matching script set
> Let user policy dictate what gets kicked
Shell scripts execution shouldn't be the only action
that can be taken, though it's likely time to start
agreeing on how and when to invoke scripts.
I'm thinking we need design answers like:
- Do we invoke /etc/usb/*.policy scripts? (Sure.)
- As root? (If we want to modprobe or do similar
system reconfiguration, yes.)
- How do we break down different scripts? (class
and device specific scripts each seem necessary.
which first?)
- What are the parameters to the scripts? (let's
see ... /proc/bus/usb/003/093 , class/sub/proto,
manufacturer and product ids, plug/unplug, and
surely a lot more. Passing as variables seems
most general to me. HID descriptors likely need
to be parsed.)
That seems like it'd be enough to start with.
- Dave
(*) It'll poll() as soon as that issue gets more
important than some other one. The API will
not change at that point; just how one thread
does its job, affecting its CPU/memory profiles.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
