To: Jamie Lokier <jamie@shareable.org>
Cc: JANAK DESAI <janak@us.ibm.com>, viro@ftp.linux.org.uk, chrisw@osdl.org,
       dwmw2@infradead.org, serue@us.ibm.com, mingo@elte.hu,
       linuxram@us.ibm.com, jmorris@namei.org, sds@tycho.nsa.gov,
       akpm@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH -mm 1/9] unshare system call: system call handler
 function
References: <1134513959.11972.167.camel@hobbs.atlanta.ibm.com>
	<m1k6e687e2.fsf@ebiederm.dsl.xmission.com>
	<43A1D435.5060602@us.ibm.com>
	<m1d5jy83nr.fsf@ebiederm.dsl.xmission.com>
	<43A24362.6000602@us.ibm.com>
	<20051216105048.GA32305@mail.shareable.org>
	<m1wti56wgw.fsf@ebiederm.dsl.xmission.com>
	<20051216170021.GA12495@mail.shareable.org>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Fri, 16 Dec 2005 19:23:33 -0700
In-Reply-To: <20051216170021.GA12495@mail.shareable.org> (Jamie Lokier's
 message of "Fri, 16 Dec 2005 17:00:21 +0000")
Message-ID: <m1slss797e.fsf@ebiederm.dsl.xmission.com>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1409
Lines: 33

Jamie Lokier <jamie@shareable.org> writes:

> Eric W. Biederman wrote:
>> > Like clone(), unshare() will have to change from year to year, as new
>> > flags are added.  It would be good if the default behaviour of 0 bits
>> > to unshare() also did the right thing, so that programs compiled in
>> > 2006 still function as expected in 2010.  Hmm, this
>> > forward-compatibility does not look pretty.
>> 
>> Why all it requires is that whenever someone updates clone they update
>> unshare.  Given the tiniest bit of refactoring we should be
>> able to share all of the interesting code paths.
>
> That only works if unshare() should always mean "unshare everything
> except specified things", including things that we currently don't
> unshare.
>
> I guess that is probably fine.  Anything that would break
> unshare()-using programs in future if it unshared by default, would be
> likely to break clone()-using programs too.  Is that right?  Any
> counterexamples?

The only way I can see to confuse unshare is to add a clone
flag and not implement it in unshare.    If there is enough
in common between the implementations I don't see that being
a problem.

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