From owner-freebsd-current@FreeBSD.ORG Mon Nov 24 19:11:35 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 6B72E16A4CE for ; Mon, 24 Nov 2003 19:11:35 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E82843F3F for ; Mon, 24 Nov 2003 19:11:34 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) hAP3BTiF075917; Mon, 24 Nov 2003 19:11:29 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id hAP3BTCO075916; Mon, 24 Nov 2003 19:11:29 -0800 (PST) (envelope-from dillon) Date: Mon, 24 Nov 2003 19:11:29 -0800 (PST) From: Matthew Dillon Message-Id: <200311250311.hAP3BTCO075916@apollo.backplane.com> To: Peter Wemm References: <20031125025621.453732A8FC@canning.wemm.org> cc: freebsd-current@freebsd.org cc: "M. Warner Losh" Subject: Re: 40% slowdown with dynamic /bin/sh 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: Tue, 25 Nov 2003 03:11:35 -0000 :Ding! "Oh god, not another one!" *plonk* : :We need nsswitch type functionality in /bin/sh. To the people who want to :make it static, lets see some static binary dlopen() support or a nsswitch :proxy system. : :If half as much effort had been spent on implementing such a thing as there :has been hand wringing, then we'd have the best of both worlds by now. : :I'm sorry to sound harsh, but its the reality of the situation. Code :speaks louder than words. : :Cheers, :-Peter :-- :Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com :"All of this is for nothing if we don't go to the stars" - JMS/B5 You don't need dynamic loading to get nsswitch type functionality. You only need dynamic loading if nobody is willing to write an IPC model to get the functionality. It's really silly to create such a fundamental restriction on the binary because people are too lazy to build an IPC based mechanism. Not only silly, but it seems to me that it also creates security issues. At least with a client/server model it is possible to isolate the authentication code to, for example, disallow exec(), filesystem operations, or the opening of any new files. The other huge advantage that IPC has over DLL is that you can switchout the backend mechanisms on a running system without killing and restarting anything other then he one service you want to switch out, and if it doesn't work right you can restart the old one or keep live as a fallback. the IPC model is so much better then the DLL model for this sort of thing I don't understand why people are even arguing about it. And, of course, moving all of this junk out means that the libc implementation becomes a lot smaller... it just becomes an IPC interface and may be a small local cache rather then the full blown algorithm. The result? Static binaries become a lot smaller too (not that that is really a problem anyway). This 'it has to be static so dlopen works' argument is just not a good argument. It's really more of an excuse then an argument. If you really want to use dlopen then make it work with static binaries. If you want to do it right, develop an IPC model or use an existing IPC model. That said, an IPC model is precisely what I am developing for DragonFly (a 'money where your mouth is' response). :-) Right now I'm building it as a userspace library but I intend to move the rendezvous code directly into the kernel. Unix domain sockets are so icky(!). They work, but they are icky. I intend to use it for all resource and authentication lookups... password, group, services, pam equivalent, kerberos, resolver, and so on and so forth. Hell, I think I might use it for C locale too just to be able to rip locale out of libc. -Matt Matthew Dillon