linux-kernel - Re: [PATCH 08/23] kconfig: add 'macro' keyword to support user-defined function

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, 16 Feb 2018 21:30:38 -0500 (EST)
From:   Nicolas Pitre <nico@...xnic.net>
To:     Ulf Magnusson <ulfalizer@...il.com>
cc:     Masahiro Yamada <yamada.masahiro@...ionext.com>,
        linux-kbuild@...r.kernel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Arnd Bergmann <arnd@...db.de>,
        Kees Cook <keescook@...omium.org>,
        Randy Dunlap <rdunlap@...radead.org>,
        Sam Ravnborg <sam@...nborg.org>,
        Michal Marek <michal.lkml@...kovi.net>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 08/23] kconfig: add 'macro' keyword to support user-defined
 function

On Sat, 17 Feb 2018, Ulf Magnusson wrote:

> On Fri, Feb 16, 2018 at 02:49:31PM -0500, Nicolas Pitre wrote:
> > On Sat, 17 Feb 2018, Masahiro Yamada wrote:
> > 
> > > Now, we got a basic ability to test compiler capability in Kconfig.
> > > 
> > > config CC_HAS_STACKPROTECTOR
> > >         bool
> > >         default $(shell $CC -Werror -fstack-protector -c -x c /dev/null -o /dev/null)
> > > 
> > > This works, but it is ugly to repeat this long boilerplate.
> > > 
> > > We want to describe like this:
> > > 
> > > config CC_HAS_STACKPROTECTOR
> > >         bool
> > >         default $(cc-option -fstack-protector)
> > > 
> > > It is straight-forward to implement a new function, but I do not like
> > > to hard-code specialized functions like this.  Hence, here is another
> > > feature to add functions from Kconfig files.
> > > 
> > > A user-defined function can be defined as a string type symbol with
> > > a special keyword 'macro'.  It can be referenced in the same way as
> > > built-in functions.  This feature was also inspired by Makefile where
> > > user-defined functions are referenced by $(call func-name, args...),
> > > but I omitted the 'call' to makes it shorter.
> > > 
> > > The macro definition can contain $(1), $(2), ... which will be replaced
> > > with arguments from the caller.
> > > 
> > > Example code:
> > > 
> > >   config cc-option
> > >           string
> > >           macro $(shell $CC -Werror $(1) -c -x c /dev/null -o /dev/null)
> > 
> > I think this syntax for defining a macro shouldn't start with the 
> > "config" keyword, unless you want it to be part of the config symbol 
> > space and land it in .config. And typing it as a "string" while it 
> > actually returns y/n (hence a bool) is also strange.
> > 
> > What about this instead:
> > 
> > macro cc-option
> > 	bool $(shell $CC -Werror $(1) -c -x c /dev/null -o /dev/null)
> > 
> > This makes it easier to extend as well if need be.
> > 
> > 
> > Nicolas
> 
> I haven't gone over the patchset in detail yet and might be missing
> something here, but if this is just meant to be a textual shorthand,
> then why give it a type at all?

It is meant to be like a user-defined function.

> Do you think a simpler syntax like this would make sense?
> 
> 	macro cc-option "$(shell $CC -Werror $(1) -c -x c /dev/null -o /dev/null)"
> 
> That's the most general version, where you could use it for other stuff
> besides $(shell ...) as well, just to keep parity.

This is not extendable.  Let's imagine that you might want to implement 
some kind of conditionals some day e.g.:

macro complex_test
	bool $(shell foo) if LOCKDEP_SUPPORT
	bool y if DEBUG_DRIVER
	bool n

There is no real advantage to simplify the macro definition to its 
simplest expression, unlike its actual usage.

> Are there any cases where something more advanced than that might be
> warranted (e.g., macros that expand to complete expressions)?

Maybe not now, but there is no need to close the door on the possibility 
either.


Nicolas