Date: Tue, 10 Feb 1998 08:57:11 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: eivind@yes.no (Eivind Eklund) Cc: tlambert@primenet.com, eivind@yes.no, current@FreeBSD.ORG Subject: Re: Heads up: static -ification Message-ID: <199802100857.BAA22938@usr05.primenet.com> In-Reply-To: <19980210030906.20113@follo.net> from "Eivind Eklund" at Feb 10, 98 03:09:06 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > Remember that functions and variables are exported interfaces in > > many cases. This includes user space uses for "ps", "w", "netstat", > > and so on, as well as kernel space uses. > > I know. I hope I didn't break any of them; the suspicion that I might > have was the reason for sending the heads-up in the first place. > > I though fixing this (the extreme spread of kernel symbols) was worth > the potential trouble. > > BTW: Speaking of symbol spread - you once gave a reference to the ld > manpage and implied that it was possible to create new object files > included a specific subset of the symbols from the original object > files. I tried to find out how to do this, as I wanted it both for > the kernel and for libalias, but I've spent quite some time without > finding out how to do it. Would you mind giving detailed > instructions? (Re-creating object files is easy, the problem is > controlling which symbols to include on a fine-grained basis). You should look at the man page again. Keep in hand a copy of the nm man page with reference to the "-g" option, and a copy of the modload source code. The modload source code works by linking an object (or ld -r'ed objects) against the kernel symbol table at a relative offset of zero to get the size of the resulting binary (aren't we lucky that the kernel is linked high? 8-)). Then space is allocated to contain the text and data, and the object is linked again, with the offest of the allocation. Finally, the data is pushed across the /usr/kernel boundry (at the time it was written, the cache was not unified, and kernel space mmap would not work; both that code, and all execution class loaders -- my name for ABI's when I originally released the LKM code, which I also wrote -- should be rewritten to use mmap()). > > For a potential kernel environment, you should be careful to not > > disallow dynamic replacement of kernel pieces using "generic" > > loadable modules (ie: if something is a function pointer, it > > should not be static'ed, unless there is an encapsulation function > > that can be used to modify its value, and then the encapsulation > > function should not be static). > > I think I may have broken one of these. I'll look through my patches > again. (I remember seeing something that looked like the above, and I > don't remember what I did with it. I just remember being in doubt.) If I don't miss my guess, this was either in the console code (World21 uses this to replace the console with an internalized console capable of displaying 21 different locales -- one at a time) or it's in the NFS lease function pointer management. Those are the two examples that spring to mind. If you can make sure when you build that the LKM's build as well, and then ld -A them against the kernel to see if there are unresolved externals (pretty easy). You may wish to explicitly contact binary driver vendors (like Dennis at ETINC), who may depend on unknown symbols. I definitely agree that the interfaces should be pruned, for what it's worth. I'm not quite to the point that I agree with the Linux/AIX or Microsoft link ".DEF" file approach to defining external interfaces to objects, but a directive to decide which symbol table in an ELF file, for instance, would probably be acceptable to everyone, especially if it were a macro wrapped storage class specifier or a #pragma of some kind (we will need these for marking things pageable and "non-load" for the kernel loader at some point, anyway). Once this is done, along with your other changes, then we will be a long way down the road of having a documentable DDI/DKI that we can stick with to get vendors to start writing binary drivers for their hardware for FreeBSD (I'm sure the aforementioned Dennis would be happy with this). A lot of problems like this come from subsystem exposure. Veto interfaces will definitely reduce the kernel symbol "footprint" of subsystems (my favorite hobby horse here is the VOP_ADVLOCK code in the FS's). Most of these are violations of the "downcalls only, no upcalls" rule that any beginning professional interface designer must know. In any case, keep up the good work; I only meant to caution you about the amount of exposure that was dependended upon; I in no way advocate it, nor do I hold it up as an example of "good engineering practice". ;-). In general, anything that links against libkvm is at risk, as far as user space goes. The "ps" and "vmstat" code are primary examples, since the symbols they reference aren't necessarily consumed directly without a bunch of arcane arguments to them on the command line. 8-(. You should be able to find the "at risk" programs by renaming and disabling the libkvm build, and doing a build world with make -i and then make -k (in case someone depends on something that isn't an explicit dependency). The output log should tell you where to look. The parameteric symbol uses are unfortunately the most complex to diagnose reliably. You may need to build shell scripts to exercise them individually. 8-(. 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 current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802100857.BAA22938>