Jamie Lokier <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
