From owner-freebsd-current Sun Jun 7 11:53:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA17709 for freebsd-current-outgoing; Sun, 7 Jun 1998 11:53:56 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA17701 for ; Sun, 7 Jun 1998 11:53:46 -0700 (PDT) (envelope-from jdp@austin.polstra.com) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.8/8.8.8) with ESMTP id LAA17184; Sun, 7 Jun 1998 11:52:38 -0700 (PDT) (envelope-from jdp) Message-Id: <199806071852.LAA17184@austin.polstra.com> To: Brian Somers cc: toj@gorillanet.gorilla.net, current@FreeBSD.ORG Subject: Re: IP Packet Aliasing Broke? In-reply-to: Your message of "Sun, 07 Jun 1998 11:46:30 BST." <199806071046.LAA00965@awfulhak.org> Date: Sun, 07 Jun 1998 11:52:38 -0700 From: John Polstra Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Now all we need is > > char *dlfind(const char *, int *major, int *minor) ... > Has anyone any objections to me implementing dlfind() ? Yes -- I object for several reasons. I'll save the biggest one for last. First, the dlfind() interface is too specific to the object format, for starters. ELF shared libraries have only major version numbers; they don't have minor versions. Second, when loading shared libraries programmatically using dlopen(), the established convention is that the shared library should simply be named "foo.so" without any version number. The installation process should make sure that the library (or a symlink to it) is installed in a location known to the application ("/usr/libdata/ppp/libalias.so"?). But really, why does ppp use dlopen to load libalias at all? Why not simply link it in like other libraries? I've heard the bloat-based arguments, but they look pretty bogus to me. Consider this: =============================================================================== $ ldd /usr/sbin/ppp /usr/sbin/ppp: -lutil.2 => /usr/lib/aout/libutil.so.2.2 (0x20043000) -lz.2 => /usr/lib/aout/libz.so.2.0 (0x20049000) -lcrypt.2 => /usr/lib/aout/libcrypt.so.2.0 (0x20055000) -ldes.3 => /usr/lib/aout/libdes.so.3.0 (0x2006a000) -lc.3 => /usr/lib/aout/libc.so.3.1 (0x20073000) $ size /usr/sbin/ppp /usr/lib/aout/libutil.so.2.2 /usr/lib/aout/libz.so.2.0 \ > /usr/lib/aout/libcrypt.so.2.0 /usr/lib/aout/libdes.so.3.0 \ > /usr/lib/aout/libc.so.3.1 text data bss dec hex 184320 4096 81228 269644 41d4c /usr/sbin/ppp 20480 4096 0 24576 6000 /usr/lib/aout/libutil.so.2.2 40960 4096 256 45312 b100 /usr/lib/aout/libz.so.2.0 12288 4096 68152 84536 14a38 /usr/lib/aout/libcrypt.so.2.0 32768 4096 0 36864 9000 /usr/lib/aout/libdes.so.3.0 425984 16384 53488 495856 790f0 /usr/lib/aout/libc.so.3.1 $ size /usr/lib/aout/libalias.so.2.5 text data bss dec hex 24576 4096 13140 41812 a354 =============================================================================== There's 934K of stuff loaded by ppp no matter what. (Or 518K if you don't count the text segment of libc, which to be fair would be in memory whether ppp needed it or not.) Why bother trying to save 41K for the cases where aliasing isn't needed? It just doesn't seem worth the bother to me. One other thing to keep in mind is that this whole /usr/lib/aout situation is only temporary. As soon as the ELF transition is finished, the libraries will be back in /usr/lib again. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message