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 netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
