All of lore.kernel.org
 help / color / mirror / Atom feed
From: walter harms <wharms-fPG8STNUNVg@public.gmane.org>
To: "Michael Kerrisk (man-pages)"
	<mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: CLONE_FILES description confusing
Date: Mon, 05 Sep 2016 20:10:23 +0200	[thread overview]
Message-ID: <57CDB50F.4070201@bfs.de> (raw)
In-Reply-To: <63e31345-ccb2-22c8-4584-62fb32db7d96-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>



Am 28.08.2016 06:43, schrieb Michael Kerrisk (man-pages):
> On 08/27/2016 11:07 PM, walter harms wrote:
>>
>>
>> Am 24.08.2016 02:11, schrieb enh:
>>> On Tue, Aug 23, 2016 at 4:52 PM, Michael Kerrisk (man-pages)
>>> <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>> Hello Elliott
>>>>

>>
>>
>> Just one note:
>> People are terrible bad at negation. So i would suggest:
>>
>> If  CLONE_FILES  is  set, the child process share
>> all file descriptors opened in the calling  process
>> at the time of clone().
>> Subsequent operations that open or close file descriptors,
>> or change  file  descriptor  flags, performed  by  either
>> the  calling  process  or  the child
>> process do also affect the other  process.
>>  Note,  however,
>>  that  the duplicated file descriptors in the child refer to
>>  the same open file descriptions as the  corresponding  file
>>  descriptors  in  the  calling  process, and thus share file
>>  offsets and files status flags (see open(2)).
> 
> Hi Walter,
> 
> I am having trouble to see what you find wrong, and what you want to change,
> since the text comparison is difficult. Could you formulate this as a patch?
> 
> Thanks,
> 
> Michael
> 
>  

Most people are bad at negations. The patch attempts to reword the
description of the CLONE_FILES without describing "what is not does
when not set".

This changes not the whole file but it should give an idea how it could be done.

re,
 wh


----

diff --git a/man2/clone.2 b/man2/clone.2
index b867961..fd25e38 100644
--- a/man2/clone.2
+++ b/man2/clone.2
@@ -172,6 +172,17 @@ Store the child thread ID at the location
 in the child's memory.
 .TP
 .BR CLONE_FILES " (since Linux 2.0)"
+
+By default the child process still inherits a copy of all file descriptors
+opened in the calling process at the time of
+.BR clone ().
+The child and parent process can close or change
+file descriptors independently.
+The duplicated file descriptors in the child refer to the same open file
+descriptions as the corresponding file descriptors in the calling process,
+and thus share file offsets and files status flags (see
+.BR open (2)).
+
 If
 .B CLONE_FILES
 is set, the calling process and the child process share the same file
@@ -187,20 +198,6 @@ If a process sharing a file descriptor table calls
 .BR execve (2),
 its file descriptor table is duplicated (unshared).

-If
-.B CLONE_FILES
-is not set, the child process inherits a copy of all file descriptors
-opened in the calling process at the time of
-.BR clone ().
-Subsequent operations that open or close file descriptors,
-or change file descriptor flags,
-performed by either the calling
-process or the child process do not affect the other process.
-Note, however,
-that the duplicated file descriptors in the child refer to the same open file
-descriptions as the corresponding file descriptors in the calling process,
-and thus share file offsets and files status flags (see
-.BR open (2)).
 .TP
 .BR CLONE_FS " (since Linux 2.0)"
 If

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

      parent reply	other threads:[~2016-09-05 18:10 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-23 22:19 CLONE_FILES description confusing enh
     [not found] ` <CAJgzZopmS1ph4G4zMu-_chLjsyE4CLnZiuOPqXBC=vdUE9R96w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-08-23 23:52   ` Michael Kerrisk (man-pages)
     [not found]     ` <e9dc2d61-4d72-32f4-3fb7-8864dd575f32-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-08-24  0:11       ` enh
     [not found]         ` <CAJgzZor_Ru3TJfjA0L9PFo7r+2asCD+BxW=GAgmdFHY_UR2Gag-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-08-27 11:07           ` walter harms
     [not found]             ` <57C17454.80707-fPG8STNUNVg@public.gmane.org>
2016-08-28  4:43               ` Michael Kerrisk (man-pages)
     [not found]                 ` <63e31345-ccb2-22c8-4584-62fb32db7d96-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-09-05 18:10                   ` walter harms [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=57CDB50F.4070201@bfs.de \
    --to=wharms-fpg8stnunvg@public.gmane.org \
    --cc=linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.