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.204 / U:0.840 seconds]
©2003-2014 Jasper Spaans. Advertise on this site