On Sat, 2005-01-15 at 01:36 -0800, William Lee Irwin III wrote: >> We can easily do a "rolling upgrade" by adding new versions of the >> system calls, giving glibc and apps grace periods to adjust to them, >> and nuking the old versions in a few years.
On Sat, Jan 15, 2005 at 10:58:45AM +0100, Arjan van de Ven wrote: > but for 1: do we care? it is being more tolerant than allowed by a > standard. Those who care can easily add the test in the userspace > wrapper > for 2: we again are more tolerant and dtrt; again. And again userspace > wrapper can impose an additional restriction if it wants > 3 is more nasty and needs thinking; we could consider a fix inside the > kernel that actually does wait long enough > I don't see a valid reason to restrict/reject input that is accepted now > and dealt with reasonably because some standard says so (if you design a > new api, following the standard is nice of course). I don't see "doesn't > reject a condition that can reasonable be dealt with" as a good reason > to go double ABI at all. These are probably better reasons against fiddling with ABI shifts and against starting 2.7 for its sake than I could come up with. Thanks. -- wli - 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/
