This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Clean up glibc manual references to "GNU system" (bug 6911)
On Sat, 18 Feb 2012, Alfred M. Szmidt wrote:
> How about using the term "the GNU system" to encompase both GNU/Hurd,
> GNU/Linux, GNU/kFreeBSD, and when something is specific to the Hurd or
> Linux explictly say so? For example,
My patch did leave "the GNU system" used for cases intending to cover both
GNU/Linux and GNU/Hurd. But I get the impression that the general
preference would be to avoid that term completely, and instead refer to
the "GNU C Library" for something describing a pure library property
independent of the system, "GNU/Linux and GNU/Hurd" for something covering
both but possibly not other variants (e.g. a description of a kernel error
number from a function), etc.
> +++ b/manual/conf.texi
> @@ -1190,7 +1190,7 @@ represents the maximum length of a file name string. It is defined in
>
> Unlike @code{PATH_MAX}, this macro is defined even if there is no actual
> limit imposed. In such a case, its value is typically a very large
> -number. @strong{This is always the case on the GNU system.}
> +number. @strong{This is always the case on the GNU/Hurd system.}
>
> @strong{Usage Note:} Don't use @code{FILENAME_MAX} as the size of an
> array in which to store a file name! You can't possibly make an array
>
> Could be worded as follows instead,
>
> This is always the case on systems running the Hurd.
There's some logic in that - except that the comparable wording "This is
always the case on systems running Linux" would probably be objected to;
if it did specifically describe a kernel property, referring at length to
"systems running the Linux kernel" would probably be preferred by the FSF.
And given that the primary function of the manual is to describe the GNU C
Library and systems using it, not non-GNU systems with the Linux kernel
(such as Android), I'd be inclined to refer to the glibc-based systems as
GNU/Linux, GNU/Hurd etc. (encompassing both the C library and the kernel
or other pieces involved in some of the behavior of C library functions)
rather than try to deal with systems using the Linux kernel with another C
library, or hypothetical other libraries with the GNU Hurd.
> That would make it clearer than refering to GNU/Hurd, GNU/Linux, or
> debating what the GNU system really is.
Given the complications of how many functions are not purely kernel or
purely library functionality (even functions that used to be pure syscalls
with the Linux kernel may now be wrappers on newer architectures using the
"generic" syscall interface), I think it's probably better to refer to the
combinations such as GNU/Linux rather than try to separate out whether a
particular point is purely a kernel one.
--
Joseph S. Myers
joseph@codesourcery.com