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:

> Why not. How is that different from _BSD_SOURCE, _POSIX_SOURCE etc.

The difference is that code compiled with these options can run on
other platforms while _LINUX_SOURCE would introduce stuff which again
leads back to the "good old time" where programs written on Linux only
run on Linux.

> 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.

Very simple. This is an option which is not available anywhere else.
Therefore something like

#ifndef SO_FILTER
printf ("sorry, not implemented");
#else
... use the stuff on Linux ...
#endif

is possible while with the method of duplicating the ways something
can be written you'll end up with

#ifdef __linux__
... do the work with 'llseek'
#elsif defined HAVE_LSEEK64
... do the work for systems with LFS ...
#endif

The actions for both are the same, it's only that when incompatible
interface are available they'll also will be used. If in this case on
Linux the llseek function is simply not available people are forced to
use the right way.

I think you've completely missed one of the threads of the last weeks.
People complained that Linux programs are so poorly portable. The
reaction from those who wrote these programs was that they didn't know
better since they don't have other machines to test.

This is exactly the point: you might know the differences between the
machines, but 80% of the Linux people do not and if there is a way in
which they can lead to write programs which "magicall" are portable
instead of Linux specific this is the way to go.

And I don't buy the argument about "breaking source code compatibility
now is evil". This only shows two things: you never looked at the bad
experiences of the industry where following a rotten design and
keeping backward compatibility lead to unusable systems. And second:
you only speak about the migration from libc5 to glibc. But this is
not what you get. You convert a libc5 specific program to a program
which can run on other Unix systems. And these changes in many cases
simply mean to remove Linux specific code which were necessary due to
the ad hoc design if libc4+5 (I don't blame HJ, this simply was a
consequence of the too fast and therefore uncontrollable development).

--
---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com `------------------------
-
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    [from the cache]
©2003-2011 Jasper Spaans