> Date: Mon, 15 Jun 1998 22:42:02 -0400
> From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
>
> [ Below is how I believe Linus feels about the matter and why
> he did things the way he did, he can comment if what I say
> is inaccurate. ]
>
> However, if the interface is provided by the kernel, and not libc ---
> such as ioctl's, filesystem constants, etc., then the right place to
> define these numbers is in the Linux header files, and including
> <linux/*.h> for those constants *is* the right thing, regardless of what
> Linus might have said. Replicating such constants in user programs is
> madness.
>
> (I suspect Linus was thinking only of the first case, and not the second.)
>
> Not true. Linus did not like having the new restriction of having to
> keep a clean kernel header namespace with respect to whatever new
> standard popped up with which glibc needed to be compliant with.
>
> He was sent patches which did whatever was necessary to make for a
> totally clean namespace in all kernel headers, and the response was
> "no way".
>
> It's a tug of war. We want updates of kernel constants etc. to
> propagate into userspace as efficiently as possible, but at the same
> time we don't want to be required to make sure every single kernel
> header is xyz standard of the day compliant.
>
In a similiar circumstance, I created "public" headers which had the same
name as the private headerss but contained only the constants, typedefs,
enums, APIs, etc which I needed to export. The creation process read the
private header files and created the new public files... control was via
the old public header files.
john alvord
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu