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.
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.
Arnd <><
[1] for i in dev_t mode_t off_t pid_t suseconds_t timer_t uid_t gid_t \
loff_t time_t clock_t caddr_t ; do grep \\\<$i\\\> $obj/usr/include ; \
done | sort | grep -v linux/types.h
[2] grep '\<\(\(u_\|u\|\)int\(8\|16\|32\|64\)_t\|[us]\(8\|16\|32\|64\)\)\>' \
$obj/usr/include | grep -v linux/types.h
--
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
