linux-kernel - Re: [RFC] Extending kbuild syntax

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:	Sun, 30 Sep 2007 12:29:03 +0200
From:	Sam Ravnborg <sam@...nborg.org>
To:	Adrian Bunk <bunk@...nel.org>
Cc:	kbuild devel <kbuild-devel@...ts.sourceforge.net>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] Extending kbuild syntax

On Sun, Sep 30, 2007 at 05:02:58AM +0200, Adrian Bunk wrote:
> On Sat, Sep 29, 2007 at 10:11:45PM +0200, Sam Ravnborg wrote:
> >...
> > The second is the more controversial suggestion.
> > In several Makefile we have simple if expression of the variants:
> > if ($(CONFIG_FOO),y)
> >   obj-$(CONFIG_BAR) += fubar.o
> > endif
> > 
> > The pattern varies over this theme.
> > The suggestion here is to introduce a few helpers:
> > 
> > obj-y-if-$(CONFIG_FOO) += fubar.o
> > This one shall read:
> > if $(CONFIG_FOO) is y or m then set += to obj-y
> 
> IMHO for people who are not kbuild junkies the pattern is more clear 
> with the current syntax.
> 
> But you should better ask some guinea pigs who have not already seen as 
> many kernel Makefiles as I have...

Target group are for kernel developers and people who have
actually read Documentation/kbuild/makefiles.txt

But point taken - this is too 'magic'.
I will try to think of something that looks a bit more straightforward.

> Some of the cases have the following pattern:
> 
> config X86_POWERNOW_K8_ACPI
>         bool
>         depends on X86_POWERNOW_K8 && ACPI_PROCESSOR
>         depends on !(X86_POWERNOW_K8 = y && ACPI_PROCESSOR = m)
>         default y
> 
> Your suggested syntax has to be enhanced with three additional
> variables for handling such cases.
> 
> 
> The complicated cases can be handled either in kconfig or in kbuild,
> and I think kconfig is the better place for them:

The kbuild enhancements are for the cases where it
makes less sense to express this in Kconfig.
They are not thought as replacing Kconfig dependencies in any way.

I will try to come up with a new proposal later today.

	Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/