lkml.org 
[lkml]   [2006]   [Mar]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [patch 1/2] Validate itimer timeval from userspace
Date
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 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/

\
 
 \ /
  Last update: 2006-03-19 10:00    [W:3.961 / U:0.220 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site