Re: [patch 1/2] Validate itimer timeval from userspace

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mar 18, 2006, at 18:14:02, Eric Piel wrote:
18.03.2006 21:45, Jesper Juhl wrote/a écrit:
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.

I think Eric brings up a good point. Perhaps we should rename feature-removal-schedule.txt to future-abi-changes.txt and start including other kinds of predicted future ABI changes and incompatibilities. For example the sysfs class API changes which are planned are not feature removals but API changes, and as such could be usefully mentioned and tentatively assigned a date of implementation. Something like that wouldn't add a _lot_ of extra work, but would help developers more carefully consider the extent of all their ABI changes.

Cheers,
Kyle Moffett

-
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]
  Powered by Linux