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:	Sun, 10 May 2015 15:49:39 -0400
From:	Paul Gortmaker <paul.gortmaker@...driver.com>
To:	<linux-kernel@...r.kernel.org>
CC:	Paul Gortmaker <paul.gortmaker@...driver.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: [PATCH 1/7] platform_device: better support builtin boilerplate avoidance

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

[checkpatch complains about this patch, but I choose to ignore that
 and keep the added code 100% consistent with the existing code.]

 include/linux/device.h          | 22 ++++++++++++++++++++++
 include/linux/platform_device.h | 23 +++++++++++++++++++++++
 2 files changed, 45 insertions(+)

diff --git a/include/linux/device.h b/include/linux/device.h
index 6558af90c8fe..c2d6167cb4a3 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -1269,4 +1269,26 @@ static void __exit __driver##_exit(void) \
 } \
 module_exit(__driver##_exit);
 
+/**
+ * builtin_driver() - Helper macro for drivers that don't do anything
+ * special in init and have no exit. This eliminates some boilerplate.
+ * Each driver may only use this macro once, and calling it replaces
+ * device_initcall (or in some cases, the legacy __initcall).  This is
+ * meant to be a direct parallel of module_driver() above but without
+ * the __exit stuff that is not used for builtin cases.
+ *
+ * @__driver: driver name
+ * @__register: register function for this driver type
+ * @...: Additional arguments to be passed to __register
+ *
+ * Use this macro to construct bus specific macros for registering
+ * drivers, and do not use it on its own.
+ */
+#define builtin_driver(__driver, __register, ...) \
+static int __init __driver##_init(void) \
+{ \
+	return __register(&(__driver) , ##__VA_ARGS__); \
+} \
+device_initcall(__driver##_init);
+
 #endif /* _DEVICE_H_ */
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index 58f1e75ba105..bba08f44cc97 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -222,6 +222,15 @@ static inline void platform_set_drvdata(struct platform_device *pdev,
 	module_driver(__platform_driver, platform_driver_register, \
 			platform_driver_unregister)
 
+/* builtin_platform_driver() - Helper macro for builtin drivers that
+ * don't do anything special in driver init.  This eliminates some
+ * boilerplate.  Each driver may only use this macro once, and
+ * calling it replaces device_initcall().  Note this is meant to be
+ * a parallel of module_platform_driver() above, but w/o _exit stuff.
+ */
+#define builtin_platform_driver(__platform_driver) \
+	builtin_driver(__platform_driver, platform_driver_register)
+
 /* module_platform_driver_probe() - Helper macro for drivers that don't do
  * anything special in module init/exit.  This eliminates a lot of
  * boilerplate.  Each module may only use this macro once, and
@@ -240,6 +249,20 @@ static void __exit __platform_driver##_exit(void) \
 } \
 module_exit(__platform_driver##_exit);
 
+/* builtin_platform_driver_probe() - Helper macro for drivers that don't do
+ * anything special in device init.  This eliminates some boilerplate.  Each
+ * driver may only use this macro once, and using it replaces device_initcall.
+ * This is meant to be a parallel of module_platform_driver_probe above, but
+ * without the __exit parts.
+ */
+#define builtin_platform_driver_probe(__platform_driver, __platform_probe) \
+static int __init __platform_driver##_init(void) \
+{ \
+	return platform_driver_probe(&(__platform_driver), \
+				     __platform_probe);    \
+} \
+device_initcall(__platform_driver##_init); \
+
 #define platform_create_bundle(driver, probe, res, n_res, data, size) \
 	__platform_create_bundle(driver, probe, res, n_res, data, size, THIS_MODULE)
 extern struct platform_device *__platform_create_bundle(
-- 
2.2.1

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ