lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4AC4EEB2.8090904@natemccallum.com>
Date:	Thu, 01 Oct 2009 14:02:26 -0400
From:	Nathaniel McCallum <nathaniel@...emccallum.com>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
CC:	linux-kernel@...r.kernel.org, greg@...ah.com
Subject: Re: Exposing device ids and driver names

On 10/01/2009 01:47 PM, Stefan Richter wrote:
> Nathaniel McCallum wrote:
>> Please CC me on any responses as I'm not subscribed to lkml.
>>
>> I have the aim at creating two tools helpful to linux.  The first tool
>> is a driver regression test of sorts.  I want to be able to create
>> essentially a time line of hardware support as they appear in distros.
>> The second tool, related to the first, is a program which runs on
>> Windows and scans for a user's hardware and tells them which distro will
>> best support their hardware.  I already have a working prototype of
>> these two tools.  It currently uses the data exported by modinfo.  This
>> however does not provide transparency for drivers compiled into the kernel.
>
> Hardware support also depends on userland:  Udev rules, libraries,
> application programs.
>
> Even if you ignore that for now and only look at the kernel part of
> hardware support:  Beyond "doesn't have a matching driver" and "does
> have", there is a large and impossible to track grey area of "has a
> poorly working driver" and "has a perfectly working driver".

Yes, I'm aware of this and will account for it as best as I am able. 
There is still tremendous value in identifying (with real data):
1. differences between distros and upstream
2. the flow of driver support between distros and upstream
3. statistically common devices that have no driver

Further, for the most common device classes (video cards, networking, 
wireless, etc) it is fairly easy to get a good reading.  For instance, 
the difference between "no graphics at all" and "some graphics" is 
infinitely larger than "some graphics" and "great 3D acceleration."  I'm 
not aware of any video cards which have drivers that claim to support 
them that can't at least modeset.

To summarize, you are correct that we cannot predict 100% of user 
experience.  But 70% is a huge improvement over 0%.

Nathaniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ