From: "Michael Kerrisk" <email@example.com> To: Linus Torvalds <firstname.lastname@example.org> Cc: email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org Subject: Re: unhare() interface design questions and man page Date: Thu, 2 Mar 2006 05:48:44 +0100 (MET) Message-ID: <email@example.com> (raw) In-Reply-To: <Pine.LNX.firstname.lastname@example.org> Linus, > On Thu, 2 Mar 2006, Michael Kerrisk wrote: > > > >>>>> > > > >>>>> That is, CLONE_FS, CLONE_FILES, and CLONE_VM *reverse* the > > > >>>>> effects of the clone() flags of the same name, but CLONE_NEWNS > > > >>>>> *has the same meaning* as the clone() flag of the same name. > > Well, if this is the only problem, who cares? CLONE_NEWNS itself is > actually a reversal of clone flags: unlike the others, that tell to > _share_ things that normally aren't shared across a fork(), CLONE_NEWNS > does the opposite: it asks to unshare something that normally is shared. > > So the fact that it then acts not as a reversal when doing "unshare()" > is > actually consistent with the fact that it's a already a "unshare" event > for clone() itself. I care about this from an (kernel-userland) *interface* point of view. I see a small but steady stream of unnecessarily confusing interfaces going into the kernel-userland interface; the problem is that no-one (or not enough people) seem to really care about this. The key point is this: if it looks like a duck, I expect it to behave like a duck. When interfaces have the same name, then users expect the interfaces to provide the same behaviour. Now with unshare() we have the situation that a set of flags with the same name reverses the corresponding flags for clone(). From an interface design point of view that might almost be okay. But one flag breaks the pattern: CLONE_NEWNS, does the same thing in both clone() and unshare(). Inflicting this sort of messiness on userland is a recipe for programmer confusion, with bugs and security holes in userland programs as the possible result. If you agree that that is a possible result, then why not avoid the possibility? It does not cost much to do so. > > Do you have any further response on this point? > > (There was none in your last message?) > > I personally don't think it's worth makign UNSHARE_NEWNS just because > it's > a flag that acts differently from the other CLONE_xxx flags. See my comments above. (And in case it wasn't clear, I meant make a complete set of UNSHARE_* flags that mirror the corresponding CLONE_* flags.) > As to whether allow or not allow unknown unshare() flags, I don't think > it's a huge deal either way. Right now we don't check the flags to > "clone()" either, I think. No checking in clone() was probably a mistake (now difficult to rectify because it could break bad userland apps). Is that past mistake a rationale for making the same mistake in future interfaces? Without checks such as I've described, the kernel is not providing ABI stability (i.e., if some bit that was meaningless in the past acquires a meaning in later kernels, then (older) application behaviour arbitrarily and unexpectedly changes. Why does that possibility not matter? Making the change I suggest would help userland programmers. What is the cost of making it? (i.e., is there some good reason not to do it?) 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 index Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <200602072059.k17KxJUI016348@shell0.pdx.osdl.net> 2006-02-13 22:10 ` Michael Kerrisk 2006-02-14 13:44 ` JANAK DESAI 2006-02-14 18:49 ` Michael Kerrisk 2006-02-14 20:47 ` JANAK DESAI 2006-02-16 5:50 ` Michael Kerrisk 2006-02-19 17:52 ` Janak Desai 2006-03-02 3:31 ` Michael Kerrisk 2006-03-02 4:03 ` Linus Torvalds 2006-03-02 4:48 ` Michael Kerrisk [this message] 2006-03-02 21:40 ` Michael Kerrisk
Reply instructions: You may reply publically 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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /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
LKML Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \ firstname.lastname@example.org public-inbox-index lkml Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git