AW: Re: Linux in a binary world... a doomsday scenario

From: dirk
Date: Thu Dec 08 2005 - 10:49:52 EST


>
>El Thu, 8 Dec 2005 13:23:11 +0000 (UTC),
>Dirk Steuwer <dirk@xxxxxxxxxx> escribió:
>
>
>> For a hardwaredatabase i like to see a structure. Kernel developers are
>> required to enter the support into the database, when submitting the
>driver.
>> Ongoing status will be logged there as well. Status and devices can only be
>
>> entered by kernel developers.
>
>[Please don't remove the CC list]
>
>This sounds like the typical nightmare that never is 100% accurate and
>needs lots of mainteinance (developers not updating the wiki, etc) as
>Lee Revell pointed out.
>
>IMO the one way of creating such database is automating it. If you
>could get a list of the device IDs supported by drivers you
>could (?) use the pciid/usbid/whatever list to build a user-readable
>database of the devices supported by the linux tree. Maybe it won't
>100% perfect but...

Yes, i can see the problem.
How about interconnecting it with the bugtracker?
If there is a bug, and if it is related to some hardware, it is logged in the database as broken for that kernel version. If the bug is fixed, support status is ok again.
All that needs to be done is entering the device once into the database, status is broken by default, and take it from there?
Then it gets some goals (similar to bugs) assigned if it is a complex device. i.e. for a graphic device:
* 2d graphic support
* 3d graphic support
* framebuffer
* vesa

one can close goals similarly to bugs, and if a second tester find something broken, it gets filed as a bug.
As i see it the system has to be simple to use and if used, provide an advantage to kernel developers. This makes sure it will get used and could provide an instant status about linux hardware support.

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