lkml.org 
[lkml]   [1998]   [Jun]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: OFFTOPIC: e2fsprogs and +2Gb partitions
    On Sat, Jun 13, 1998 at 08:03:21PM +0200, Ulrich Drepper wrote:
    > ak@muc.de writes:
    >
    > > The __ variants are 100% name space clean.
    >
    > It's safe in the way they do not violate standards. But these names
    > are far to common (since too short) to not be used in other
    > situations.

    So don't define _LINUX_SOURCE then.

    >
    > > If they're all ifdefed with _LINUX_SOURCE then the name space
    > > problem is moot anyways - _GNU_SOURCE adds name space polution,
    > > _BSD_SOURCE adds name space pollution - why is Linux so special?
    >
    > I'm tired of repeating this on and on
    >
    > > I think this is a bad hack. Do you really want to duplicate kernel includes
    > > in all kinds of packages? This gives bad source control problems and makes
    > > extending the kernel very difficult .
    >
    > Talk to Linus about this. His intention is to have no user-level code
    > using kernel headers and I agree. This also means that very special
    > headers (like the filesystem headers) will have to come with the
    > package which need them.

    This is a very bad idea. If he said this he is just misguided.

    Maybe he doesn't need to fix nettools when they break..



    >
    > > And there exists a large body of code that uses these types, if you like
    > > it or not. And sometimes we need to write Linux specific code, simply because
    > > Linux has some interfaces that don't exist on other systems (for example
    > > the netlink interface, the SO_FILTER extension Alan pointed out etc. etc.)
    >
    > You miss the point. System specific code must be written, sure. But
    > system specific code in the libraries is wrong since it makes these
    > definitions appear as the way to go when writing a program.

    Exactly, it must be writen. But currently much of this code can't be writen
    with glibc, but one has to revert to libc5.

    Do you really advocate duplication of kernel includes as a good solution here?

    I think it would be much more profitable and generally a better solution
    if we allowed sharing of specific includes between glibc programs and the
    kernel as painless as possible.

    I understand that this won't work for all includes because of the different
    glibc ABI. It would be nice if it was possible to make the kernel includes
    glibc friendly with a minimal amount of #ifdefs. I'm willing to do this work
    for the network headers I'm interested in (and possible others).

    But glibc needs to add some support for this too. The __uXXX/__sXXX types
    are definitely needed. They are there and won't go away any time soon.

    >
    > And by the way: what number of programs (and what percantage) do we
    > talk about? These are mainly problems for programs which are close to
    > the kernel and written by the same people who wrote the kernel stuff.
    > Of course you've used the same names etc which I fully can understand
    > for a first implementation. But ince the programs are released to the
    > world these problems should have been fixed and since the nubmer is
    > quite low there is no such problem.

    Fixed == duplicating the kernel includes into the program source? For me
    this is not a mess, this is just generating a hard to maintain mess for
    dubious gains.

    -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.051 / U:1.312 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site