On 11/5/13, 2:18 PM, John Baldwin wrote:
On Tuesday, November 05, 2013 3:42:17 pm Gleb Smirnoff wrote:
John,
On Tue, Nov 05, 2013 at 02:47:52PM -0500, John Baldwin wrote:
J> On Tuesday, November 05, 2013 2:29:04 pm Gleb Smirnoff wrote:
J> > On Tue, Nov 05, 2013 at 11:56:09AM -0500, John Baldwin wrote:
J> > J> On Tuesday, November 05, 2013 5:29:48 am Gleb Smirnoff wrote:
J> > J> > Author: glebius
J> > J> > Date: Tue Nov 5 10:29:47 2013
J> > J> > New Revision: 257696
J> > J> > URL: http://svnweb.freebsd.org/changeset/base/257696
J> > J> >
J> > J> > Log:
J> > J> > Drop support for historic ioctls and also undefine them, so that
code
J> > J> > that checks their presence via ifdef, won't use them.
J> > J>
J> > J> Most of these are COMPAT_43, but one appears to be a 9.x ioctl? If
that's the
J> > J> case it's implementation should probably stick around under appropriate
J> > J> COMPAT_FREEBSD<x> macros. It looks like it goes all the way back to
4.4BSD,
J> > J> so at least COMPAT_FREEBSD4 and later should define the implementation
to
J> > J> preserve ABI compat for old binaries.
J> >
J> > Why should we support such broken configurations as running new kernel and
J> > ancient core base system utilities? The efforts to keep this are much more
J> > expensive, then yields.
J>
J> Is this ioctl only ever used by ifconfig and not suitable for public
consumption?
J> If so, then I think removing it is fine. However, it's not clear that this
is
J> the case from the commit, and it's good to make sure it is really the case.
J>
J> It might be nice to hide ioctls we think are internal under some #ifdef that
tools
J> like ifconfig #define to expose them so we are more explicit about which
ioctls
J> are purely internal, etc.
Well, it isn't hidden and actually some applications as zebra/quagga can use it.
On previous hacking session at this area, 2 years ago, I noticed that
zebra/quagga
do use SIOCAIFADDR and it actually does better at filling sockaddrs than our
ifconfig :)
I am pretty sure that no closed source, but available to wide public,
application
that configures addresses in FreeBSD kernel exist.
In case of open source applications, like zebra/quagga, supporting one major
release behind should be enough.
Mmmm, people run older versions of binaries (even open source ones) on newer
OS's
perhaps more often than you think. The COMPAT_43 stuff can be dropped
certainly,
but people will almost certainly do rolling upgrades where they upgrade the OS
on their machines before they upgrade their packages.
There are people running binaries back to the 2.x days I'm sure.
Personally every now and then I fire up a 1.1 jail and I'll be very
sad if I can't do that any more.
I don't expect ifconfig or netstat (or ps) to run, but it'd be a pitty
if standard 'apps' stopped working.
for a laugh you should time "make world" in such a jail..
it shows how much cost our progress comes at.
Certainly, I'd like to be able to compile and package freebsd 1 or 2
based systems for very small
embeded x86 based appliances..
some still exist..
_______________________________________________
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"
