Messages in this thread | | | Date | Tue, 16 Jun 1998 09:35:05 -0400 (EDT) | From | John Alvord <> | Subject | Re: OFFTOPIC: e2fsprogs and +2Gb partitions |
| |
On Mon, 15 Jun 1998, David S. Miller wrote:
> 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
| |