On Sun, Jan 18, 2009 at 10:13:00AM +0100, Ingo Molnar wrote: > > * Sam Ravnborg <sam@xxxxxxxxxxxx> wrote: > > > On Sun, Jan 18, 2009 at 08:37:41AM +1100, David Woodhouse wrote: > > > On Sun, 2009-01-18 at 01:47 +0530, Jaswinder Singh Rajput wrote: > > > > --- a/include/linux/dvb/audio.h > > > > +++ b/include/linux/dvb/audio.h > > > > @@ -24,9 +24,8 @@ > > > > #ifndef _DVBAUDIO_H_ > > > > #define _DVBAUDIO_H_ > > > > > > > > -#ifdef __KERNEL__ > > > > #include <linux/types.h> > > > > -#else > > > > +#ifndef __KERNEL__ > > > > #include <stdint.h> > > > > #endif > > > > > > > > > > That patch looks wrong, and unnecessary. It was fine before. > > Nope - include/linux/dvb/audio.h failed to include linux/types.h > > despite the fact that is uses __u32 etc. > > > > But why the _kernel_ should include a userspace header is > > much more questionable. > > ok, i dropped this one for the time being. > > Sam, Andrew, et al, i've got the commit lineup below, to fix the ~200 new > CONFIG_HEADERS_CHECK=y warnings we have in current -git, on x86 > allyesconfig. > > Note that i have restructured the tree and the commits so that this effort > can be tracked more easily: each commit has a "headers_check fix" subject > line prefix. So you can go back later and revisit these things - for > example whether a header really needs to be exported to user-space, via: > > git log --grep='headers_check fix:' --pretty=format:"%h: %s" > > to get an overview and a historic track record. We can follow this > notation in the future too. > > So if there are no objections, i'll send this to Linus tomorrow-ish and > we'll have the worst of the fallout behind us and can embark on a much > more fluid (and per maintainer) headers_check related workflow. Thanks for taking care of this Ingo and please push towards Linus. And thanks to all the contributors too - it was great to see this dealt with soo quickly! Sam -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html