From owner-freebsd-net@FreeBSD.ORG Tue Sep 6 03:07:29 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B85FE106566C for ; Tue, 6 Sep 2011 03:07:29 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.freebsd.org (Postfix) with ESMTP id 2F13F8FC0A for ; Tue, 6 Sep 2011 03:07:22 +0000 (UTC) Received: from c122-106-165-191.carlnfd1.nsw.optusnet.com.au (c122-106-165-191.carlnfd1.nsw.optusnet.com.au [122.106.165.191]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p8637Kes004380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Sep 2011 13:07:21 +1000 Date: Tue, 6 Sep 2011 13:07:20 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Arnaud Lacombe In-Reply-To: Message-ID: <20110906121821.I3398@besplex.bde.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, Adrian Chadd , "K. Macy" Subject: Re: No IPFW binary compat across versions ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 03:07:29 -0000 On Mon, 5 Sep 2011, Arnaud Lacombe wrote: > On Mon, Sep 5, 2011 at 7:50 PM, Adrian Chadd wrote: >> That's not what the COMPAT_* hooks are for. >> >> They're for backwards compatibility of normal userland binaries, not >> binaries which use a FreeBSD-specific kernel ABI. >> > What do you define as "normal" and where do you draw the line ? It's hard to say, and probably undocumented, but system-y programs should be the only unnormal ones. Until about 10 years ago, anything using kinfo broke every other day with a binary change to struct kinfo_proc, but this was mostly fixed so kinfo only breaks every couple of major releases. Using sysctls instead of kmem significantly increased the portability of statistics utilities like systat and netstat, so they only break across every 1 and a half major releases (new features don't work of course). I run kernels between FreeBSD-4 and FreeBSD-9-current-6-months ago under a FreeBSD-5 userland with only the following changes: - hack signal handling for FreeBSD-4 compatibility in otherwise FreeBSD-5 userland. - static linkage throughout (except in ports, which are mostly not not even installed except under FreeBSD-5 (FreeBSD-4 ports)). No dll hell. - scripts to select a working binary. E.g., for ps: % #!/bin/sh % % case "$(uname -m)-$(uname -r)" in % amd64-8.*-*) p=/c/tmp/rela/;; % i386-9.*-*) p=/c/tmp/rel9/;; % i386-8.*-*) p=/c/tmp/relc/;; % i386-[6-7].*-*) p=/c/tmp/rel6/;; % *) p=/;; % esac % exec "$p"bin/ps "$@" I only need a few binaries to work on all kernels, and add a script like the above, or lines to an old script as necessary. The above shows the FreeBSD-6 ps working for FreeBSD-5 and FreeBSD-7 on i386 and ps only needed under FreeBSD-8 for amd64. My list of system-scripts is: % atacontrol % bsdtar # not really system-y; minor portability problems % fdisk % fstat % ifconfig % kdump % killall % mdconfig % mount # mostly not needed, and also not used for mounting root % mount_msdosfs # all mount utils mostly not needed, and never should be % mount_ntfs % netstat # this breaks too often % nfsstat % pmccontrol # FreeBSD-5 doesn't even have pmc % pmcstat # but pmc changed within major releases and I only have old vers % ps % pstat % rpc.lockd % systat # surprisingly binary-compatible (same binaries for 6-7 and 8-9) % top # as binary-compatible as systat % vmstat # even more binary-compatible (6 binary for i386 works on 6-9) % w >> From my point of view, I should be able to run a FreeBSD 9.0 kernel > (when released) on top of a FreeBSD 5 userland without such issues. > That's what backward compatibility is. _Every_ piece of the ABI > exposed by the kernel[0] should be kept compatible, even funky > behavior userland might ends up relying on. Keeping the ABI compatible is not easy, and mostly wasn't attempted except for simple syscalls in FreeBSD until about 10 years ago. /etc/rc.d stuff tends to be a bit broken. No new features anyway. I mostly use FreeBSD >5 in my amd64 laptop which could use some new features, but I avoid some problems by not using any special power saving kernel or userland features on it at all. This laptop mostly gets used for benchmarking new kernels and libm. It nfs-mounts /c from an i386 FreeBSD-5 system, and gets some amd64 binaries from there. (I should use i386 binaries nfs/mounted from the FreeBSD-5 system more, but haven't investigated this. Only much the same system-y binaries should have a machine-dependence that stops the i386 version from working.) > [0]: ... with very few exception, such are security issue when there > is no other choices available. My old userland must have many security problems. Bruce