From owner-freebsd-questions Fri Jan 24 4:45:52 2003 Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4CC8537B401 for ; Fri, 24 Jan 2003 04:45:50 -0800 (PST) Received: from splode.eterna.com.au (splode.eterna.com.au [203.15.111.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C46D43F13 for ; Fri, 24 Jan 2003 04:45:43 -0800 (PST) (envelope-from mrg@eterna.com.au) Received: from splode.eterna.com.au (localhost [127.0.0.1]) by splode.eterna.com.au (Postfix) with ESMTP id 0110292A0; Fri, 24 Jan 2003 23:45:25 +1100 (EST) To: Pavel Cahyna Cc: debian-bsd@lists.debian.org, freebsd-questions@FreeBSD.ORG subject: re: glibc vs BSD libc in-reply-to: your message of "Fri, 24 Jan 2003 11:20:15 BST." <20030124102015.GB8015@artax.karlin.mff.cuni.cz> organisation: people's front against (bozotic) www (softwar foundation) x-other-organisation: The NetBSD Foundation. Date: Fri, 24 Jan 2003 23:45:25 +1100 Message-ID: <27656.1043412325@splode.eterna.com.au> From: matthew green Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > when making such assertions it helps to be actually correct. while it > is true that *any* old binary may require COMPAT_XX options in the kernel, > netbsd supports binaries back to 386bsd for i386, with shorter periods > of backwards compat for the newer plaforms. i have personally run 386bsd > binaries on netbsd 1.5/i386. i just downloaded the netbsd/sparc 1.0 > /bin/sh and: > .... > i think you will find that netbsd cares _a whole lot_ about binary > compatibility. to claim otherwise is simply fallacy. Are you sure that running such old binaries doesn't require to have any COMPAT_ option? I remember a recommendation on current-users that if you upgrade your kernel before your userland, you should always compile the COMPAT_xxx option for your previous version. I also vaguely remember failure reports from people who forgot to do this. i never said that you don't need COMPAT_XXX options. infact, i said "is true that *any* old binary may require COMPAT_XX options in the kernel". however, these options are enabled by default so unless you actually take them out this isn't an issue. the advice you have gotten from current-users is good and valid. My statement of not caring about binary compatibility was wrong, sorry. What I wanted to say was that the binary interfaces become incompatible and compatibility is provided via COMPAT_ options in the kernel or by packages containing old versions of librairies. So I really don't think that it's possible to run an old binary against a new libc (at least, the sonames wold probably mismatch). Why would otherwise the compat packages in pkgsrc exist? Please correct me if I am wrong. the compat packages exist to provide missing libraries. the netbsd libc "soname" has never changed -- it was libc.so.12 when the first ELF port arrived, and it is libc.so.12 today. of course you can not use an ELF libc.so to run an a.out program. that's is what the compat packages provide - a.out libraries so that old programs work. however the a.out dynamic linker *is* provided by the system so given that all relevant libraries are available, dynamic netbsd programs will run back to when shared libraries were first introduced. BTW, I believe there are some programs that search the kernel memory directly for some data. Are ps and netstat examples of this? Can old versions of such programs be successfully used on a new kernel, even if the required COMPAT_ option is present? What about special ioctls, like SCSI commands sent directly from userland? ps(1) from netbsd 1.5 and above will work. programs like netstat and other "kmem"/"libkvm" grovellers may or may not work. it all depends on the relevant kernel structures not changing (too much?) kmem grovellers do not count as "portable programs" -- they do not use published API's to gather info, but assume a particular format about how the kernel stores things. netbsd has been moving away from kmem grovellers in a big way for two main reasons: the binary compat issue, and, most kmem grovellers are set-id to group kmem. removing both of these issues *is* a goal, but as i meantioned above, these sorts of programs don't "count" for backwards compatibility. for instance, the VM system was completely replaced in netbsd 1.4. no program that tries to grovel the old VM system could possibly work today -- those data structures don't exist and more and in many cases, they don't even have something comparable. SCSI commands sent directly from userland i would expect to work. the interface for doing this doesn't change, and the SCSI spec doesn't change one hopes.... does this clear it all up? [sorry for being so verbose] .mrg. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message