lkml.org 
[lkml]   [2002]   [Nov]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: A Kernel Configuration Tale of Woe
On Wed, Nov 27, 2002 at 12:52:45PM -0500, Dennis Grant wrote:
> >> Agreed - so then the association between "board"
> >> and "chipset" must be capable of being multi-valued,
> >> and when there is a mult-valued match there must be
> >> some means of further interrogating the user (or user agent)
> >> for more information.
> > Much simpler to just include "modular everything" and let
> > user space sort it out. Guess why every vendor takes this path
> So I think there's still a need for the hardware->kernel version+config database.

The kernel source pretty close resembles what the kernel supports
(except the broken drivers). Make the source your database. Propose
source code formatting rules, and let the userspace parse it (assuming
the proposal find the way into source). Make the hardware descriptions
readable in the object code, so the userspace can pick up new modules
and activate them if a new pci-id is seen. Etc...

It's already of such use for some of us, who are about to get a new
hardware and trying to figure out if it can be useful:

egrep -rn 'vendor|cardname' .

-alex

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

\
 
 \ /
  Last update: 2005-03-22 13:31    [W:0.030 / U:1.472 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site