[lkml]   [1998]   [Jun]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: OFFTOPIC: e2fsprogs and +2Gb partitions
    Date (Alan Cox) writes:

    > > > You are without a doubt wrong to have not included as close to full
    > > > libc5 compatibility for -D_LINUX_SOURCE.
    > >
    > > Following this path would for ever manifested that software written on
    > > Linux is not portable. This always was wrong, all the hacks necessary
    > > to run software written are damaging. You certainly don't want to
    > > tell me that living with -D_LINUX_SOURCE is better than living without
    > > -D_LINUX_SOURCE after a phase of adaption, do you?
    > Why not. How is that different from _BSD_SOURCE, _POSIX_SOURCE etc. The
    > _blah_source exists because unlike you the standards committees are
    > aware of the cost of updating and maintaining software as well as the fact
    > that other standards do not always fully represent the capabilities of
    > the system itself.
    > Where for example do you fit Linux facilities like the SO_FILTER socket option
    > into your grand plan of standards. It has to be Linux specific code because
    > nobody else has borrowed our great plan yet.
    > The fact I can't take a random libc5 program and compile it with
    > -D_LINUX_SOURCE on the Linux OS with glibc is a flaw in glibc, probably one
    > of the biggest and most damaging flaws in glibc. Sure they day I have to port
    > that program off Linux I need to resolve things, but until then glibc is
    > costing people real time and money with a selective, poorly considered and
    > I feel misguided attitude to standards.

    One thing I would wish for a _LINUX_SOURCE would be the definition of
    the "linux standard" __u{64,32,16,8} / u{64,32,16,8} /
    s{64,32,16,8} / __s{64,32,16,8} typedefs.

    First there is a lot of code out there that uses these types, but the
    more important thing is that it allows to write kernel headers that can
    be easily included into glibc programs. With a few #ifdef __KERNEL__s many
    of the kernel includes could be made 'glibc-ready'

    No, copying all kernel includes into glibc is _not_ an option. It is a major
    pain when one is writing kernel test programs, or is trying to compile
    low level system utilities (e.g. try to compile iproute2 at

    No, switching the kernel code to C9x style type defines is not an option


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to

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