David Brownell wrote:
>
> > > > > Eventually, it'd make
> > > > > more sense not to compile specific device IDs into drivers.
> > > >
> > > > Why?
> > >
> > > Because the original driver has no strong reason to know, or care,
> > > about every device that's going to be compatible enough to use it.
> >
> > It is at least usefull to be able to tell the user of a driver (a human or a
> > daemon) which devices it is *known* to work with.
>
> Absolutely; but what levels of "work with" are OK in this case?
Good question. How does one answer it today ?
> Maybe the administrator has a lot more current information than
> the developer.
Then, off course, he should pass it on to the developer ;-)
> > This can be easily provided with a little utility that can add entries to the
> > daemon's database. This is not something that is needed for general use, so
> > this can be a 'debug' feature.
>
> I'm not sure I can see that. Someone ships a new device, and to install
> it there need to be some database additions. I don't want to see this
> become something only linux distributors can possibly do.
Actually, it would be limited to people able to recompile a new kernel
(or at least a module), these are not only distributers ;-).
Anyway, supporting new hardware is not something the average user will
do. If User Doe wants to use the newly supported hardware, they will
have to download a new driver package (unless this is anticipated and an
alternative approach it included, see below). Btw, if i am not mistaken,
this is the situation today...
I have been thinking about a system to load 'patch info' at boot time,
but all I can think of is a file with bindings information, the current
system ;-).
This brings me (in my head anyway ;) to another problem I have with the
driver bindings file. This information is rather volatile, it can change
every kernel version. The files will easily get out of date and cause a
lot of problems. The system with the modules doesn't, but the patch
file thingie would. On the other hand, the patch file info has a high
chance of becoming redundant with a kernel unpgrade.
A file with bindings per kernel version, per modules version (to allow
module updates) and per hardware version, I think this can easily get
out of hand.
> > Yeah, I realize what I suggest would impact about every subsystem and every
> > module in the kernel. It is not a good idea to do this for 2.4 :-)
> > I was planning a bit more research in what is available/feasable/nescessary
> > and then write up a serious proposal. Consider this a brainstorm session :-)
>
> We all need those regularly!
Yeah, keeps the brain active ;-)
Thank you for participating!
J.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
