linux-kernel - Re: [PATCH 1/7] platform_device: better support builtin boilerplate avoidance

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]

Message-ID: <CACRpkdb4Qdv2A_VZ4f9Duvfu7YEbV1+OP7Yx9Co1NeBVuT=TAQ@mail.gmail.com>
Date:	Tue, 12 May 2015 13:46:50 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Paul Gortmaker <paul.gortmaker@...driver.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH 1/7] platform_device: better support builtin boilerplate avoidance

On Sun, May 10, 2015 at 9:49 PM, Paul Gortmaker
<paul.gortmaker@...driver.com> wrote:

> We have macros that help reduce the boilerplate for modules
> that register with no extra init/exit complexity other than the
> most standard use case.  However we see an increasing number of
> non-modular drivers using these modular_driver() type register
> functions.
>
> There are several downsides to this:
> 1) The code can appear modular to a reader of the code, and they
>    won't know if the code really is modular without checking the
>    Makefile and Kconfig to see if compilation is governed by a
>    bool or tristate.
> 2) Coders of drivers may be tempted to code up an __exit function
>    that is never used, just in order to satisfy the required three
>    args of the modular registration function.
> 3) Non-modular code ends up including the <module.h> which increases
>    CPP overhead that they don't need.
> 4) It hinders us from performing better separation of the module
>    init code and the generic init code.
>
> Here we introduce similar macros, with the mapping from module_driver
> to builtin_driver and similar, so that simple changes of:
>
>   module_platform_driver()       --->  builtin_platform_driver()
>   module_platform_driver_probe() --->  builtin_platform_driver_probe().
>
> can help us avoid #3 above, without having to code up the same
> __init functions and device_initcall() boilerplate.
>
> For non modular code, module_init becomes __initcall.  But direct use
> of __initcall is discouraged, vs. one of the priority categorized
> subgroups.  As __initcall gets mapped onto device_initcall, our
> use of device_initcall directly in this change means that the
> runtime impact is zero -- drivers will remain at level 6 in the
> initcall ordering.
>
> Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@...driver.com>

This does not inhibit probe() and remove() to be
triggered from sysfs does it?

What is needed on builtin drivers is to set
.suppress_bind_attrs = true on the struct device_driver
so that we inhibit the creation of sysfs files to probe
and remove the driver by operator intervention.

I don't know if there is a simple way do address
this though since you don't seem to operate on
the struct device_driver, just pass it on.

Maybe it's possible to inhibit compilation of
builtin_platform_driver's if .suppress_bind_attrs == 0?

Yours,
Linus Walleij
--
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/