On Thu, May 04, 2000, David Brownell <[EMAIL PROTECTED]> wrote:
> > > 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.
Yup.
> > > 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.)
Yes, you are correct. I wanted to give a link to all of the information.
> 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).
I'd very much like to get this implemented for 2.4.
Right now there is no way to load drivers on demand, nor is there any
cohesive way of determing which configuration and alternate settings
should be used.
This nicely cleans it all up without adding more bloat into the kernel.
> 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 ... :-)
Well, do they need them? I could care less if they really get passed,
but it looked like you were going in the wrong direction.
I was just trying to repoint your though back into what's really
important about it.
JE
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
