Re: Hardware compatibility test: draft proposal
Joe Smith wrote:
>
> "Giacomo Catenazzi" <cate@debian.org> wrote in message
> [🔎] 48AE9B26.4040704@debian.org">news:[🔎] 48AE9B26.4040704@debian.org...
>> 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.
>> Listening the available hardware is pretty trivial (see i.e. my
>> AutoKernConf).
>
>
> Ok. What does the test do if it notices that a pecie of hardware exists,
> but cannot identify it?
> Should it warn about that?
I think that 100% (but maybe very few exceptions) of the new hardware
can be detected and identify the class of hardware.
Possible problem could arise with some USB gadget, but class list
is frequently updated, and in this case we must warn the user
about unsupported hardware. (the same with firewire, PCI, and some other
buses).
> Perhaps a few of those could be merged into other tests, like a single
> optical drive test, but in some of those cases it would then be
> important that a list of hardware that was found is printed. That way
> the manufacturer can be sure that both optical drives (in a two optical
> drive PC) were found.
I agree, but probably we should ask Bdale about how the manufacturers
will do the test and what we can expect about it.
> If there is any hardware that cannot be tested with only a single test
> script due to major implementation differences between all brands of
> hardware (and no current unified software interface), we would want to
> avoid having a notice printed for each possible manufacture of the
> device.
Hmm. If hardware cannot be fully detected (e.g. in this case: if we
cannot detect what kind of the protocol is used), it is an error, which
should be notified, so to correct the test, the driver or the hardware.
[i.e. the burden of hardware identification should not be left to
our users]. The handle of such cases IMHO should not have a
high priority.
Probably not always it is possible to do such identification
(IIRC recently on kernel and Linus had such problem with
Intel e1000 "variant"), but I think it is rare.
ciao
cate
Reply to: