All of lore.kernel.org
 help / color / mirror / Atom feed
From: dirk@steuwer.de
To: <rdunlap@xenotime.net>
To: <wli@holomorphy.com>
To: <riel@redhat.com>
To: <linux-kernel@vger.kernel.org>
To: <arjan@infradead.org>
To: <diegocg@gmail.com>
Subject: AW: Re: Linux in a binary world... a doomsday scenario
Date: Thu, 08 Dec 2005 16:49:46 +0100	[thread overview]
Message-ID: <6798653.142371134056986823.JavaMail.servlet@kundenserver> (raw)

>
>El Thu, 8 Dec 2005 13:23:11 +0000 (UTC),
>Dirk Steuwer <dirk@steuwer.de> 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

             reply	other threads:[~2005-12-08 15:50 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-08 15:49 dirk [this message]
2005-12-08 16:14 ` Linux in a binary world... a doomsday scenario Diego Calleja
2005-12-08 20:28   ` Horst von Brand
2005-12-08 19:38 ` AW: " Lee Revell
     [not found]   ` <161717d50512081213oab71f63ncd9ecb3d721c83fc@mail.gmail.com>
2005-12-08 20:26     ` Lee Revell
2005-12-08 16:35 dirk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6798653.142371134056986823.JavaMail.servlet@kundenserver \
    --to=dirk@steuwer.de \
    --cc=rdunlap@xenotime.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.