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: <20240301043316.GO11972@google.com>
Date: Fri, 1 Mar 2024 13:33:16 +0900
From: Sergey Senozhatsky <senozhatsky@...omium.org>
To: Masahiro Yamada <masahiroy@...nel.org>
Cc: Sergey Senozhatsky <senozhatsky@...omium.org>,
	linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCHv2] kconfig: add some Kconfig env variables to make help

On (24/03/01 00:35), Masahiro Yamada wrote:
> > >   "I am interested only in these. I do not care about the rest,
> >
> > It's "I *do NOT know* what the rest do".  I cannot document something
> > that I have no knowledge of, can I?  So as a reasonable start I added
> > only those that I'm familiar with (and I have explicitly stated that
> > in previous emails), and I disagree with the "bad attitude" label.
> 
> 
> You were aware of:
> 
>  - several env variables are listed in the document
>  - your patch would introduce a new "inconsistency"
>  - somebody else would need to make efforts to solve it

OK.

> > So the rational for that was that people run "make help" and find
> > out about new build targets, for instance, but there is no way for
> > people to find out about new Kconfig features (and yes, we are talking
> > "new features" here) that are controlled by env variables.  We need
> > to do something about it, don't you agree?
> 
> Disagree.
> 
> I maintain the entire Kconfig, not like you only caring about
> a particular feature.
> 
> If you add only two in help, I have no idea about
> what it will look like in the end.
> I am not convinced that it will be in good shape.
> So, it is reasonable for me to reject it.

Yes, OK.  I wasn't talking about this patch in particular at that
point, I was more curious whether you agreed that we need to document
in some way those vars in `make help` or not.  If you see value in
documenting them then I can sit down and try to come up with v3 that
will (in one way or another) give a simple "help" description for
each of Kconfig's vars.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ