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