lkml.org 
[lkml]   [1998]   [Jun]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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

    \
     
     \ /
      Last update: 2005-03-22 13:43    [W:0.020 / U:397.560 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site