18.03.2006 21:45, Jesper Juhl wrote/a écrit:
On 3/18/06, Andrew Morton <[email protected]> wrote:
Thomas Gleixner <[email protected]> wrote:
On Sat, 2006-03-18 at 12:07 -0800, Andrew Morton wrote:
From my reading, 2.4's sys_setitimer() will normalise the incoming timeval
rather than rejecting it. And I think 2.6.13 did that too.
It would be bad of us to change this behaviour, even if that's what the
spec says we should do - because we can break existing applications.
So I think we're stuck with it - we should normalise and then accept such
timevals. And we should have a big comment explaining how we differ from
the spec, and why.
Hmm. How do you treat a negative value ?
In the same way as earlier kernels did!
Unless, of course, those kernels did something utterly insane. In that
case we'd need to have a little think.
If the change only affects buggy apps (as Thomas says), then it seems
completely obvious to me that the change should be made.
1. We'll be in compliance with the spec
2. Buggy applications will actually be helped by this by getting a
clear error instead of undefined behaviour silently hiding the fact
that they are buggy.
3. Correct applications are unaffected.
4. Applications written for an OS which respects the spec (and using
this particular rule) will finally work on Linux.
Well, I'd vote for just making Linux conform to the spec as soon as
someone notices a non-compliance. However, as this rule doesn't play
well with a stable ABI, a "trade-off" solution could consists in:
- Keeping the old behavior for now and generate a printk() each time
this code path is entered;
- Add an entry to feature-removal-schedule.txt saying Linux will start
conforming to the spec next year.
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]
