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 <gleb...@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. _______________________________________________ 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"
