From owner-freebsd-current Thu Feb 12 05:38:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA28281 for current-outgoing; Thu, 12 Feb 1998 05:38:52 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA28260 for ; Thu, 12 Feb 1998 05:38:48 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id NAA11467; Thu, 12 Feb 1998 13:38:46 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.6/8.8.6) id OAA20426; Thu, 12 Feb 1998 14:38:45 +0100 (MET) Message-ID: <19980212143844.44164@follo.net> Date: Thu, 12 Feb 1998 14:38:44 +0100 From: Eivind Eklund To: Terry Lambert , Eivind Eklund Cc: current@FreeBSD.ORG Subject: Re: Heads up: static -ification References: <19980210030906.20113@follo.net> <199802100857.BAA22938@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <199802100857.BAA22938@usr05.primenet.com>; from Terry Lambert on Tue, Feb 10, 1998 at 08:57:11AM +0000 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Feb 10, 1998 at 08:57:11AM +0000, Terry Lambert wrote: > > > 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 implied pointer to the LKMs made me discover the solution - just as I had discovered it by myself :-) symorder can be used to restrict symbols, too. I can't see anything else that does this job. And a simple reference to 'symorder' would have been all I needed. [... On what my staticization might have broken ...] > 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. It was some MIDI-stuff in VoxWare. And I don't think it was intended as an LKM hook. > You may wish to explicitly contact binary driver vendors (like Dennis > at ETINC), who may depend on unknown symbols. He hasn't complained yet... :-) > 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). The problem is that we have subsystems that share symbols internally, but shouldn't expose those symbols to the rest of the world. I'd like a hierarchical model where we the kernel is the top node of a tree, and each node in the tree have a defined exported interface, and all symbols not in that interface will be removed. Each node will be implemented as an object file, but might be constructed by re-linking subnodes through ld -r and a pass through symorder -c to zap non-wanted symbols. This has two good effects: (1) Limiting exposure of symbols as much as possible, so incestous relationships don't develop so easily. (2) Minimizing re-link time, as only the parts of the kernel that really has changed will be re-linked. OTOH, I think this might be too large a change for people to swallow. > 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). I'd like it, at least. I'm hacking drivers, too, though not usually sending it out as LKMs. > 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. I actually dislike the use of calls between layers at all (or at least in almost all cases). Layers should communicate through asynchronous messages; that way, you avoid a lot of stupid implict ordering assumptions. > 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". ;-). I actually think I've zapped all the variables that can turn static. The next stage would be to go for the module-variables, but that need a re-design of the kernel link process as outlined above. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe current" in the body of the message