Date: Tue, 5 Nov 2013 11:45:52 -0800 From: Adrian Chadd <adrian@freebsd.org> To: Gleb Smirnoff <glebius@freebsd.org> Cc: "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, John Baldwin <jhb@freebsd.org> Subject: Re: svn commit: r257696 - in head: libexec/rbootd share/man/man9 sys/compat/svr4 sys/net sys/sys Message-ID: <CAJ-VmokbLjP=OZEFf529uUfU_czyrhsMEGQxJRsVkTM_6ksaUA@mail.gmail.com> In-Reply-To: <20131105192904.GG7577@FreeBSD.org> References: <201311051029.rA5ATmmM017799@svn.freebsd.org> <201311051156.09819.jhb@freebsd.org> <20131105192904.GG7577@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Who says the only thing written out there that's old and would want a list of interfaces and interface configs via some legacy old ioctl API is ifconfig? -adrian On 5 November 2013 11:29, Gleb Smirnoff <glebius@freebsd.org> wrote: > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmokbLjP=OZEFf529uUfU_czyrhsMEGQxJRsVkTM_6ksaUA>