> > > 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.
> >
> > As a data point, PCMCIA passes quite a bit more info
> > than that ... and I think it's right to make it so
> > that most scripts won't need to reparse descriptors.
>
> It passes such things as ethernet addresses and the such.
It's "the such" that's interesting ... :-)
It should be easy for scripts to do things like add special
cases for flakey devices (say, vendor 0x1234 product 0x5678
has a particular bug that needs tending). And to recognize
specific (nonflakey) device-to-driver mappings, too.
> > > Take a look at my userspace driver binding email and
> > > you'll see that it
> > > provides solutions for some of these questions.
> >
> > There was a bit too much info there ...
>
> > Perhaps you could summarize in brief? (With change in
> > subject line, please!) It's really the work of just an
> > hour or so to come up with a daemon that can fork off
> > such scripts. No kernel patches beyond pre7-3 ... ;-)
>
> Take a look at the description, not the implementation.
The URL you'd provided is for the latter, not the former.
(The first link in the posting seems to be the former.)
Much of what I saw there seems more oriented to 2.5 series
evolution. The kernel needs a good distinction between
interface and device claiming, which will affect some of
the issues you mentioned there. It should be easy to have
some non-kernel module assign drivers to devices ... which
seems to turn the current probing model around (drivers
make some policy choices).
The pseudocode that _doesn't_ depend on such new features
could help resolve some of the "which goes first" style
questions, though it does seem to assume that if scripts
are the implementation, they'll have access to parsed
values for idVendor/idProduct, class/subclass/protocol,
and other values you implied shouldn't be passed ... :-)
- Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
