Messages in this thread | | | Date | Mon, 6 Jun 2011 14:35:07 +0200 | Subject | Re: [PATCH] spi: reorganize drivers | From | Geert Uytterhoeven <> |
| |
On Mon, Jun 6, 2011 at 14:16, Jean Delvare <khali@linux-fr.org> wrote: > On Mon, 6 Jun 2011 13:21:07 +0200, Arnd Bergmann wrote: >> 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. > > Err, what about I2C and SPI? Aren't drivers/i2c/busses and drivers/spi > full of "device drivers"? Or are these what you call "bus-specific > drivers"? Maybe we need to define all the terms before the discussion > continues further.
Arnd did write:
| It does include i2c and spi, which stick out by being a lot larger than most others.
>> (...) >> 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. > > This gets interesting. Would you suggest for example that i2c-core.c > goes to bus/i2c, and drivers/i2c/busses becomes drivers/i2c? And that > CONFIG_I2C is somewhere in menuconfig, and the hardware driver > selection for drivers/i2c is in a totally different place? > > While I am surprised, I am not necessarily objecting. But it seems that > you should better define what your actual plan is, before asking us if > we agree with it.
Most other drivers are located based use case, i.e. from the user's point of view, e.g. drivers/net/ and drivers/video.
Gr{oetje,eeting}s,
Geert
-- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |