> > > > 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 ?
Many different ways. There are answers from distribution
providers as well as driver writers and end users, and they
don't all agree. I've certainly berated driver writers who
have labeled some devices as "working" without having done
real testing to verify it. But then, what are they to do
when they don't have that particular configuration?
Thorough testing is required, but one must also accept that
most testing isn't thorough and most results aren't fed back
to the folk who need to see them.
> 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...
"Driver package" doesn't inherently mean just driver source
code; there's build instructions (other kernel patches) and
likely other information including installation stuff that
can easily update a driver database.
> 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.
Some comments to add there. First, _most_ changes will be for
supporting new devices. Using old driver bindings will tend
to cause minor "it doesn't work" glitches, with easy workarounds
(load driver by hand) or fixes (update those bindings) that are
no worse than for other such problems in Linux.
Second, using new binding databases with old kernels will tend to
change nothing much -- the kernel won't accept the binding. (We
can eventually change that if we want, letting user mode data take
over the "master driver database" role if we want.)
And third, having a standard place to get the most appropriate
driver database makes it easy to avoid the problems as they happen.
Just get the latest distribution.
At this point I'm most concerned with having a solution for the
driver loading problem that can evolve. I think we've got a basic
framework that works, and it's our job to evolve it to address the
more important of the issues we run across ... making sure that we
know the inputs that a "what drivers do I load" policy agent needs
to make the decision, and that its driver database has enough data.
If we change the driver database in any way, fine with me, so long
as it keeps working and we don't lose maintainability!
- Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
