linux-kernel - Re: [PATCH 0/3] video/fbdev: avoid module usage in non-modular sparc code

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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 29 Feb 2016 10:44:59 +0200
From:	Tomi Valkeinen <tomi.valkeinen@...com>
To:	Paul Gortmaker <paul.gortmaker@...driver.com>
CC:	<linux-kernel@...r.kernel.org>,
	"David S. Miller" <davem@...emloft.net>,
	Jean-Christophe Plagniol-Villard <plagnioj@...osoft.com>,
	<linux-fbdev@...r.kernel.org>, <sparclinux@...r.kernel.org>
Subject: Re: [PATCH 0/3] video/fbdev: avoid module usage in non-modular sparc
 code

On 26/02/16 15:58, Paul Gortmaker wrote:

> A counter point would be that if an old driver has remained non-modular
> for all these years, then clearly there is no demand for adding a new
> modular implementation at this point in time.

True. Then again, I think fbdev drivers are almost always used as
built-in to get the console up and running early. For fbdev I see the
module support mostly as a way to improve the code quality and to
simplify development and testing.

> The main reason is listed as #4 above -- if we keep drivers around that
> reflect a disconnect between Kconfig and code, the same mistake gets
> copied into more and more new drivers as they are created.

Yep, but the same could be said about having drivers without module
support too =).

In any case, I don't accept new fbdev drivers except in special cases,
so fbdev drivers' value as examples is not that much.

> If the argument was to not go in and rewrite core code for legacy
> drivers, I'd agree with that, but that isn't what is happening here.
> In a lot of these type changes, where the only change is to replace
> module_init with device initcall, the object files are identical.

Yes, the patches look simple enough. Ensuring they would work as modules
would be riskier.

> If subsystem maintainers would rather have blanket tristate coversions
> and whatever changes are required to make it compile and modpost, and
> are OK to assume things will just work, then that could be an option...

Nope, I think these are fine. I'll queue them up for 4.6.

 Tomi



Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)