Date: Wed, 06 Nov 2013 12:53:51 -0800 From: Peter Wemm <peter@wemm.org> To: Gleb Smirnoff <glebius@FreeBSD.org> Cc: "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, John Baldwin <jhb@freebsd.org> Subject: Re: svn commit: r257696 - in head: libexec/rbootd share/man/man9 sys/compat/svr4 sys/net sys/sys Message-ID: <527AAC5F.9040009@wemm.org> In-Reply-To: <20131106181956.GC7577@FreeBSD.org> References: <201311051029.rA5ATmmM017799@svn.freebsd.org> <201311051156.09819.jhb@freebsd.org> <20131105192904.GG7577@FreeBSD.org> <CAGE5yCryiEotSqLfjq-oJrfVuqY5j-o2qXb-AZztR1=pZBz=Rg@mail.gmail.com> <20131106181956.GC7577@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?527AAC5F.9040009>