Date: Thu, 24 Sep 1998 01:00:39 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: peter@netplex.com.au (Peter Wemm) Cc: tlambert@primenet.com, sthaug@nethelp.no, asmodai@wxs.nl, current@FreeBSD.ORG Subject: Re: DNS in CURRENT Message-ID: <199809240100.SAA16903@usr07.primenet.com> In-Reply-To: <199809230825.QAA13991@spinner.netplex.com.au> from "Peter Wemm" at Sep 23, 98 04:25:44 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> It would be simple if we could have libc.so.3 in /lib and ld-elf.so.1 on > the root fs somewhere. > > We can't dlopen() (easily) from static binaries yet. We need to weaken > the libc interfaces a little so that the decision about "which malloc" > (ie: the one linked statically into the executable, or the one in libc.so) > isn't made until runtime. Then, we could have a seperate resolver library > that was dlopened by libc, and libresolv.so.whatever would then link in > libc.so to get access to the missing functions, but everything will use > the functions that are presently linked into the static binary (eg: > malloc, stdio etc). glibc has done this (I think, but they might have > done it for different reasons (such as symbol versioning)). > > Then there's the issue of initializing rtld after the static program is > running.. Probably not out of the question, but not trivial I'd think. I think the way I'd want to handle this, given my druthers, is to have ld.so in /libexec. There is a gap between the end of the first page of the process vm space (which is unmapped), and the first page of the process itself in the process vm space. The purpose of this gap, and the reason that Linux fixed their ELF implementation to add this gap (they used to relocate to immediately after the first page) is to allow the kernel execution class loader for ELF images to map things into the process address space, whether the process wanted them mapped in or not. One thing that it's supposed to map in was ld.so. I believe on some systems, it also maps libc.so into this region (on the theory that "no one will ever build a libc so large it fills this gap"; yeah, right...). I would be happy with the map of the ld.so for all images. Alternately, we could use the crt0.o for shared linked images for all images, linked against shared libraries or not. > The neat thing is that we could even get away with something like PAM or > an extensible username / hostname system that doesn't require linking > everything into all the static binaries. Solaris already supports this for LDAP as part of the JINI framework, BTW... The have an nsswitch that includes all NIS+ fields, including the "Using LDAP as an NIS+ server" standards track RFC... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809240100.SAA16903>