[PATCH v1 1/1] kernel.h: Move upper_*_bits() and lower_*_bits() to wordpath.h

[PATCH v1 1/1] kernel.h: Move upper_*_bits() and lower_*_bits() to wordpath.h

[Andy Shevchenko]

The wordpart.h header is collecting APIs related to the handling
parts of the word (usually in byte granularity). The upper_*_bits()
and lower_*_bits() are good candidates to be moved to there.

This helps to clean up header dependency hell with regard to kernel.h
as the latter gathers completely unrelated stuff together and slows
down compilation (especially when it's included into other header).

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---

Kees, since wordpart.h is now only in your tree, this is supposed
to go there as well.

 include/linux/kernel.h   | 30 ++----------------------------
 include/linux/wordpart.h | 29 +++++++++++++++++++++++++++++
 2 files changed, 31 insertions(+), 28 deletions(-)

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 5f74733391ed..d718fbec72dd 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -33,6 +33,8 @@
 #include <linux/sprintf.h>
 #include <linux/static_call_types.h>
 #include <linux/instruction_pointer.h>
+#include <linux/wordpart.h>
+
 #include <asm/byteorder.h>
 
 #include <uapi/linux/kernel.h>
@@ -52,34 +54,6 @@
 }					\
 )
 
-/**
- * upper_32_bits - return bits 32-63 of a number
- * @n: the number we're accessing
- *
- * A basic shift-right of a 64- or 32-bit quantity.  Use this to suppress
- * the "right shift count >= width of type" warning when that quantity is
- * 32-bits.
- */
-#define upper_32_bits(n) ((u32)(((n) >> 16) >> 16))
-
-/**
- * lower_32_bits - return bits 0-31 of a number
- * @n: the number we're accessing
- */
-#define lower_32_bits(n) ((u32)((n) & 0xffffffff))
-
-/**
- * upper_16_bits - return bits 16-31 of a number
- * @n: the number we're accessing
- */
-#define upper_16_bits(n) ((u16)((n) >> 16))
-
-/**
- * lower_16_bits - return bits 0-15 of a number
- * @n: the number we're accessing
- */
-#define lower_16_bits(n) ((u16)((n) & 0xffff))
-
 struct completion;
 struct user;
 
diff --git a/include/linux/wordpart.h b/include/linux/wordpart.h
index c9e6bd773ebd..f6f8f83b15b0 100644
--- a/include/linux/wordpart.h
+++ b/include/linux/wordpart.h
@@ -2,6 +2,35 @@
 
 #ifndef _LINUX_WORDPART_H
 #define _LINUX_WORDPART_H
+
+/**
+ * upper_32_bits - return bits 32-63 of a number
+ * @n: the number we're accessing
+ *
+ * A basic shift-right of a 64- or 32-bit quantity.  Use this to suppress
+ * the "right shift count >= width of type" warning when that quantity is
+ * 32-bits.
+ */
+#define upper_32_bits(n) ((u32)(((n) >> 16) >> 16))
+
+/**
+ * lower_32_bits - return bits 0-31 of a number
+ * @n: the number we're accessing
+ */
+#define lower_32_bits(n) ((u32)((n) & 0xffffffff))
+
+/**
+ * upper_16_bits - return bits 16-31 of a number
+ * @n: the number we're accessing
+ */
+#define upper_16_bits(n) ((u16)((n) >> 16))
+
+/**
+ * lower_16_bits - return bits 0-15 of a number
+ * @n: the number we're accessing
+ */
+#define lower_16_bits(n) ((u16)((n) & 0xffff))
+
 /**
  * REPEAT_BYTE - repeat the value @x multiple times as an unsigned long value
  * @x: value to repeat
-- 
2.43.0.rc1.1.gbec44491f096

Re: [PATCH v1 1/1] kernel.h: Move upper_*_bits() and lower_*_bits() to wordpath.h

[Randy Dunlap]

On 2/14/24 09:26, Andy Shevchenko wrote:
> The wordpart.h header is collecting APIs related to the handling
> parts of the word (usually in byte granularity). The upper_*_bits()
> and lower_*_bits() are good candidates to be moved to there.
> 
> This helps to clean up header dependency hell with regard to kernel.h
> as the latter gathers completely unrelated stuff together and slows
> down compilation (especially when it's included into other header).
> 
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
> 
> Kees, since wordpart.h is now only in your tree, this is supposed
> to go there as well.

after someone corrects the Subject (wordpath -> wordpart).

Reviewed-by: Randy Dunlap <rdunlap@infradead.org>


> 
>  include/linux/kernel.h   | 30 ++----------------------------
>  include/linux/wordpart.h | 29 +++++++++++++++++++++++++++++
>  2 files changed, 31 insertions(+), 28 deletions(-)
> 
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index 5f74733391ed..d718fbec72dd 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -33,6 +33,8 @@
>  #include <linux/sprintf.h>
>  #include <linux/static_call_types.h>
>  #include <linux/instruction_pointer.h>
> +#include <linux/wordpart.h>
> +
>  #include <asm/byteorder.h>
>  
>  #include <uapi/linux/kernel.h>
> @@ -52,34 +54,6 @@
>  }					\
>  )
>  
> -/**
> - * upper_32_bits - return bits 32-63 of a number
> - * @n: the number we're accessing
> - *
> - * A basic shift-right of a 64- or 32-bit quantity.  Use this to suppress
> - * the "right shift count >= width of type" warning when that quantity is
> - * 32-bits.
> - */
> -#define upper_32_bits(n) ((u32)(((n) >> 16) >> 16))
> -
> -/**
> - * lower_32_bits - return bits 0-31 of a number
> - * @n: the number we're accessing
> - */
> -#define lower_32_bits(n) ((u32)((n) & 0xffffffff))
> -
> -/**
> - * upper_16_bits - return bits 16-31 of a number
> - * @n: the number we're accessing
> - */
> -#define upper_16_bits(n) ((u16)((n) >> 16))
> -
> -/**
> - * lower_16_bits - return bits 0-15 of a number
> - * @n: the number we're accessing
> - */
> -#define lower_16_bits(n) ((u16)((n) & 0xffff))
> -
>  struct completion;
>  struct user;
>  
> diff --git a/include/linux/wordpart.h b/include/linux/wordpart.h
> index c9e6bd773ebd..f6f8f83b15b0 100644
> --- a/include/linux/wordpart.h
> +++ b/include/linux/wordpart.h
> @@ -2,6 +2,35 @@
>  
>  #ifndef _LINUX_WORDPART_H
>  #define _LINUX_WORDPART_H
> +
> +/**
> + * upper_32_bits - return bits 32-63 of a number
> + * @n: the number we're accessing
> + *
> + * A basic shift-right of a 64- or 32-bit quantity.  Use this to suppress
> + * the "right shift count >= width of type" warning when that quantity is
> + * 32-bits.
> + */
> +#define upper_32_bits(n) ((u32)(((n) >> 16) >> 16))
> +
> +/**
> + * lower_32_bits - return bits 0-31 of a number
> + * @n: the number we're accessing
> + */
> +#define lower_32_bits(n) ((u32)((n) & 0xffffffff))
> +
> +/**
> + * upper_16_bits - return bits 16-31 of a number
> + * @n: the number we're accessing
> + */
> +#define upper_16_bits(n) ((u16)((n) >> 16))
> +
> +/**
> + * lower_16_bits - return bits 0-15 of a number
> + * @n: the number we're accessing
> + */
> +#define lower_16_bits(n) ((u16)((n) & 0xffff))
> +
>  /**
>   * REPEAT_BYTE - repeat the value @x multiple times as an unsigned long value
>   * @x: value to repeat

-- 
#Randy

Re: [PATCH v1 1/1] kernel.h: Move upper_*_bits() and lower_*_bits() to wordpath.h

[Andy Shevchenko]

On Wed, Feb 14, 2024 at 10:09:10AM -0800, Randy Dunlap wrote:
> On 2/14/24 09:26, Andy Shevchenko wrote:
> > The wordpart.h header is collecting APIs related to the handling
> > parts of the word (usually in byte granularity). The upper_*_bits()
> > and lower_*_bits() are good candidates to be moved to there.
> > 
> > This helps to clean up header dependency hell with regard to kernel.h
> > as the latter gathers completely unrelated stuff together and slows
> > down compilation (especially when it's included into other header).
> > 
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > ---
> > 
> > Kees, since wordpart.h is now only in your tree, this is supposed
> > to go there as well.
> 
> after someone corrects the Subject (wordpath -> wordpart).

Oh, indeed. Thanks for spotting this!
Kees, should I send a v2 or you can amend when applying?

> Reviewed-by: Randy Dunlap <rdunlap@infradead.org>

Thanks!

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 1/1] kernel.h: Move upper_*_bits() and lower_*_bits() to wordpath.h

[Kees Cook]

On Wed, Feb 14, 2024 at 08:12:00PM +0200, Andy Shevchenko wrote:
> On Wed, Feb 14, 2024 at 10:09:10AM -0800, Randy Dunlap wrote:
> > On 2/14/24 09:26, Andy Shevchenko wrote:
> > > The wordpart.h header is collecting APIs related to the handling
> > > parts of the word (usually in byte granularity). The upper_*_bits()
> > > and lower_*_bits() are good candidates to be moved to there.
> > > 
> > > This helps to clean up header dependency hell with regard to kernel.h
> > > as the latter gathers completely unrelated stuff together and slows
> > > down compilation (especially when it's included into other header).
> > > 
> > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > > ---
> > > 
> > > Kees, since wordpart.h is now only in your tree, this is supposed
> > > to go there as well.
> > 
> > after someone corrects the Subject (wordpath -> wordpart).
> 
> Oh, indeed. Thanks for spotting this!
> Kees, should I send a v2 or you can amend when applying?

I've amended it; thanks for the catch Randy!

-Kees

> 
> > Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
> 
> Thanks!
> 
> -- 
> With Best Regards,
> Andy Shevchenko
> 
> 

-- 
Kees Cook

Re: [PATCH v1 1/1] kernel.h: Move upper_*_bits() and lower_*_bits() to wordpath.h

[Kees Cook]

On Wed, 14 Feb 2024 19:26:32 +0200, Andy Shevchenko wrote:
> The wordpart.h header is collecting APIs related to the handling
> parts of the word (usually in byte granularity). The upper_*_bits()
> and lower_*_bits() are good candidates to be moved to there.
> 
> This helps to clean up header dependency hell with regard to kernel.h
> as the latter gathers completely unrelated stuff together and slows
> down compilation (especially when it's included into other header).
> 
> [...]

Applied to for-next/hardening, thanks!

[1/1] kernel.h: Move upper_*_bits() and lower_*_bits() to wordpart.h
      https://git.kernel.org/kees/c/9aa3bb490404

Take care,

-- 
Kees Cook

Re: [PATCH v1 1/1] kernel.h: Move upper_*_bits() and lower_*_bits() to wordpath.h

[Max Kellermann]

On Thu, Feb 15, 2024 at 9:49 AM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
> The wordpart.h header is collecting APIs related to the handling
> parts of the word (usually in byte granularity). The upper_*_bits()
> and lower_*_bits() are good candidates to be moved to there.

Sigh. This was actually a copy of my patch which I submitted a week
before yours. https://lore.kernel.org/lkml/20240209164027.2582906-34-max.kellermann@ionos.com/

Re: [PATCH v1 1/1] kernel.h: Move upper_*_bits() and lower_*_bits() to wordpath.h

[Andy Shevchenko]

On Thu, Feb 15, 2024 at 09:53:48AM +0100, Max Kellermann wrote:
> On Thu, Feb 15, 2024 at 9:49 AM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > The wordpart.h header is collecting APIs related to the handling
> > parts of the word (usually in byte granularity). The upper_*_bits()
> > and lower_*_bits() are good candidates to be moved to there.
> 
> Sigh. This was actually a copy of my patch which I submitted a week
> before yours. https://lore.kernel.org/lkml/20240209164027.2582906-34-max.kellermann@ionos.com/

But it was not standalone and the series has issues AFAICS.
Nevertheless, I like it!

In any case the wordpart.h is only in Kees' tree, hence can't be applied
separately right now, so if you continue with a series it's technically can't
be applied before v6.9-rc1.


-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 1/1] kernel.h: Move upper_*_bits() and lower_*_bits() to wordpath.h

[Andy Shevchenko]

On Thu, Feb 15, 2024 at 03:50:51PM +0200, Andy Shevchenko wrote:
> On Thu, Feb 15, 2024 at 09:53:48AM +0100, Max Kellermann wrote:
> > On Thu, Feb 15, 2024 at 9:49 AM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > > The wordpart.h header is collecting APIs related to the handling
> > > parts of the word (usually in byte granularity). The upper_*_bits()
> > > and lower_*_bits() are good candidates to be moved to there.
> > 
> > Sigh. This was actually a copy of my patch which I submitted a week
> > before yours. https://lore.kernel.org/lkml/20240209164027.2582906-34-max.kellermann@ionos.com/
> 
> But it was not standalone and the series has issues AFAICS.
> Nevertheless, I like it!
> 
> In any case the wordpart.h is only in Kees' tree, hence can't be applied
> separately right now, so if you continue with a series it's technically can't
> be applied before v6.9-rc1.

Btw, you need to look to the patches by Ingo, you are repeating some of them.

-- 
With Best Regards,
Andy Shevchenko