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

[Peter Wemm]

On 11/6/13, 10:19 AM, Gleb Smirnoff wrote:
> On Wed, Nov 06, 2013 at 08:30:43AM -0800, Peter Wemm wrote:
> P> > Why should we support such broken configurations as running new kernel and
> P> > ancient core base system utilities? The efforts to keep this are much more
> P> > expensive, then yields.
> P> >
> P> Why? because up until now you could run a FreeBSD4 jail on a modern system
> P> and reasonably expect it to work.  No, we don't really "support" system
> P> level tools, but examining network state is widely used.  No, one doesn't
> P> run ifconfig to set interface configs in jails, but there's a lot of
> P> scripts to read the configuration.
> 
> Examining interface configs are done via getifaddrs(3), which uses NET_RT_IFLISTL
> sysctl, and this is not touched by this commit.

Sorry, getifaddrs(3) was a BSD addition. It is far from universally used.

eg:on a typical Linux, it has:

  CONFORMING TO
       getifaddrs(3) is not in POSIX.1-2001.  This function first
       appeared in BSDi and is present on some BSD systems, but with
       different semantics...

The highest common interface is SIOCGIF*.  I'm not talking about just
ifconfig(8), but also third party binary tools.

> P> > But why the hell should we support an insane who will try to run
> P> > ifconfig(8)
> P> > from FreeBSD 4 on FreeBSD 11? Not speaking about this tool from 4.4BSD,
> P> > LOL :)
> P> > This is not what COMPAT_FREEBSD4 meant to be.
> P> >
> P> 
> P> Insane? Perhaps, but it's keeping FreeBSD alive in a fairly large company I
> P> know of.  We'll have to locally revert this change, most likely, and spend
> P> time supporting it ourselves instead of doing other potentially more useful
> P> things to help FreeBSD in general.
> 
> I will not agree that an insane idea gets sane, if it is performed by a large
> company. "Large" doesn't mean "right". Can you please describe the scenario that
> may urge someone to run ifconfig(9) that is several major versions backwards
> on a modern kernel? What does prevent someone to install appropriate world, or
> at least ifconfig(8)?

We run old binaries in jails because that's what they were shipped with.
 For example, we had to implement the 32 bit freebsd-4 interface to
/dev/pci so that the 4.x 32 bit pciconf(8) runs.

One scenario is:  Scrape old FreeBSD-4.x machine.  Put it in a jail on a
current host.  That implicitly brings old binaries with it.

> May be it is worth to invest time into improving our upgrading technics? We've
> got freebsd-update(1). Doesn't it work for large companies? We have at minimum
> 2 years before 11.0-RELEASE will be released. We can invest time into upgrading
> technics, or into writing down compat layers.

We don't use anything that you'd recognize as a FreeBSD "release" so
freebsd-update(1) isn't interesting.  We use compat layers to keep the
old binaries running just well enough.  Unfortunately for us, we have to
go a bit further than regular freebsd because we need to keep a
selection of system level tools running that can examine system state.
eg: a 12 year old pciconf(8) binary so that it can list the pci devices
present.

> If you can explain what can prevent
> someone to upgrade ifconfig, but to push kernel to 11.0, then we could work
> on it. May be we should fix these obstacles on the upgrade path, instead of
> layering one compat layer over another?

All that we need is for ancient 4.x binaries to keep running that *read*
interface state.  Stuff that was compiled years ago by people who no
longer work at the company and we have no way to reproduce.  That's what
things like COMPAT_FREEBSD4 etc is for.  We have some commercial 3.x and
4.x binary "things" that will never be updated.

> Ok, if you need to, you can just revert commit right here in FreeBSD svn, I
> will not start a commit war. I am already very close to abandon idea on cleaning
> network stack, since this work is very very ungrateful.

There is no need for that, we'll just re-implement the COMPAT_* that was
removed in our tree at work, as needed.  I just suspect that since some
9.x binaries are affected by the compat removal that more people than
just us will be affected.

-Peter