[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <498B0315.5080804@zytor.com>
Date: Thu, 05 Feb 2009 07:17:41 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Arnd Bergmann <arnd@...db.de>
CC: Jaswinder Singh Rajput <jaswinder@...nel.org>,
Herbert Xu <herbert@...dor.apana.org.au>, mingo@...e.hu,
x86@...nel.org, sam@...nborg.org, jirislaby@...il.com,
gregkh@...e.de, davem@...emloft.net, xyzzy@...akeasy.org,
mchehab@...radead.org, jens.axboe@...cle.com,
linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
Avi Kivity <avi@...hat.com>, netfilter-devel@...r.kernel.org
Subject: Re: [GIT PULL -tip] fix 22 make headers_check - 200901
Arnd Bergmann wrote:
> On Wednesday 04 February 2009, H. Peter Anvin wrote:
>> Actually, if anything we should move the *non* __KERNEL_STRICT_NAMES out
>> of <linux/types.h> into something else, or completely deep-six them. I
>> don't know of any libc which wants these anymore, and I think they're
>> just residual libc5 cruft.
>>
>> However, if we want <linux/extra_types.h> that's fine with me; but
>> <linux/types.h> really should be clean, which means doing what
>> __KERNEL_STRICT_NAMES does now.
>
> Right now, we have 15 exported headers [1] that use the non-strict
> posix types (pid_t, off_t, clock_t, ...) and a set of 106 (!)
> files [2] using non-strict integer types (u_int32_t, uint32_t, u32, ...),
> 76 of those alone in netfilter.
>
Geez. The integer types is just a pattern replacement, so those we can
just fix. The 15 exported headers that use other types may very well be
real bugs -- we have had a fair share of broken ioctl signatures due to
exactly this problem.
> Do you think we should fix up all of them before 2.6.29? I'm worried
> that we might introduce more regressions in the process.
> Also, should we leave netfilter alone, in order to reduce the changes?
> I'm also unsure whether a hack in headers_install would be better than
> changing the headers in the source tree.
I have been advocating for hacking headers_install for a while. That
takes care of the 106. The 15 *need* to be audited immediately, because
that is even likely to be actual manifest bugs.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
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