Date: Thu, 12 Feb 1998 14:38:44 +0100 From: Eivind Eklund <eivind@yes.no> To: Terry Lambert <tlambert@primenet.com>, Eivind Eklund <eivind@yes.no> Cc: current@FreeBSD.ORG Subject: Re: Heads up: static -ification Message-ID: <19980212143844.44164@follo.net> In-Reply-To: <199802100857.BAA22938@usr05.primenet.com>; from Terry Lambert on Tue, Feb 10, 1998 at 08:57:11AM %2B0000 References: <19980210030906.20113@follo.net> <199802100857.BAA22938@usr05.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980212143844.44164>