On Thu, May 04, 2000, David Brownell <[EMAIL PROTECTED]> wrote:
> > > 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...
If that's all it's used for, devfs has the same thing already, but you
don't have to scan the bus to see what's changed.
It tells you specifically what was added and what was removed.
> > 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.)
Each device needs different information. I think only the device name
and plug/unplug should be passed and let the script/program determine
the rest of what it needs.
> That seems like it'd be enough to start with.
Hmm, it's good to see people finally looking into the problems I brought
up a couple of weeks ago.
Take a look at my userspace driver binding email and you'll see that it
provides solutions for some of these questions.
JE
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
