Re: C99 Initialisers

[Jeff Garzik]

Greg KH wrote:
> On Wed, Aug 13, 2003 at 01:47:54PM -0400, Jeff Garzik wrote:
>
> > Greg KH wrote:
> >
> > > # add PCI_DEVICE() macro to make pci_device_id tables easier to read.
> > >
> > > diff -Nru a/drivers/net/tg3.c b/drivers/net/tg3.c
> > > --- a/drivers/net/tg3.c	Wed Aug 13 10:29:08 2003
> > > +++ b/drivers/net/tg3.c	Wed Aug 13 10:29:08 2003
> >
> >
> > This patch is ok with me.
> >
> > And I agree with David that, in generic, C99 initializers is the way to 
> > go.  However, the higher level point remains:
> >
> > PCI IDs, and data like them, are fundamentally not C code.
>
>
> But the kernel, using C code, uses those ids to match drivers to
> devices.  So we have to create C structures out of those ids some how.
>
> The idea was that since the kernel already keeps track of these ids, we
> might as well export them to userspace, so that it too can see what the
> kernel support.  That brought forth the modules.*map files and enabled
> the hotplug scripts to automatically load a module based on a device id
> (this is much nicer than other os schemes which force a text file to be
> created for every driver listing these ids.  They are usually created by
> hand, and can get out of sync.)

Oh, no argument about how we got here.  The ids started out in C code 
for good reasons.  Linus always says "do what you need to do, and no 
more" and IMO he's right.  And we did exactly that :)


> I agree that now that more and more tools are using this data, we should
> put it into a form that everyone can easily get at, without having to
> parse module attributes or even the modules.*map files.
>
> Any suggestions that do not involve XML?  :)

Again, my philosophy:  put the data in its most natural form.  In 
CS-speak, domain-specific languages.  So, just figure out what you want 
the data files to look like, and I'll volunteer to write the parser for it.

An overall goal for metadata is to collect it in one place.  I mentioned 
earlier about moving the simple "obj-$(foo) += foo.o" out of Makefiles 
and into Kconfig.  So putting PCI IDs in Kconfig files is one idea. 
Note that Kconfigs can be split up and #include'd, so it can be 
partitioned neatly in a single directory as the maintainer desires.

Another option is a few collections of files:  drivers/net/pci.ids, 
drivers/sound/pci.ids, and these would hold pci ids and driver assocations.

I'm sure the people CC'd here have even better suggestions.

One the PCI ID data format is chosen, automated tools generate the 
required C code so that the kernel source code (and behavior) is 
essentially unchanged.

	Jeff


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