All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andy.shevchenko@gmail.com>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: Tanzir Hasan <tanzirh@google.com>,
	Kees Cook <keescook@chromium.org>,
	linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org,
	Nick DeSaulniers <nnn@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	llvm@lists.linux.dev, Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH v2 1/2] sh: Added kernel.h to word-at-a-time
Date: Mon, 18 Dec 2023 19:23:23 +0200	[thread overview]
Message-ID: <ZYCACxTTc4j9VrIs@smile.fi.intel.com> (raw)
In-Reply-To: <CAKwvOdmMqJacYRfwohY-DXBbmNmz_M4EKUL1KuTv=tT2dO_p1g@mail.gmail.com>

On Mon, Dec 18, 2023 at 08:57:59AM -0800, Nick Desaulniers wrote:
> On Fri, Dec 15, 2023 at 11:09 AM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
> > On Fri, Dec 15, 2023 at 8:31 PM Tanzir Hasan <tanzirh@google.com> wrote:
> > > On Fri, Dec 15, 2023 at 8:04 AM Andy Shevchenko <andy@kernel.org> wrote:
> > >> On Thu, Dec 14, 2023 at 09:06:12PM +0000, tanzirh@google.com wrote:

...

> > >> > +#include <linux/kernel.h>
> > >>
> > >> I highly discourage from doing that. Instead, split what is needed to
> > >> the separate (new) header and include that one.
> > >
> > >
> > > I think it would make the most sense to do this in a separate patch.
> > > What word-at-a-time.h needs from kernel.h is REPEAT_BYTE and to my knowledge,
> > > almost every other version of word-at-a-time.h includes kernel.h gets this by
> > > including kernel.h. A future change could be removing REPEAT_BYTE
> > > out of kernel.h
> >
> > Just create a patch that either moves that macro (along with upper_*()
> > and lower_*() APIs) to a more distinguishable header
> > (maybe bytes.h or words.h or wordpart.h, etc) and use it in your case
> > and fix others.
> 
> Andy,
> These are good suggestions and we should do them...
> 
> ...and Tanzir only has 3 weeks left of his internship.  I don't want
> him to get bogged down chasing build regressions from modifying the
> headers themselves.  I think what's best for him from here through the
> remainder of his internship is to stay focused on applying suggestions
> from IWYU to just modify the #include list of .c files, and not start
> splitting .h files.  Splitting the .h files will be the next step, and
> is made easier by having the codebase not have so many indirect
> includes (via IWYU), but we need time to soak header changes, and time
> Tanzir does not have.  Please can we keep the suggestions focused on
> whether the modifications to the header includes (and the tangential
> cleanups) are correct?

Understood. Can we add a comment like

/* FIXME: replace with a proper header to avoid dependency hell */
#include <linux/kernel.h>

?

> While REPEAT_BYTE has a manageable number of users, upper_* and
> lower_* have significantly more; I worry about moving those causing
> regressions.

If you look at how I did similar in the past, I back included new header
into kernel.h. Not the pretty solution, but allows to split in the new code.

> We can move them, but such changes would need significantly more soak time

s/significantly//

But I got your point, see above.

> than this series IMO. Tanzir is also working on statistical analysis; I
> suspect if he analyzes include/linux/kernel.h, he can comment on whether the
> usage of REPEAT_BYTE is correlated with the usage of upper_* and lower_* in
> order to inform whether they should be grouped together or not.

-- 
With Best Regards,
Andy Shevchenko



  parent reply	other threads:[~2023-12-18 17:23 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-14 21:06 [PATCH v2 0/2] shrink lib/string.i via IWYU tanzirh
2023-12-14 21:06 ` [PATCH v2 1/2] sh: Added kernel.h to word-at-a-time tanzirh
2023-12-14 21:37   ` Kees Cook
2023-12-14 21:51     ` Nick Desaulniers
2023-12-15 16:04   ` Andy Shevchenko
     [not found]     ` <CAE-cH4p5VJ_A91BAkURBN67ACA0_u7T8UhApUYLQDWeeRY6FWA@mail.gmail.com>
2023-12-15 19:09       ` Andy Shevchenko
2023-12-18 16:57         ` Nick Desaulniers
2023-12-18 17:05           ` Tanzir Hasan
2023-12-18 17:25             ` Andy Shevchenko
2023-12-18 17:23           ` Andy Shevchenko [this message]
2023-12-14 21:06 ` [PATCH v2 2/2] lib/string: shrink lib/string.i via IWYU tanzirh
2023-12-14 21:39   ` Kees Cook
2023-12-15 16:08   ` Andy Shevchenko
2024-01-09 21:49   ` Justin Stitt
2024-01-11  0:07     ` Kees Cook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZYCACxTTc4j9VrIs@smile.fi.intel.com \
    --to=andy.shevchenko@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=keescook@chromium.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=ndesaulniers@google.com \
    --cc=nnn@google.com \
    --cc=tanzirh@google.com \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.