On Tue, Nov 05, 2013 at 11:56:09AM -0500, John Baldwin wrote: J> On Tuesday, November 05, 2013 5:29:48 am Gleb Smirnoff wrote: J> > Author: glebius J> > Date: Tue Nov 5 10:29:47 2013 J> > New Revision: 257696 J> > URL: http://svnweb.freebsd.org/changeset/base/257696 J> > J> > Log: J> > Drop support for historic ioctls and also undefine them, so that code J> > that checks their presence via ifdef, won't use them. J> J> Most of these are COMPAT_43, but one appears to be a 9.x ioctl? If that's the J> case it's implementation should probably stick around under appropriate J> COMPAT_FREEBSD<x> macros. It looks like it goes all the way back to 4.4BSD, J> so at least COMPAT_FREEBSD4 and later should define the implementation to J> preserve ABI compat for old binaries.
Why should we support such broken configurations as running new kernel and ancient core base system utilities? The efforts to keep this are much more expensive, then yields. The only reason I see is to keep compat for the previous major version, since we guarantee only consequtive upgrades to a next major. If something goes wrong during upgrade a sysadmin can use old tools with new kernel. I agree on that, and when changing SIOCAIFADDR two years ago, I provided compatibility. But why the hell should we support an insane who will try to run ifconfig(8) from FreeBSD 4 on FreeBSD 11? Not speaking about this tool from 4.4BSD, LOL :) This is not what COMPAT_FREEBSD4 meant to be. If we claim to support that, then we must have an extensive set of unit tests, and every time we produce a release, we must ensure that the kernel is still compatible with ancient ifconfig(8), mount(8) and a dozen of oether tools. We don't do this, and I'm pretty sure that if we try, the unit tests will fail here and there. And to fix them, an enourmous efforts need to be made. And for what sake? For a very strange idea to run ancient *config or *ctl on modern kernel. I vote with both hands on keeping compatibility at generic syscalls layer, so that closed source, 3rd party, binary applications could run on newer systems. But not for the core system utilities, that configure our kernel and are shipped in the base system. Leaving all this compat cruft bloats the code, makes it difficult to understand. It weakens constraints on the input from userland. For example in 9.x ifconfig didn't fill in sockaddr structure correctly. Compat code even can bring security issues. If I was agressive enough 2 years ago to wipe SIOCSIFADDR entirely, then SA-13:12.ifioctl would not be applicable to 10.x and 11.x. -- Totus tuus, Glebius. _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
