From owner-svn-src-all@FreeBSD.ORG Wed Nov 6 20:53:53 2013 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D1815108 for ; Wed, 6 Nov 2013 20:53:53 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-pb0-x231.google.com (mail-pb0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9FE742D71 for ; Wed, 6 Nov 2013 20:53:53 +0000 (UTC) Received: by mail-pb0-f49.google.com with SMTP id um15so53391pbc.8 for ; Wed, 06 Nov 2013 12:53:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=SVwmfK5dzXA3PpQsfbKxRcHsNAeWSPjG1DjMg2g+GBM=; b=XmrpbfYsangXLD3BwUTlryoNqXq7mu0/8fz/zwISWaBEj6jdtV58Fc+Hr07KxJjGw1 EabIicCqg1DEzLiaVMIsg6jhF2fl7XJj9ppWTAq8H6AWwDizM8CMJldrCZ5KJ61OUmbX qki53XnxTzgINN2PWrtpYOv7XDy8EwSMlL8/0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=SVwmfK5dzXA3PpQsfbKxRcHsNAeWSPjG1DjMg2g+GBM=; b=QLEQLq/mZWAKVoPLyj0dLf7WVMBcM+Be4yV3dCdWh66//T5ahFmj7EdsseLMJeOsNH HoAW8j1TvHgA2fFhfNLi+eNVv3d56AcmCx4s5HNLVwd+PoHZH0TXzjrZiRJR8WycmfOw h/NzHscQgphhdGC9huGnlYj2Odt5L3id60YGS2iYe6To4ZFGWmWasM6/JiAEMKY5UUIL k58X4BWiJfTxMrSKV96COzKe/a0AyEN/ggsJ0ws5hpBW5Cw0RBNrb0WFjXmYcMsztnWV Gn/ZJk3s3mu7OKRusQ4NckPLqGq4ieFJkmMb6ThRusn4BX8vmE2gC3ahZ//GQsj9SjrX KIoQ== X-Gm-Message-State: ALoCoQn8JDPZoWE1Jc3SiN4vzFJqbJ9VIdbR8lo+LrADSxLUysS2U2DMVg3yd0w90DQDxzqBUrjF X-Received: by 10.68.253.129 with SMTP id aa1mr5157895pbd.189.1383771233039; Wed, 06 Nov 2013 12:53:53 -0800 (PST) Received: from hater-dm.corp.yahoo.com (nat-dip4.cfw-a-gci.corp.yahoo.com. [209.131.62.113]) by mx.google.com with ESMTPSA id xe9sm755429pab.0.2013.11.06.12.53.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Nov 2013 12:53:52 -0800 (PST) Message-ID: <527AAC5F.9040009@wemm.org> Date: Wed, 06 Nov 2013 12:53:51 -0800 From: Peter Wemm User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Gleb Smirnoff Subject: Re: svn commit: r257696 - in head: libexec/rbootd share/man/man9 sys/compat/svr4 sys/net sys/sys References: <201311051029.rA5ATmmM017799@svn.freebsd.org> <201311051156.09819.jhb@freebsd.org> <20131105192904.GG7577@FreeBSD.org> <20131106181956.GC7577@FreeBSD.org> In-Reply-To: <20131106181956.GC7577@FreeBSD.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "svn-src-head@freebsd.org" , svn-src-all , "src-committers@freebsd.org" , John Baldwin X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 20:53:53 -0000 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