lkml.org 
[lkml]   [2005]   [Dec]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH -mm 1/9] unshare system call: system call handler function
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?

-- Jamie
-
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/

\
 
 \ /
  Last update: 2005-12-16 18:08    [W:0.053 / U:0.968 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site