Messages in this thread | | | Date | Fri, 16 Dec 2005 17:00:21 +0000 | From | Jamie Lokier <> | Subject | Re: [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/
| |