From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 23:23:09 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6675737B401 for ; Fri, 25 Jul 2003 23:23:09 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id C50EC43FB1 for ; Fri, 25 Jul 2003 23:23:08 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfj2b.dialup.mindspring.com ([165.247.204.75] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19gISM-0006EE-00; Fri, 25 Jul 2003 23:23:03 -0700 Message-ID: <3F221E08.FAE1638C@mindspring.com> Date: Fri, 25 Jul 2003 23:22:00 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Shawn References: <000001c3521a$7fa912c0$6bd4bfac@AlHindawi> <1059139238.50681.0.camel@CPE-65-26-140-154.kc.rr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a436fb8f85d42f79d19b296c6cf14c1953a8438e0f32a48e08350badd9bab72f9c350badd9bab72f9c cc: freebsd-current@freebsd.org Subject: Re: Memory Mangement Problem in 5.1-RELEASE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2003 06:23:09 -0000 Shawn wrote: > On Fri, 2003-07-25 at 02:21, Terry Lambert wrote: > > You probably can't get away with the old gcc, since the binary > > format changed For No Good Reason(tm). > > Didn't the GNU people say they had to change it to be more ABI compliant > with the 'standard'? I will believe that when they upgrade their FORTRAN compiler to be more compliant with 'the standard'. Some standards are not worth complying with; I still have yet to see anyone tell me exactly what the practical benefit of doing this is. It's like the ELF standard instead of a.out; I was very much in favor of the change-over because it was supposed to let us have section attribution and multiple text and data segements that got loaded in the same executable. Is your FreeBSD kernel capable of defragging kernel memory to permit large contiguaous allocations for a device driver like the BT848 to happen well after boot time? Mine isn't. Is your FreeBSD kernel capable of dicarding the code and data for the probe routines that are not currently being executed and are not used in the common operational case? Mine isn't. Is your FreeBSD kernel capable of paging out any kernel page that's not in the paging path, so that if you, for example, have sound hardware and aren't using your sound driver, you have the ability to use the physical memory to instead open more sockets? Mine isn't. Is your FreeBSD kernel capable of loading *only* the probe code for a device, and, if it doesn't probe as being there, never loading the rest of the device driver and cotributing to KVA fragmentation? Mine isn't. Does your system have a libc.so linked against a libresolv.so that's totally seperate so that you can pull in new libraries from ISC whenever you need to do that the name lookups aren't serialized and make your Netscape slow? Mine doesn't. Is your entire system linked shared? Well, mine is. 8-). But it was under a.out, too. ELF promised a lot of things that never ended up having any practical value beyond what we already had with a.out, which was one BSS, one TEXT, and one DATA: just like before ELF. So what exactly is being promised by "being more standards compliant" in this particular instance? I can tell you what isn't: binaries are larger and compilation is slower than in previous releases; keeping up with GCC feels like running further and deeper into a swamp filled with molasses. Yeah, it's nice that we support 64 bit architectures (sorta) now, but that particular feature didn't need the binary format changed. Does anyone else ever suspect that some standards are written to cripple your competition, if they are stupid enough to fully comply with them? -- Terry