On 11/6/13, 9:00 AM, Adrian Chadd wrote:
I think the important thing here is that there _are_ organisations
that rely on some reasonable attempt at supporting historical APIs
where needed.
This IMHO should've explicitly gone into a compat macro for people who
want support of this older stuff.
My suggestion for a saner way to handle this deprecation schedule:
* do the announce - I'd have to go looking for that, but we should be
placing these somewhere obvious (like a wiki page that lists
deprecated APIs in order, with the date/release they're going to be
deprecated);
* deprecate the userland use of the ioctl values first so they use the
newer API;
* deprecate the kernel API after the announced amount of time, hiding
things behind COMPAT_xxx as appropriate.
That's how it was before - behind COMPAT_43 etc and he removed it.
COMPAT_43 now does less than it did before.
There were a bunch of ioctl's that had been renamed ages ago with an O
prefix that were exposed to userland. While they weren't part of any
API they should probably have been #ifdef COMPAT_43 in the includes to
avoid accidental use. However, things like ktrace/kdump/strace wanted
access to them for decoding so it would have made the change even messier.
-Peter
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
