Messages in this thread | | | Date | Tue, 16 Jun 1998 18:08:22 -0700 | From | "David S. Miller" <> | Subject | Re: OFFTOPIC: e2fsprogs and +2Gb partitions |
| |
Date: Tue, 16 Jun 1998 16:55:14 -0700 (PDT) From: Linus Torvalds <torvalds@transmeta.com>
I think that kernel header files should be used for building the kernel. Nothing else.
I for the most part agree. However the issue I brought up still stands for a soluation, as does another issue:
1) The latency from adding a new (for example) flag bit to a structure and when user programs can actually get at it.
2) The "just 'cp' it" argument is slightly parsimonious to me, if we could just 'cp' it, we wouldn't have kernel header file issues with glibc, changes do need to be made to make them "libc friendly" or whatnot, and here is where errors can be introduced
But I'm not so concerned about #2, I'm concerned about #1. Especially in places where the additional flags are needed for certain parts of core functionality in userspace. A good example of this case would be a package such as gated, which might test for presence of certain RTCF_* flags to determine which features it can enabled during a kernel build. How do I propagate new RTCF_* flags into userspace in a short period of time?
What about when new SCSI cdrom or IDE or (add your favorite driver here) ioctls are added... I could go on and on...
It used to be possible with kernel headers, but as many have pointed out kernel headers used by userspace have a lot of other problems.
So all I ask is a proposal to solve this problem within the context of the way we want things to work now. I think Matti pointed out some important issues which need to be addresses as well, wrt. inet6 support on glibc-2.0.x systems running 2.1.x kernels
Later, David S. Miller davem@dm.cobaltmicro.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |