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
| ||
|
Date: Mon, 5 Mar 2007 20:08:52 +0100 From: Sam Ravnborg <sam@...nborg.org> To: FN <zzzz444@....net> Cc: Oleg Verych <olecom@...wer.upol.cz>, linux-kernel@...r.kernel.org Subject: Re: module builds need improvement / top Makefile not good enough On Mon, Mar 05, 2007 at 05:53:14AM -0800, FN wrote: > | > I am unhappy with the direction the 2.6 kernel builds have taken. > | > Very much like Micro$loth DDKs we (linux users) are being forced to > | > build modules by plugging into a framework that doesn't respect the > fine > | > aspects of dependency generation and analysis. > | > | Ideas in form of patches are accepted, > > I think that one of the bigger firms that support linux, like IBM, > Redhat, > Suse, ought to hire a contractor to redesign kbuild and get the linux > community involved. Obviously kbuild can be better and if someone are committed to put in a month work on kbuild we would see improvements. As the kbuild maintainer I am the first to agree on this. kbuild has taken the direction where make is used not only as a simple DAG tool - be some of the other facilities has been utilised to support some of the following goals: -> Very simple Kbuild files for the simple cases - and the simple cases counts for more than 95% of the Kbuild files in the kernel. -> One kbuild file pr. directory for simplicity -> rebuild in case prerequisites OR referred CONFIG symbol changes -> rebuild if commandline arguments changes (but not order of these) -> revert back to known Makefile syntax for complex scenarios -> make kbuild infrastructure avialable for external modules to make build of these more releiable (pick up correct CONFIG) -> Last but not least - relaible. These golas are fulfilled by kbuild today. You want to add another few goals: -> Do not rely on GNU Make -> Track actual timestamp/file content to support ClarCase dynamic views > Currently I face the following situation -- I try to build 2 drivers > from the same Makefile If you try to use Kbuild in a way it is not designed to be used then you will obviously face issues. One Kbuild file pr. directory. Use a top-level Kbuild file to specify both sub-directory Kbuild files. This structure works well for the kernel - so it should work well for your module too? I am open for specific improvement proposals - but not for 'redo from scratch proposals'. 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/
Powered by blists - more mailing lists