Re: [GIT PATCH] char/misc patches for 3.10-rc1
From: Nicolas Pitre
Date: Mon Apr 29 2013 - 16:45:13 EST
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".
> 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
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/