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. -adrian _______________________________________________ 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"