On Tue, Dec 09, 2014 at 12:49:17PM +0100, Daniel Borkmann wrote: > On 12/08/2014 10:15 PM, Paul Bolle wrote: > >On Mon, 2014-12-08 at 21:36 +0100, Paul Bolle wrote: > >>On Mon, 2014-12-08 at 20:41 +0100, Paul Bolle wrote: > >>>Well, it seems the treewide "boolean" cleanup should be done first. > >>>Removing support for "boolean" could than be a second, separate step. > >>>Just to ease review. > >> > >>This appears to have no effect on the .config files I generated for the > >>defconfig files in next-20141208. (After porting the patch and changing > >>those last booleans to bool, that is.) So that's good. > >> > >>If you'd resend as two patches on top of linux-next, I might add an > >>Acked-by: or a Tested-by:. > > > >My last mail on this series. To make sure the tree stays buildable that > >second patch to drop support for 'boolean' should only be applied a > >release or two after the cleanup patch has been applied. Otherwise we're > >bound to run into fun build errors in linux-next, and even mainline, for > >quite a few commits, aren't we? One tree still using boolean is all it > >takes... > > Sounds like a good plan, thanks a lot for looking into it, Paul! > > Meanwhile, also checkpatch.pl could emit a deprecate warning in case > a patch carries Kconfig code with 'boolean' in it, but I leave that > up to Christoph to decide. ;) Agree. Thanks for reviewing and testing! I'll resend a series on top of linux-next that takes all of your suggestions into account. Thanks, Chris -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
