lkml.org 
[lkml]   [1998]   [Jun]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: OFFTOPIC: e2fsprogs and +2Gb partitions
From
Date
alan@lxorguk.ukuu.org.uk (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
ftp.inr.ac.ru:/ip-routing).

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

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