Linus Torvalds wrote:> In the end, we just have to balance the "everything in one place so that> it is easy to find" with "uhhuh, that 'ls' output is just too confusing,> and I can't seem to find my driver any more".

I think there is value in having everything under drivers/... Withdrivers/<bus>, we can already cover most of the architecture-specificbits. Maybe just a few more bus types are needed - e.g. many "system ona chip" design families have some tiny little bus and all the devicesthere are rather unique and may have a lot of shared resources.

On the other hand, drivers/<function> makes sense for generic drivers(e.g. drivers/char/mem.c) and those supporting many buses. So perhaps achipset that is used on many platforms should be split into the businterfaces in drivers/<bus> and the portable part in drivers/<fn> ?

This would probably require include/drivers or such, to avoidcluttering include/linux with tons of additional "internal" files.Also, drivers/<bus> should probably be reserved for drivers for the busitself, with the device drivers in drivers/<bus>/<fn>, or drivers/pciwould look a little nasty ;-)

Furthermore, if a driver starts is existence in drivers/<bus>, and thenturns out to be useful on other buses too, it would have to be split.This would be a departure from the current implicit assumption that youpick "The Right Place" once and forever. It would also make it harderto port somebody else's driver to a second bus. But it would limit codereplication.