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

[Peter Wemm]

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