Date: Tue, 1 Apr 1997 11:35:50 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jdp@polstra.com (John Polstra) Cc: phk@critter.dk.tfs.com, current@freebsd.org Subject: Re: A new Kernel Module System Message-ID: <199704011835.LAA11731@phaeton.artisoft.com> In-Reply-To: <199704010326.TAA24955@austin.polstra.com> from "John Polstra" at Mar 31, 97 07:26:44 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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. The ld.so.hints stuff is trivial, assuming that there is a corrected implementation of kernel level file I/O for it to use to do the dirty deed. The LD_LIBRARY_PATH (like variant symlinks, which are always coming up) is more of a problem in the implementation of process environment space than it is a real issue. The child process created will inherit the parent's value, and at the exec, the envp will be "visibile" to the kernel. The child process can't set it's own path to use in running itself, after all, because of where in crt0 this all happens (before _main is called). 8-). > 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. Except for image size, when the code is removed from the crt0 startup code. There are also a number of possible compatability issues which "drop out" when this is done. For instance, in another thread of this discussion, the SVR4 EABI mapping of ld.so and libc, which should be done by our execution class loader for ABI compatability anyway. > 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. Yes; this is not a necessary/sufficient condition on mapping the ld.so; we could still map both of them, and get libc; as you said, the mapping is the least of the issues. One big issue, IMO, is that the symbol munging can be made to "go away", so long as you sort the vtable contents, and call by vtable offset. This assumes a vtable implementation very much like that used by Microsoft, actually -- a win in general, if we wish to be able to consume commercially produced "component-ware". > 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. Yes. My reference to PIC was relative. If the modules were required to be truly PIC in the current scheme of things, one link would suffice at base address 0, and then the image of the module could be loaded at the allocated space without a relink; clearly, this isn't a real possibility for module stacking, since the relocation offsets of the data need to be patched, and subsequent links would get the data relocated to the wrong address. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704011835.LAA11731>