[Fwd: Re: 2.0.4 BUG in build]

[Auke Kok]

reading food:

fruitfull discussion with Jeff Licquia, we seriously need to start 
working together with these people. Being who we are we could get some 
good publicity out of it too!

please read and share comments!

sofar

-------- Original Message --------
Subject: Re: 2.0.4 BUG in build
Date: Thu, 13 May 2004 11:00:44 -0500
From: Jeff Licquia <licquia at progeny.com>
To: Auke Kok <sofar at lunar-linux.org>
CC: discover-workers at lists.progeny.com
References: <40A087A8.4030406 at thermal.esa.int> 
<40A08932.1080504 at lunar-linux.org>	<40A0953E.8090903 at lunar-linux.org> 
<40A10010.6090804 at progeny.com>  <40A148B2.2010706 at lunar-linux.org> 
<1084383845.5947.16.camel at laptop1> <40A33873.6080602 at lunar-linux.org>

On Thu, 2004-05-13 at 03:57, Auke Kok wrote:
> Jeff Licquia wrote:
> >Just send us lspci and lspci -n output, and we'll take it from there.

> for the box with the 'e1000' driver:
> 
> 03:0e.0 Ethernet controller: Intel Corp. 82545EM Gigabit Ethernet 
> Controller (Copper) (rev 01)
> 03:0e.0 Class 0200: 8086:100f (rev 01)

Great, thanks.

> >I believe the current state of the database loads ALSA modules for 2.6.x
> >kernels or later, and OSS for 2.4.x and earlier.  Are you seeing this on
> >2.6?
> 
> 2.4!

Yup, it's working as designed, then.

> >We don't do ALSA for 2.4.x because we haven't figured out a good way to
> >determine the user's preference.  If you have any good ideas along those
> >lines, we're all ears.
> 
> well I suspect (haven't digged into it) that your database therefore 
> also stores the alsa-modules as it needs to work on 2.6 as well (or do 
> you have a separate database for that?)
> 
> That probably brings the following dilemma up that you need to solve:
> 
>   *  how do you handle choosing between driver alternatives?

Discover's database can store version information for any data, and can
automatically use that information when detecting hardware.  In this
case, we pass the kernel version to discover, and it returns the right
driver for the particular version of the kernel.

> even in the kernel itself there are alternatives... and how about those 
> ncr8xxx scsi cards having 12 drivers?

I'd imagine there's a single driver that's recommended for various
specific cards (with different PCI IDs).  In the rare case that there
truly is no preferred alternative, we just pick one.  (Example: e100 vs.
eepro100)

> anyway I'd really like to have alsa drivers on 2.4 boxes. OSS is old 
> ;^). think about it

Here's an idea:

Suppose 2.4 sound card information were provided in two separate files
outside of pci-device.xml: an OSS-based file and an ALSA-based file.  By
default, OSS would be used (since it's in the kernel by default, and is
thus more likely to be present), but by changing discover.conf, you
could switch to use ALSA.

As a distro vendor, you'd just ship discover.conf with ALSA turned on,
since you can guarantee to your users that ALSA drivers will be
present.  Similarly, power users wouldn't mind changing discover.conf on
their own, and could generally take care of themselves.  But for the
default case, where a vendor/user just grabs discover and the kernel and
doesn't do too much to either, everything would work generally as
expected.

> >>last point but not least... perhaps it would be nice to have some form 
> >>of reporting missing drivers, devices with a script (a la gccbug!) that 
> >>send back lspci output (possibly with user comments?!). Is there some 
> >>way of doing this (you would want to check only unknown items)? This 
> >>could greatly improve the growth and accuracy of the DB
> >>
> >>ultimately you would want to go to a live web-interface IMO... submit && 
> >>forget ;^)
> >
> >Yup.  Something like this is on our list.
> 
> being a distro's project leader I might help out in this case. anything 
> we (I) can do for you? I have 20 excellent scripters waiting for a good 
> challenge... ideas? Are you looking to build a 'community' or is this 
> out of scope? (or are you just happy living in debian circles ;^))

Absolutely yes to the community thing.  We would love to see everyone
adopt discover and send us patches, utilities, etc.

If you're inclined to take on the tool for reporting hardware, we'd be
very interested.  Some thoughts:

  - If at all possible, it would be nice to use discover to remove lspci
information for the devices we already know about - just like your
report on the e1000 info.  The tool could possibly show all the hardware
on the system and let the user pick which one to report.

  - User input is definitely vital.

  - Besides free-form comments, information about the make and model for
the hardware, and what kind of hardware it is, might be nice for
cutting-edge hardware that isn't known about by the kernel.

  - You know that discover has a C API, right?  We also have the start of
SWIG bindings in our Subversion repository; just check out
svn://svn.progeny.com/discover/discover-swig/trunk.  I have been able to
generate Python bindings that work.  If you need something more from
them, let me know, or alternatively patches are always appreciated. :-)

Don't feel any obligation, but we'd be thrilled to accept any effort you
put forward on discover's behalf.