linux-kernel - Re: discussion of Kbuild fixes (kbuild: Kbuild.include avoid using spaces in call arguments)

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: <20070208025934.GH22699@flower.upol.cz>
Date:	Thu, 8 Feb 2007 03:59:35 +0100
From:	Oleg Verych <olecom@...wer.upol.cz>
To:	Roman Zippel <zippel@...ux-m68k.org>
Cc:	Randy Dunlap <randy.dunlap@...cle.com>,
	Alexey Dobriyan <adobriyan@...il.com>, torvalds@...l.org,
	sam@...nborg.org, linux-kernel@...r.kernel.org
Subject: Re: discussion of Kbuild fixes (kbuild: Kbuild.include avoid using spaces in call arguments)

On Thu, Feb 08, 2007 at 03:05:41AM +0100, Roman Zippel wrote:
> Hi,
> 
> On Thu, 8 Feb 2007, Oleg Verych wrote:
> 
> > -- `find | sort' in localversion (i insist on split between paths and
> >     files)
> 
> make has dedicated functions for this.

I think, "make" (even whatever shiny new) that particular problem can't
handle. Regexp on *file name* is needed, while PATH must be untouched.
That what i meant with spliting tasks. Stripping strings of wildcards
by "make dedicated functions" is ugly, IMHO. 

Also, what do you think, if someone (very unlikely) will add port of build
system to something different? Clear logic for a "rule" is there, one can
easily make whole `include/config/kernel.release' with that.

> > -- symlinks to /dev/null in option checking -- isn't it better to not
> >    have any (though cached) access to files on filesystem, instead of to
> >    /dev/null? cont.:
> 
> symlinks are not much else than special files.

IMHO, cheap I/O. Yes, that isn't a big benefit, but i don't see anything
against, except, probably, filesystems without support of symlinks.

> > I wish to have more people to work on this (even with just comments),
> > because "Kbuild.include" was only first step to reduce bloated top
> > Makefile. Since then, it seems, Sam have more important things to do.
> 
> The problem is that you mix multiple changes into a single patch,

Yes, from whitespace-issue point of view, that was a huge change (:,

> but since kbuild is very central part that puts everything together,

and patch set didn't make a single release of -mm tree (:

> I don't think it's bad idea to be more conservative, especially if you
> just start to work on it.

.... alone. I think it will be OK, Linus is with us!

Thanks, Roman.

____
-
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/