Re: Hardware compatibility test: draft proposal
Wouter Verhelst wrote:
On Fri, Aug 22, 2008 at 12:55:34PM +0200, Giacomo Catenazzi wrote:
Wouter Verhelst wrote:
Hi,
As I mentioned in my blog[1], I kindof like the suggestion that Bdale
Yes, I find the talk very interesting.
So, after more than twelve hours of boredom on an airplane and half a
night of not-being-able-to-sleep-due-to-jetlag, which is certainly
enough to think about this problem, I came up with the following things
such a system could need:
/me too
- It should support a notion of what I'll call 'profiles'. A 'server'
profile should check for different things than a 'desktop' or 'laptop'
profile; e.g., it's usually okay if a server doesn't have graphical
support or wireless drivers, while the same isn't true for a laptop.
No. I don't think we should provide profiles.
The check should be:
"complete": test all hardware that it is installed on system.
If the system doesn't have the video-card or the wifi just it doesn't
test it, but it write a notice.
That will create ambiguity, which I think we should avoid at all cost.
If you tell a user of this test that "it seems to work, but you should
check this and this and this output to make sure we didn't miss
anything", then such a test is worthless; hardware vendors *will* miss
this kind of thing.
I really think there are no such cases. Eventually we found
unknown hardware, but I really think that on modern hardware
we will not be undetected hardware (but on very new bus,
in which case the hardware vendor care much more).
Listening the available hardware is pretty trivial (see i.e. my
AutoKernConf).
I'm afraid I'm not familiar with this piece of software; and as I'm
offline right now, I can't look it up, either.
However, I don't think checking by listing the hardware is the best way
to go, in any regard. A script that checks for all hardware available in
a system can't know about each and every piece of hardware out there;
especially not if new interfaces are made that the script doesn't yet
know about. Giving a piece of hardware a perfect score because our
script failed to notice there's some unsupported wireless interface
connected is not the way to go.
I meant the kdetect script, which list the hardware attached to
various buses.
You are right, the other program try to give a name and a kernel
driver to hardware, which is impossible to do completely.
But you can list the hardware of pretty all buses, which
usually some information about the type.
My script collect work of kernel and other programs.
Additionally "dmidecode" collects a lot more information
about memory, cache, motherboard, etc, and
there is already some program to find sensors
(my script find only the sensor found by the kernel,
the other program is kernel-indipendent).
Now there is also a fan-control script that
check the fan (but maybe using dmidecode or i2c)
I really think we can detect nearly all hardware.
The hardware that could be missed, it is the hardware that
probably the vendor will forget (sensor, fan and other
small and probably fast changing piece of hardware).
Additionally a component test should be furnished, for component
hardware vendor. (e.g. a network card vendor would test
only the network card, not the whole system).
I'm not sure that's very useful. A network card vendor has two options:
either they design a card based on an existing chipset that has drivers
already in the kernel (in which case it will probably just work, unless
they use previously-unknown PCI IDs, in which case it won't), or they
will create a totally new chipset for their network card, in which case
it won't work. A vendor is usually aware of this fact, and giving them a
"test" for something they already know about isn't very useful.
If you disagree, of course don't let me stand in your way. Just don't
expect me to work on it ;-)
Maybe we should discuss with Bdale. I'm not sure about your reasoning,
for two reasons:
- hardware vendor will do a new version, but it still use old driver
(USB and PCI have an additional version value, along the ID)
- a lot of drivers support multiple hardware: if you read the kernel,
you will see driver with a long list of ID.
Some drivers (IDE,...) check only the class of hardware
so I think there could be error on hardware that we could detect.
But my point was about one of my mouse: it work good on windoze,
but not on my systems ("automatic backspace after click").
For this reason I would like to have component tests.
Anyway I think it is more an interface problem, not a really
problem, and it is not the primary goal.
-- to late --
I'll read and answer the bottom part of the email tomorrow ;-)
ciao
cate
I'm not so sure that the test should be packages.
The system is too different on early boot from a Debian system.
In what way? Note that a Debian Live system *is* a normal Debian system;
you build a Debian Live image by giving the debian-live script a bunch
of packages; it then installs them into a chroot, changes a few things
so that the system will actually boot from CD-ROM, and then create an
ISO image from it.
How is that "too different" from a Debian system? Or are you talking
about something else?
I think it is a lot simpler to do a separate project, using
building infrastructure as d-i or debian-live.
IMHO the target CD should be very easy to create and it
should be complete. (but maybe allowing additional external
kernel and modules).
That's my goal, too.
The "modular" thing should be put mainly on the testing
development side.
Yeah, I'm not suggesting we provide vendors with a bunch of packages;
the packages thing is a way for us to make it easier to actually develop
this without having one maintainer who has to write/accept/maintain
*all* the tests in the system. But hey, this is debian-devel, not
debian-announce ;-)
- Vendors who pass this test on a particular bit of hardware are allowed
to advertise that fact; it might be nice to have provide them with a
logo that they may use for this purpose.
This should be discussed after we have comprehensive tests,
Sure.
and probably to LI. I don't want to see packages with logo of 10
distributions.
To me, it's not about seeing a logo on a package. It's about seeing
another vendor besides HP make a commitment that "Yes, Debian will be
supported. We won't run away scared to the hills if you say that you're
running Debian." Because that's what most vendors will do currently.
I think you'll also find aving a generic "Linux" hardware compatibility
test isn't very useful; if we provide hardware vendors with such a
thing, they'll go "I ran that test, and it said 'pass'; but my
shiny-new-network-card-chipset-that's-supported-in-the-latest-development-kernel-only
isn't supported in Debian? That's probably a bug in Debian, then".
And it doesn't even have to be "too new" stuff; it may also be that some
particular bit of hardware is supported by some free out-of-tree driver
which is supported by some distributions, but not necessarily by all of
them. Would you test for that in a generic "Linux" compatibility test?
If you don't, you'll fail on an amount of hardware that works perfectly
well in most distributions; and if you do, you'll succeed on hardware
that won't be supported by a number of distributions, possibly the one
the hardware vendor cares about most (because, say, they use it
themselves for their webservers).
No, I think we *do* need a Debian-specific test.
Marketing people could choose to include on packages only few
distribution, which could be negative for other distribution (and
maybe for debian).
I think you'll find that they do that anyway. The more logos, the
merrier, because it sells good. Never mind that you can make those up, of
course.
Reply to: