lkml.org 
[lkml]   [1999]   [Nov]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: vfork
acahalan@cs.uml.edu (Albert D. Cahalan)  wrote on 10.11.99 in <199911100713.CAA31619@jupiter.cs.uml.edu>:

> Andries Brouwer writes:
>
> > Linus writes:
> >
> > Just describe it the way it works.
> >
> > Yes, I did that further down the same page, describing the BSD vfork
> > and the reasons for it. But the POSIX description is what programmers
> > that wish to produce portable programs have to use. In a portable
> > program vfork only has disadvantages - strictly speaking it cannot be
> > used at all. Maybe I should add a separate LINUX DESCRIPTION.
>
> These are Linux man pages, are they not?

So?

When I look at a man page, *at least* 50% of the time I'd like to know if
this is in any way Linux specific (and if so, in what way), and what
exactly are the portable properties.

I may then decide to rely on non-portable properties, if those make a
significant difference to what I'm trying to do.

Or I may prefer to keep it portable.

In any case, to do that, I *MUST* know what the portable aspects are.

> 1. man pages should not rant about kernel design choices

True.

> 2. man pages should not encourage _or_ discourage portability

Misleading. They should *explain* portability insofar as it relates to the
manpage subject.

> Man pages exist to document the system. That is their primary function.
> It is also nice to document portability issues, but this is secondary.

False. Portability of system features *is* an important aspect of
documenting those features, just as much as pointing out related features
is (SEE ALSO).

> Those that wish to write portable software may purchase a copy
> of "Advanced Programming in the UNIX Environment" or POSIX itself.

I've done that. Neither tells more than half the story at best.

> > Hmm. Its cuts only one way: avoid vfork in a program that should
> > be portable.
>
> Being "portable" seems oddly like being "politically correct".

That is a seriously stupid comment. Especially given that political
correctness is actually highly *un*-portable.

> Being "portable" is relative. One may choose "all x86", "all BSD",
> "all 64-bit Linux", "all big-endian 32-bit SysV" or even "all Win32".
> To varying degree, most people don't give a damn. If you think you
> are an exception... does your software support v6 UNIX?

And how do you decide to do one or the other? Right ... you rely on
documentation that explains what doing so actually entails.

> > I will replace the word `broken' in the header.
> > (And maybe replace the entire page - will have to see what you wrote.)
> > But otherwise - are not all statements below factually correct?
>
> No, but there are gaping holes in the documentation. I'd most like
> to know what I can get from the raw system call, libc 5, recent glibc,
> and older glibc. For example, are file descriptors handled well?

Those are, of course, portability comments. (What, you didn't realize that
moving between raw syscalls, libc5, and various glibc versions, is also a
case of porting?)

> Since the POSIX version is so useless, you can just consider vfork() to
> be a Linux-specific call. On a modern Linux system, one may depend on
> quite a few things.

But then one might realize the hard way that portability even between
similar Linux versions suddenly becomes a problem.


MfG Kai

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.151 / U:0.756 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site