From: "Michael Kerrisk" <mtk-manpages@gmx.net>
To: Linus Torvalds <torvalds@osdl.org>
Cc: akpm@osdl.org, ebiederm@xmission.com,
linux-kernel@vger.kernel.org, janak@us.ibm.com,
viro@ftp.linux.org.uk, hch@lst.de, ak@muc.de, paulus@samba.org,
mtk-manpages@gmx.net
Subject: Re: [PATCH] unshare: Cleanup up the sys_unshare interface before we are committed.
Date: Fri, 17 Mar 2006 21:27:49 +0100 (MET) [thread overview]
Message-ID: <31796.1142627269@www086.gmx.net> (raw)
In-Reply-To: <Pine.LNX.4.64.0603162140190.3618@g5.osdl.org>
Linus,
> On Fri, 17 Mar 2006, Michael Kerrisk wrote:
> >
> > > - it's all the same issues that clone() has
> >
> > At the moment, but possibly not in the future (if one day
> > usnhare() needs a flag that has no analogue in clone()).
>
> I don't believe that.
>
> If we have something we might want to unshare, that implies by definition
> that it was something we wanted to conditionally share in the first
> place.
>
> IOW, it ends up being something that would be a clone() flag.
I should have been a little clearer. I was thinking of
some orthogonal flag that would change the operation of unshare()
itself (i.e., not some resource that was unshared, but something
that changes how unshare() goes about its job). It
would not make sense to call such a flag CLONE_xxx.
> So I really do believe that there is a fundamental 1:1 between the flags.
> They aren't just "similar". They are very fundamentally about the same
> thing, and giving two different names to the same thing is CONFUSING.
This is your viewpoint ;-). Actually, it cuts through to the
crux of the matter:
The existing flags are *about* the same fundamental things,
but they *treat* those things in subtly different ways.
I believe that sentence summarises how our viewpoints differ,
and explains why you think the names should be the *same*,
while I think they should better be just *similar*.
As I said in an earlier message, when I wrote my test program
I found myself getting confused about how CLONE_NEWNS worked,
even though I had just drafted a manual page that clearly
told me that CLONE_NEWNS did not reverse the clone() of the
same name. I was CONFUSED. (That's a "fact" ;-).)
Maybe that is just a demonstration of the obvious: I'm not
the sharpest tack in the box. But my feeling is that part
of my confusion *arose from the naming of the flags*, and
some others will be like me. This is my belief
about the two possible alternatives:
a) Flags with names that are *similar but not the same*
(CLONE_* vs UNSHARE_*) will give userland programmers what I
think is the right clue about the reality: these flags are
working with the same things, but treating them somewhat
differently.
b) The flags have the *same* names. This will lead *some*
programmers into thinking that the correspondence
between the flags is *exact*. But that is not so.
I believe that the first possibility is less likely to lead to
traps (bugs) based on false understanding. It also fits better
with the possibility of a hypothetical "orthogonal unshare()
flag".
Of course, I can construct a counterargument: some
programmers will be smarter than me, and the ones who are
like me will at least have my manual page to help them avoid
trouble. Nevertheless, my gut feel is that the status quo is
an example of weak user interface design which could bear
improvement.
Cheers,
Michael
--
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7
Want to help with man page maintenance?
Grab the latest tarball at
ftp://ftp.win.tue.nl/pub/linux-local/manpages/,
read the HOWTOHELP file and grep the source
files for 'FIXME'.
next prev parent reply other threads:[~2006-03-17 20:27 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1359.1142546753@www064.gmx.net>
2006-03-16 23:34 ` Michael Kerrisk
2006-03-16 23:57 ` Linus Torvalds
2006-03-17 1:11 ` Michael Kerrisk
2006-03-17 5:42 ` Linus Torvalds
2006-03-17 16:04 ` Eric W. Biederman
2006-03-17 16:49 ` Janak Desai
2006-03-17 20:27 ` Michael Kerrisk [this message]
2006-03-18 18:41 ` Eric W. Biederman
2006-03-18 19:54 ` Janak Desai
2006-03-19 13:58 ` Eric W. Biederman
2006-03-18 23:41 ` Paul Mackerras
2006-03-20 4:45 Albert Cahalan
2006-03-20 16:52 ` Eric W. Biederman
-- strict thread matches above, loose matches on Subject: below --
2006-03-16 16:49 Eric W. Biederman
2006-03-16 19:40 ` Michael Kerrisk
2006-03-16 20:33 ` Andrew Morton
2006-03-16 20:41 ` Linus Torvalds
2006-03-16 21:58 ` Eric W. Biederman
2006-03-16 22:19 ` Andrew Morton
2006-03-16 21:36 ` Janak Desai
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=31796.1142627269@www086.gmx.net \
--to=mtk-manpages@gmx.net \
--cc=ak@muc.de \
--cc=akpm@osdl.org \
--cc=ebiederm@xmission.com \
--cc=hch@lst.de \
--cc=janak@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulus@samba.org \
--cc=torvalds@osdl.org \
--cc=viro@ftp.linux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®