Re: [PATCH] spi: reorganize drivers
On Sunday 05 June 2011, Grant Likely wrote:
rename drivers/spi/{omap2_mcspi.c = spi_omap2_mcspi.c} (100%)
rename drivers/spi/{omap_spi_100k.c = spi_omap_100k.c} (100%)
rename drivers/spi/{omap_uwire.c = spi_omap_uwire.c} (100%)
rename drivers/spi/{orion_spi.c = spi_orion.c} (100%)
rename drivers/spi/{amba-pl022.c = spi_pl022.c} (100%)
rename drivers/spi/{pxa2xx_spi.c = spi_pxa2xx.c} (100%)
rename drivers/spi/{pxa2xx_spi_pci.c = spi_pxa2xx_pci.c} (100%)
rename drivers/spi/{ti-ssp-spi.c = spi_ti_ssp.c} (100%)
rename drivers/spi/{tle62x0.c = spi_tle62x0.c} (100%)
rename drivers/spi/{xilinx_spi.c = spi_xilinx.c} (100%)
I recently looked at the directory structure in drivers/ and found a lot
of bus drivers with very few files, plus a few bus drivers with a lot
of files in them besides directories for non-bus specific subsystems.
I think it would be good to move them into a deeper directory drivers/bus/
if we have support from the maintainers, and it's probably better if we
only have to move the files once to reduce the amount of churn on the
MAINTAINERS file and any out of tree patches.
Specifically, I'd like to do these moves:
drivers/{ = bus}/amba
drivers/{ = bus}/dio
drivers/{ = bus}/eisa
drivers/{ = bus}/firewire
drivers/{ = bus}/i2c
drivers/{ = bus}/mca
drivers/{ = bus}/nubus
drivers/{ = bus}/pcmcia
drivers/{ = bus}/rapidio
drivers/{ = bus}/sbus
drivers/{ = bus}/spi
drivers/{ = bus}/ssb
drivers/{ = bus}/tc
drivers/{ = bus}/uwb
drivers/{ = bus}/virtio
drivers/{ = bus}/vlync
drivers/{ = bus}/w1
drivers/{ = bus}/zorro
This leaves out the two most common buses, USB and PCI, mostly because
the directories contain a lot of stuff that is not really bus code
but actual drivers. It does include i2c and spi, which stick out by
being a lot larger than most others.
Opinions? Move or don't move?
Arnd
___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: [PATCH] spi: reorganize drivers
On Mon, Jun 06, 2011 at 11:00:38AM +0200, Arnd Bergmann wrote: This leaves out the two most common buses, USB and PCI, mostly because the directories contain a lot of stuff that is not really bus code but actual drivers. It does include i2c and spi, which stick out by being a lot larger than most others. Opinions? Move or don't move? I don't see much point in adding an additional level of directories. All that it'll do is add to the shell filename completion workload and wear out our tab keys faster... We'll still have these directories with not a lot under them. ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: [PATCH] spi: reorganize drivers
On Mon, 6 Jun 2011 11:00:38 +0200, Arnd Bergmann wrote:
On Sunday 05 June 2011, Grant Likely wrote:
rename drivers/spi/{omap2_mcspi.c = spi_omap2_mcspi.c} (100%)
rename drivers/spi/{omap_spi_100k.c = spi_omap_100k.c} (100%)
rename drivers/spi/{omap_uwire.c = spi_omap_uwire.c} (100%)
rename drivers/spi/{orion_spi.c = spi_orion.c} (100%)
rename drivers/spi/{amba-pl022.c = spi_pl022.c} (100%)
rename drivers/spi/{pxa2xx_spi.c = spi_pxa2xx.c} (100%)
rename drivers/spi/{pxa2xx_spi_pci.c = spi_pxa2xx_pci.c} (100%)
rename drivers/spi/{ti-ssp-spi.c = spi_ti_ssp.c} (100%)
rename drivers/spi/{tle62x0.c = spi_tle62x0.c} (100%)
rename drivers/spi/{xilinx_spi.c = spi_xilinx.c} (100%)
I recently looked at the directory structure in drivers/ and found a lot
of bus drivers with very few files, plus a few bus drivers with a lot
of files in them besides directories for non-bus specific subsystems.
I think it would be good to move them into a deeper directory drivers/bus/
if we have support from the maintainers, and it's probably better if we
only have to move the files once to reduce the amount of churn on the
MAINTAINERS file and any out of tree patches.
Specifically, I'd like to do these moves:
drivers/{ = bus}/amba
drivers/{ = bus}/dio
drivers/{ = bus}/eisa
drivers/{ = bus}/firewire
drivers/{ = bus}/i2c
drivers/{ = bus}/mca
drivers/{ = bus}/nubus
drivers/{ = bus}/pcmcia
drivers/{ = bus}/rapidio
drivers/{ = bus}/sbus
drivers/{ = bus}/spi
drivers/{ = bus}/ssb
drivers/{ = bus}/tc
drivers/{ = bus}/uwb
drivers/{ = bus}/virtio
drivers/{ = bus}/vlync
drivers/{ = bus}/w1
drivers/{ = bus}/zorro
This leaves out the two most common buses, USB and PCI, mostly because
the directories contain a lot of stuff that is not really bus code
but actual drivers. It does include i2c and spi, which stick out by
being a lot larger than most others.
Opinions? Move or don't move?
No opinion, I just don't care.
--
Jean Delvare
___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: [PATCH] spi: reorganize drivers
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 ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: [PATCH] spi: reorganize drivers
On Monday 06 June 2011, Stefan Richter wrote: On Jun 06 Arnd Bergmann wrote: On Monday 06 June 2011, Jean Delvare wrote: On drivers/firewire/: FireWire drivers are currently spread over drivers/firewire (three link-layer controller drivers + the IEEE 1394 core + two IEEE 1394 application layer drivers), drivers/media/dvb/firewire/ (one 1394 application layer driver), sound/firewire/ (two 1394 application layer drivers, more are planned to be added there). From the Linux driver model POV, 1. the IEEE 1394 core driver implements the firewire bus, 2. the link-layer controller drivers implement pci bus based devices, 3. the IEEE 1394 application layer drivers implement firewire bus based devices. The two of them that are located in drivers/firewire/ expose a SCSI LLD (a transport in SCSI Architecture Model terms, but a host rather than a transport in Linux implementation terms) and a networking interface driver. Number 2 is something one would expect to find in a hypothetical drivers/bus/ directory. But where do the others belong? Would type 1 drivers be kept in drivers/bus/firewire/? I understand your above response to Jean that this is what you have in mind. Correct. firewire-sbp2 could be moved into drivers/scsi/, and firewire-net could be moved into drivers/net/. But what about maintenance? They could still be maintained via linux1394-2.6.git because this worked so far, but then the directory structure might irritate people who don't use scripts/get_maintainer.pl all the time. Well, I could actually picture firewire-net to be maintained via the net development tree, but I do wonder how well firewire-sbp2 maintenance through the scsi tree would work. I guess the real question is whether firewire should be considered a bus like USB or a device class like SCSI, and it's abit of a grey area (SCSI is too). If you declare it to be a bus, I'd suggest moving the sbp2 and network drivers to drivers/scsi and drivers/net. If you like to think of firewire as a closed subsystem instead, it's probably better to leave all of it in drivers/firewire. PS, these are the same questions like with USB, only on a smaller scale. (The usb-storage driver is maintained through the usb tree as well, not the scsi tree. drivers/net/usb/ has got T: git .../gregkh/usb-2.6.git assigned in MAINTAINERS but most of the commits there are actually done by DaveM.) The difference that I see with usb-storage is that this one is really a set of different drivers for all sorts of devices, while the firewire sbp2 driver feels more like a single driver that includes a few special cases. Also, USB is generally perceived as a generic interconnect, while firewire is seen primarily as a way to attach disk drives. The differences are of course gradual. Arnd ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
