Messages in this thread | | | Date | Wed, 17 Jun 1998 12:54:12 +0200 | From | ak@muc ... | Subject | Re: OFFTOPIC: e2fsprogs and +2Gb partitions |
| |
On Wed, Jun 17, 1998 at 03:08:22AM +0200, David S. Miller wrote: > 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
In networking we already have separate directories for "internal" and "public" includes: include/net/ vs include/linux/. With a few exceptions (e.g. linux/skbuff.h) that cannot be easily fixed those are mostly ready for userspace.
With glibc we have some conflicts with user includes (e.g. netinet/ip.h and linux/tcp.h both define struct tcphdr), but I think it is reasonably to expect the user to not mix them (at least for 2.2, it would be nice if a more friendly solution could be found later)
The main obstacle of using linux/* networking file with glibc is that glibc sys/types.h does not define __u{8,16,32}. If that could be fixed sharing would be a lot easier.
-Andi
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |