On Wednesday, November 06, 2013 12:48:36 pm Peter Wemm wrote: > 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.
I think removing COMPAT_43 is a separate issue from removing what should be under COMPAT_FREEBSD9. I doubt much of anything is using COMPAT_43 ioctls, but there are likely things using the older version of the still-current ioctl that would need to be under COMPAT_FREEBSD[4-9]. -- John Baldwin _______________________________________________ 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"