Re: [GIT PATCH] char/misc patches for 3.10-rc1

[Nicolas Pitre]

On Mon, 29 Apr 2013, Linus Torvalds wrote:

> The "explanations" for why it should be in drivers/ is this mindless drivel:
> 
> On Tue, Feb 22 2011, Daniel Walker wrote:
> > On Tue, 2011-02-22 at 12:47 -0800, Dima Zavin wrote:
> >
> >> What is the problem leaving it under arch/arm/mach-msm?
> >
> > Because it's a driver.
> 
> Seriously. That's the *ONLY* explanation given.

This certainly sucks as an answer.

> WTF? That's a singularly *bad* reason for moving things to "drivers".

Agreed.

> And I'm calling the ARM people out on this idiocy. Arnd and Nico -
> stop encouraging this kind of crap. Move things to drivers only once
> there is actual reason for it. If it's some proprierary single-SoC
> thing, it can damn well stay away from other people. And it definitely
> shouldn't mess up autocomplete in some core location.

All I wish to add to what Arnd already stated is this:

We ought to gather drivers together according to their _purpose_.  
Especially if they provide some generic functionality via a common API 
to be used by the rest of the kernel.  In some cases that API just begs 
to be created and commonalities factored out from individual drivers, 
which also warrants a move to drivers/.

Of course the cpufreq drivers, or even the cpuidle drivers, are awfully 
platform specific, or even proprietary single-SoC in many cases.  But 
the interface they register into and the services they provide are 
common, and it is far easier for someone maintaining the cpuidle 
infrastructure to improve the interface and avoid conflicts by having 
all the related drivers at the same place. .  It even helps next driver 
author look for better examples than only the last SoC they worked with.

However this is a design goal, not a hard rule.  If a piece of code has 
no interface commonality with anything else then it is indeed not worth 
the hassle.


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