svn commit: r257696 - in head: libexec/rbootd share/man/man9 sys/compat/svr4 sys/net sys/sys

[Gleb Smirnoff]

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.