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: <CACqU3MUfJAeur_65i5vDegu1d1VqAdq15EedfX9A3w52J23MPg@mail.gmail.com>
Date:	Tue, 13 Sep 2011 17:13:29 -0400
From:	Arnaud Lacombe <lacombar@...il.com>
To:	Michal Marek <mmarek@...e.cz>
Cc:	linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFC] Kbuild: allow code re-use across different directories

Hi,

2011/9/9 Michal Marek <mmarek@...e.cz>:
> On 20.8.2011 02:37, Arnaud Lacombe wrote:
>> Hi folks,
>>
>> The attached patch modify Kbuild to allow to directly re-use code in multiple
>> directory without having to go through a copy. Technically, it changes Kbuild to
>> use by default the VPATH feature of GNU make and provides accessors for Makefile
>> to change it indirectly.
>>
>> Considering:
>>
>> arch/foo/lib:
>> fancy.c
>>
>> We want to be able to build it with -DPANTS=32 in the kernel, but the
>> bootloader requires -DPANTS_SIZE=30.
>>
>> Currently we would do, either:
>>
>> arch/foo/lib/Makefile
>> LDFLAGS_fancy.o := -DPANTS=32
>> obj-y += fancy.o
>>
>> and, either:
>>
>> arch/foo/boot/Makefile:
>> LDFLAGS_fancy.o := -DPANTS=30
>> obj-y += fancy.o
>> $(obj)/fancy.c: $(srctree)/arch/foo/lib/fancy.c
>>       $(call cmd,shipped)
>>
>> or
>>
>> arch/foo/boot/Makefile:
>> LDFLAGS_fancy.o := -DPANTS=30
>> obj-y += fancy.o
>> $(obj)/fancy.o: $(srctree)/arch/foo/lib/fancy.c
>>       $(call cmd,cc_c_o)
>>
>> The former implies an extra copy of the source file, the latter expose Kbuild
>> internal function.
>>
>> With the attached patch, we would do:
>>
>> arch/foo/boot/Makefile:
>> LDFLAGS_fancy.o := -DPANTS=30
>> obj-y += fancy.o
>> vpath-y += $(srctree)/arch/foo/lib
>>
>> and let GNU make do the job.
>
> I like this. The only issue I can think of right now, is that if you add
> a large directory to vpath-y, then it would be easy to accidentally
> reuse more files from that directory than intended. But that could be
> easily prevented by isolating those reusable source files.
>
I do not think it is that dangerous. We enforce unique access to VPATH
and we still prioritize $(src) over any other specified path.

That said, what would you want to pull the patch into -next, beside
kernel.org being up ?

Thanks,
 - Arnaud
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ