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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 29 Apr 2013 16:45:05 -0400 (EDT)
From:	Nicolas Pitre <nico@...xnic.net>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Greg KH <gregkh@...uxfoundation.org>,
	David Brown <davidb@...eaurora.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PATCH] char/misc patches for 3.10-rc1

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/