Re: 2.5.47bk2 + current modutils == broken hotplug

Jeff Garzik (jgarzik@pobox.com)
Wed, 13 Nov 2002 15:59:56 -0500


David Brownell wrote:

> Greg KH wrote:
>
> > On Wed, Nov 13, 2002 at 12:11:01PM -0800, David Brownell wrote:
> >
> >> The module-init-tools-0.6.tar.gz utilities (or something
> >> related -- kbuild changes?) break hotplug since they no
> >> longer produce the /lib/modules/$(uname -r)/modules.*map
> >> files as output ... so the hotplug agents don't have the
> >> pre-built database mapping device info to drivers.
> >
> >
> >
> > Last I heard, Rusty's still working on this. He's also going to be
> > changing the format so we don't expose kernel structures to userspace,
> > which would be a good thing.
>
>
> So long as the _information_ in those structures stays available, good.

Agreed.

> And it'd be handy if the text format for that information didn't change;
> how it's stored in object modules doesn't matter.

Correction -- the tools that read the text format are buggy if they do
not transparently support changes to the text format.
(Corollary: the text format is buggy if it does not support a method of
noticing format changes)

I am planning on adding PCI revision id to the information exported via
MODULE_DEVICE_TABLE(pci,...). Tools which correctly read the
first-line-format-definition will continue to function as before,
regardless of additional fields I want to add. Tools which make silly
assumptions will have those assumptions come back to bite them ;-)

(tangent warning!)
Another long term idea I would eventually like to realize is the removal
of device ids from the C source code. I don't care where they go --
drivers/net/pci_ids [per directory ids?], drivers/net/3c59x.meta,
whereever. Anywhere but the C source code. It's quite silly to require
a driver rebuild just to add a single PCI id, and further, embedding
metadata in C source is rarely a good idea in the long term. [reference
some of Linus's counter-arguments when it was mentioned that Donald
Becker's method of including Config.{in,help} data in C source might be
useful]

Jeff

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