On Wed, 13 Jun 2007, Grant Likely wrote:

I think we're crossing wires here.  In this particular case, I think
the hub support code is sufficiently small that it doesn't need to be
split off into a separate file.  (It's only 180 lines)  I'm not
suggesting that the hub support stuff be moved to a .h file.

If the code was larger, I argue that c67x00-hub.c should be compiled
separately from c67x00-hcd.c and that 'c67x00-hub.c' be added to
'c67x00-$(CONFIG_USB_C67X00_HCD)' in the Makefile.

Heh, 'polluted' is too loaded a term, and it suggests something I
didn't mean.  When the driver is built into the kernel, there are a
number of c67x00_* symbols which are exported.  These symbols are not
used anywhere other than in the c67x00 driver code.  However, this is
necessary because the overall driver splits the various subsystems
into separate .c files which are linked together.  This approach is
well supported by convention in the kernel, and all the non-static
symbols use the c67x00_ prefix to avoid collisions.

For example, see ib_core-y in drivers/infiniband/core/Makefile and
pcieportdrv-y in drivers/pci/pcie/Makefile.

Since the driver already makes use of this approach, I don't think it
makes sense to use a difference approach for the root hub support
code.  (Again, I'm specifically talking about the c67x00 driver here;
I've not looked at the *hci drivers in detail).

But you did say earlier that the way other drivers were written was a
bad idea...

In any case I agree that the root-hub code in c67x00 should be written
to match the style used by the rest of the driver.

Of course, when it is built as a module, none of those symbols show up
because they are not exported.

True.  And true as well of the other drivers which #include *.c files.

Alan Stern