In article
<OFB68D40CB.B0CAE212-ON88257019.002B61C8-88257019.002C0A18@xxxxxxxxxx> (at Tue,
7 Jun 2005 01:01:01 -0700), David Stevens <dlstevens@xxxxxxxxxx> says:
> Ok, but this gets back to my point. If the program source
> doesn't have #ifdefs like you suggested (for example, if
> it was written before the new API existed), then it'll still
> have an error, but that error won't show up until the next
> time it's recompiled. So, an old binary will work fine, but
> recompiling it will get EINVAL on the setsockopt() calls.
> The old binary will work, the old source will compile, but
> the new binary will not work, and may not be found until
> much later.
It is okay, we can warn that "you use old API; please fix that!"
or something like that.
(like SO_BSDCOMPAT or, neigh.XXX.base_reachable_time sysctl.)
> I think it's better to break and fix any use of these
> right away instead of delaying the error until the next
> time some old binary is recompiled and run, don't you?
No, I don't think so. Please do NOT break binary API in 2.6.x.
I think it is okay in 2.7, but I still think that it is
good to use new values for new semantics.
--yoshfuji
|