Date: Mon, 31 Mar 1997 19:26:44 -0800 From: John Polstra <jdp@polstra.com> To: phk@critter.dk.tfs.com Cc: current@freebsd.org Subject: Re: A new Kernel Module System Message-ID: <199704010326.TAA24955@austin.polstra.com> In-Reply-To: <27686.859838573@critter> References: <27686.859838573@critter>
next in thread | previous in thread | raw e-mail | index | archive | help
PHK wrote: > Question: If we stick the linker in the kernel, doesn't it mean that > we could use it for shlibs too ? > > Basically the dl* functions could be made syscalls couldn't they ? > > That would be way faster than mmap'ing ld.so all the time... Part of it could be put into the kernel, I suppose. But some of the things it does, such as dealing with ld.so.hints and LD_LIBRARY_PATH, and searching for shared libraries, seem to me like they don't belong in the kernel. When I worked on speeding up ld.so some time ago, I set up a "not quite profiling" system for measuring how much time was spent doing various things inside the dynamic linker. Mmapping it seemed to take a negligible portion of the time. Most of the time was spent in the actual linking, i.e., doing relocations and binding symbol definitions and references. (I was able to get speedups of up to a factor of three just by improving the symbol lookup code.) These tasks are strictly computational, and putting them in the kernel is unlikely to make any difference. If you want to avoid the overhead of mmapping ld.so all the time, SVR4 had a good idea. There, the dynamic linker is a part of libc. By mapping the dynamic linker, you also get libc for free. Since libc is used by every program, it's a win. The downside is that the coupling between ld.so versions and libc versions becomes much tighter. On a different but related subject ... Maybe nobody's confused about this, but just in case: The kernel modules (new LKMs) do not have to be PIC. They can just as well be plain object files, and they probably should be. PIC is only needed when the same object is going to be mapped simultaneously into several different processes at potentially different addresses. PIC doesn't eliminate the need for relocation; it just isolates all the position-dependent information in the data segment. Since each kernel module will be mapped at most once into the kernel, there's no need to make it PIC. It should probably not be PIC, because of the substantial performance penalty that PIC adds. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704010326.TAA24955>