mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: lkml <linux-kernel@vger.kernel.org>, Greg KH <greg@kroah.com>
Subject: Re: Hardware Inventory [was: Re: ISA slot detection on PCI systems?]
Date: Mon, 07 Jan 2002 12:13:21 -0800	[thread overview]
Message-ID: <000701c197b7$c21a5700$6800000a@brownell.org> (raw)

Greg, you wrote:

> > And the /sbin/hotplug program knows about _all_ devices that the
> > currently compiled kernel can handle due to the MODULE_DEVICE_TABLE
> > tags in the drivers.
>
> Along these lines, I am very disappointed in looking at the
> autoconfigure stuff in CML2.  It should be taking all of the device and
> driver matching information from the kernel itself, as it is already
> specified there.

I sent related comments to Eric last April:

> > One thing I noticed is that there's important information in the build
> > system that's discarded after a build.  That "metadata" can be handy
> > for lots of purposes.   Hotplugging drivers (including configuring them
> > after they're loaded) is one application.

So far as I can tell, nobody's trying to do much with that metadata.
Maybe in part because it's not easily accessible.  But that's exactly
something I'd expect the 2.5 build/configure system to start fixing.

MODULE_DEVICE_TABLE support is actually a good example.

Its format isn't quite tool-friendly, but the real issue is that such data
is only available _after_ a build!  In this case it's needed before
config.  And if viewed as metadata, it's also incomplete:

    - Drivers omitted from the current config are not listed.
    - It's discarded for statically linked drivers (affects hotplug)
    - Doesn't say what CONFIG_ flag corresponds to each driver
    - No driver-to-docs linkage
    - ...

For anyone configuring a kernel who's not already an expert (we're
not talking Aunt Tillie ... most technical folk shouldn't be kernel experts),
that information can be important.

(One example:  driver docs.  I did some XSLT hacks a while
back, available off the linux-hotplug "links" page.  They do a better
job for USB than PCI.  Sample output (very old now :) is at

http://linux-hotplug.sourceforge.net/kernel/kernel.html

The early text is boilerplate explanation, but sections 3 and 4 are
generated automagically from modutils output, as driven by the
MODULE_DEVICE_TABLE info.  I think such info should be far
more accessible than it is.)


> Eric, if you are going to keep your "2000+" configuration probes up to
> date by hand, good luck.  Look at all of the new USB drivers that have
> been added in just the 2.5.2-pre series alone.  That's a lot of data to
> keep track of.
>
> The rest of us have decided to rely on automatic tools for this process :)

Absolutely!  What I think is needed in this case is automatic tools to
generate such stuff from kernel sources, without needing to build the
whole thing.  Run once before "configure me a kernel", to build the
driver database.

And, maybe more in the "I have a dream ..." category, take this rare
opportunity (2.5 cycle reworking build/config) to take a look at the
forest rather than the trees.  Useful tools and documents will come
from making this metadata more generally accessible.

- Dave



             reply	other threads:[~2002-01-07 20:15 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-07 20:13 David Brownell [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-01-04 11:32 Martin Knoblauch
2002-01-04 22:17 ` Dave Jones
2002-01-05 17:00   ` Paul Jakma
2002-01-05 17:14     ` Dave Jones
2002-01-07 18:05       ` Patrick Mochel
2002-01-07 18:11         ` Dave Jones
2002-01-07 18:50           ` Greg KH
2002-01-07 18:58             ` Greg KH
2002-01-07 18:58               ` Eric S. Raymond
2002-01-07 18:58             ` Dave Jones
2002-01-07 19:06               ` Greg KH
2002-01-07 19:19                 ` Dave Jones
2002-01-07 19:45                   ` Alexander Viro
2002-01-08 14:00                   ` Alan Cox
2002-01-08 14:00                     ` Erik Andersen
2002-01-07 19:19             ` Patrick Mochel
2002-01-07 19:29               ` Greg KH
2002-01-07 20:36                 ` David Brownell
2002-01-07 22:03                   ` Greg KH
2002-01-07 22:28                     ` David Brownell
2002-01-07 23:59                       ` Greg KH
2002-01-08  8:36                       ` Kevin Easton
2002-01-11 21:52                         ` David Brownell
2002-01-07 23:25       ` Kai Germaschewski
2002-01-07 17:55     ` Patrick Mochel
2002-01-07 19:04     ` Richard Gooch
2002-01-07 19:26       ` Dave Jones
2002-01-07 19:41         ` Alexander Viro
2002-01-07 19:58         ` Paul Jakma
2002-01-07 19:33       ` Patrick Mochel
2002-01-07 20:16         ` Andrew Morton

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='000701c197b7$c21a5700$6800000a@brownell.org' \
    --to=david-b@pacbell.net \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®