Re: multiple drivers, single device (was Re: Announce: Linux-next(Or Andrew's dream :-)))

From: Jeff Garzik
Date: Tue Feb 12 2008 - 13:32:13 EST


Greg KH wrote:
Except that the individual drivers are a lot of the time written by
different people, live in different portions of the tree, and are
combined into different combinations depending on the chipset.

Yes -- the worst case is that people have to work together, and it tweaks people who like to organize source files nicely into directories :)


For i2c devices, I see the scx200_acb, i2c-elektor, i2c-sis5595, and
i2c-sis630 drivers needing this. The last one happens to share the pci
device with a video driver, that doesn't always need to be / want to be
loaded by users just so they can read the temperature of their
processors.

Sure. Reasonable request, and doable within today's APIs.


Oh, the EDAC code also needs this, and I know that no one wants to merge
that stuff into their individual drivers :)

So people have to work together... darn :) most drivers these days are organized nicely into nicely modular units anyway, making it easy to write a "shell" driver that simply registers each sub-driver, and helps arbitrate/provide resources to sub-units.

Consider, for example, a PCI driver that loads, and then fills in platform_data to provide a specific set of resources to a platform driver (a common idiom). You would need to create parented struct devices (parent: pci_dev's device), but everything else should work within

I could even forsee a future where most drivers are written in a generic platform-driver style, and PCI|sbus|embedded-bus|blah are simply bus-specific shells that fill in platform data.

All of this should be nicely possible within the existing usage of struct device, platform drivers, generic DMA API, iomap, etc.

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/