Re: [PATCH] spi: reorganize drivers

[Arnd Bergmann]

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
--
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/