linux-kernel - Re: [PATCH] auxdisplay: linedisp: Support configuring the boot message

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: Fri, 31 May 2024 16:43:26 +0300
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Chris Packham <chris.packham@...iedtelesis.co.nz>, tzimmermann@...e.de,
	ojeda@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] auxdisplay: linedisp: Support configuring the boot
 message

On Fri, May 31, 2024 at 10:22:02AM +0200, Geert Uytterhoeven wrote:
> On Fri, May 31, 2024 at 10:16 AM Andy Shevchenko
> <andy.shevchenko@...il.com> wrote:
> > On Fri, May 31, 2024 at 10:45 AM Geert Uytterhoeven
> > <geert@...ux-m68k.org> wrote:
> > > On Fri, May 31, 2024 at 7:28 AM Chris Packham
> > > <chris.packham@...iedtelesis.co.nz> wrote:
> > > > Like we do for charlcd, allow the configuration of the initial message
> > > > on line-display devices.

..

> > > > +#ifndef CONFIG_PANEL_BOOT_MESSAGE
> > > >  #include <generated/utsrelease.h>
> > > > +#endif
> > >
> > > The #ifndef/#endif is not really needed.
> >
> > It's needed to avoid unnecessary build of the module (in case of m).
> 
> OK.
> 
> > > As I see no real deficiencies:
> > > Reviewed-by: Geert Uytterhoeven <geert@...ux-m68k.org>
> >
> > I believe you agree with leaving ifdeffery above.
> 
> Thanks, I agree to agree ;-)

Btw, I will take a long lasting vacations (ten weeks in a row) and most likely
won't be able to actively participate for this subsystem. Thinking about how
to proceed if something critical appears... Maybe you want a push access to the
same Git repo and in (rare) cases can handle fixes? We may ask Konstantin to
configure that on git.kernel.org.

P.S. This change doesn't seem to me as critical and there is still a chance
that I will have time to proceed, but the situation just motivated me to discuss
the possibilities.

-- 
With Best Regards,
Andy Shevchenko