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.
-adrian
the important thing for me is the ability to run *old jails*.
such jails already require a special 'ps' for example (taken from a
new /rescue)
but there are apps that do special things for which new binaries are
not available.
typical case:
freebsd user company in 1996: "Hey vendor can we have a binary of
your "x" app for freebsd? Just compile your 'sun' version on a
freebsd machine",
vendor: "ok it'll take some time but we'll try it out.."
5 years later:
vendor: "we never sold more than 2 of these on FreeBSD so we are
discontinuing support.."
10 years later:
user company: "thank god this still runs with the compat-4 option"
2014: "shit we're screwed" :-)
OR
"The binaries for this still run thank god, since we lost all the
sources when mumble's machine crashed."
_______________________________________________
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"
