linux-kernel - How to handle patches that require regular regeneration

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Date:	Tue, 02 Aug 2011 16:07:08 +0100
From:	David Howells <dhowells@...hat.com>
To:	torvalds@...l.org
cc:	dhowells@...hat.com, sfr@...b.auug.org.au,
	linux-kernel@...r.kernel.org
Subject: How to handle patches that require regular regeneration

Hi Linus,

Having observed your recent complaint:

	http://article.gmane.org/gmane.linux.kernel/1173804

	"But best would be if it was actually tested, and had actually been in
	-next for a week. That is *especially* true when you send me a pull
	request late in the merge window."

And I have a question as how you might prefer to handle some classes of
patchset.

I have a patchset that needs regular regeneration as it scriptually alters all
the header files that are exported to userspace as a first step in cleaning up
the headers preparatory to sorting out the inclusion recursion issues.

	http://git.infradead.org/users/dhowells/linux-headers.git/shortlog/refs/heads/uapi-split

What's the best way to handle a patchset like this?

Do I point Stephen at a script and ask him to run that to create a new tree
for him to pull into linux-next, knowing that you probably won't be able to
pull the tree directly anyway?

I agree that including it in linux-next would be good, but it potentially
sticks a large burden on Stephen:-/

I know the patches compiled with allyesconfig for x86_64, i386 and MIPS with
some disabling in the configuration to handle stuff that was failing anyway.

I've done my best to make sure that the patches don't lose any content, but
occasionally the scripts have to be coached as to the right place to make a
split.

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