lkml.org 
[lkml]   [2003]   [Aug]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: C99 Initialisers
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:47    [W:0.125 / U:3.832 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site