Messages in this thread | | | From | Arnd Bergmann <> | Subject | Re: [PATCH] spi: reorganize drivers | Date | Mon, 6 Jun 2011 13:21:07 +0200 |
| |
On Monday 06 June 2011, James Bottomley wrote: > I'd say it only makes sense if we do it for all busses ... so USB and > PCI would have to move too. Logically, the bus code should move and we > should be left with the drivers in both of those directories. I'd also > say that we don't have to deepen the tree: /bus would be fine. That > way, /drivers/<bus> would be only for <bus> specific drivers, with non > bus specific drivers we just group them by function as now.
A top-level /bus would work for me, and I guess would also address Russell's concern. Regarding bus-specific drivers, we're gradually moving those out of the bus specific directories anyway, basically the only bus directory that really has device driver in it is USB at this point. It makes some sense to have a bus-specific low-level user space interface driver like sg or uio in the bus directory, but everything else should really belong into some other subsystem.
> What about the half busses (like SCSI)?
I think SCSI is a really special case, not just because of its size of more than twice the code than everything else I would suggest to move, but also because it contains mostly host drivers but very few device drivers (sd, sr, osst, st, and sg). In that sense it's more a class of devices than a bus and fits in the same category as mmc and ata than a bus like pci or i2c that have a multitude of device drivers.
> Finally, is there any real point (other than we can do it)? what is > actually helped by having the bus code obviously separated from the > driver code (assuming we sort out what is bus and what is driver)?
Mostly I think the drivers/ subdirectory is getting a bit cluttered with stuff that doesn't really fit together, and bus drivers are typically directories with less than five files in them, apart from the few exceptions that already came up.
This is about to get worse as we introduce new subsystems (e.g. iommu, irq, clocksource, eeprom, nvram, ...) into which we are moving code from arch/arm, drivers/char and drivers/misc. Having buses and drivers in a separate hierarchy would make the drivers directory and the respective menuconfig list more clearly structured IMHO.
Arnd
| |