Re: Exposing device ids and driver names

[Nathaniel McCallum]

On 10/01/2009 12:42 PM, Greg KH wrote:
> On Thu, Oct 01, 2009 at 12:40:05PM -0400, 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.
>
> That's going to be interesting, as all distros pretty much use the same
> kernel, it will just depend on who is "newer" at the moment, right?

Mostly yes.  I intend to also trace id diffs against mainline to see if 
distros have picked up patches that are not upstream.

> > 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.
>
> Most distros don't build drivers into the kernel, so you should be fine
> with what you have today, right?  Or have you run into problems with
> this?

I've run into specific problems.  This is obviously the case on 
specialized distros (which I *do* want to measure).  However, even a 
quick diff on configs will show differences on major distros with some 
devices being compiled into the kernel.  It is also often true that ACPI 
devices are built into the kernel.

> Why not just use the baseline kernel as a model for this.  Do a 'make
> allmodconfig' and then extract the data and publish it that way.  No
> kernel changes are needed, and then any distro can be easily matched up
> by this based on what they are using.  That will save you time in
> downloading zillions of distro releases, and provide a nice easy way to
> show what the kernel.org releases support.

Unfortunately, I would not be able to track changes to the kernel in 
this model.  Since this is one of my explicit goals (to make sure that 
distro kernel changes get upstream), I think a non-invasive kernel 
modification would be worth the effort.

Nathaniel

--
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/