svn commit: r257696 - in head: libexec/rbootd share/man/man9 sys/compat/svr4 sys/net sys/sys
Peter Wemm
peter at wemm.org
Wed Nov 6 00:34:46 UTC 2013
On 11/5/13, 4:15 PM, Peter Wemm wrote:
> 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.
>>
> This change is actually even worse than it appears. One of the key
> features that was removed was the workaround for code that doesn't
> know about sockaddr.sa_len.
>
> eg: /usr/sbin/traceroute after the change:
> # traceroute www.freebsd.org
> traceroute: ifaddrlist: SIOCGIFADDR: bge0: Can't assign requested address
>
> Hint: linux doesn't have a sa_len, so code that originates on Linux
> will no longer work. The code glebius removed used to work around this.
>
> This is not old binaries, this is binaries compiled *today*.
>
I may have to take this back. I mis-read the removed code for
SIOCSIFADDR etc that had the sa_len emulation in it. I might be hitting
a bug in r257692 ("rewrite in_control").
I will check and report back. My apologies for potentially jumping the
gun on this.
-Peter
More information about the svn-src-all
mailing list