On Fri, 2008-08-22 at 11:05 +0100, Chris Lamb wrote: > Wouter Verhelst wrote: > > > As I mentioned in my blog[1], I kindof like the suggestion that Bdale > > came up with during Debconf that we write a hardware compatibility test > > of sorts that hardware vendors could run on their own hardware > > I think this is a great idea, and I generally agree with your decisions and > assumptions. > > > - Scripts should not just test for availability of hardware. Instead, > > they should test the actual functionality; e.g., tests for a network > > interface should be done by trying to DHCP off that interface, X.org > > drivers should try to start X and ask for input using a graphical > > dialog, and tests for a hard disk should be done by trying to read > > some data from the disk. > > I think this the most important paragraph of all. > > What I think is missing is some really concrete info on just how various > hardware items would be tested. For example, in the case of ethernet > adaptors, I feel that simply successfully DHCP-ing on an interface is really > not an acceptable test. <snip> At a bare minimum the HCT should try to run the driver's offline self-test (ethtool -t $dev offline). For a more comprehensive (and generic) test we would really want to use two machines, though an external loopback cable may suffice. My employer outsources much of the generic network test development to Oktet Labs. Their network test environment <http://www.oktetlabs.ru/test_env.rhtml> is distributed under GPL though it is not freely downloadable. It might be worth asking them to provide it to Debian. Ben. -- Ben Hutchings It is easier to write an incorrect program than to understand a correct one.
Attachment:
signature.asc
Description: This is a digitally signed message part