Date: Fri, 13 Feb 1998 00:44:02 +0100 From: Eivind Eklund <eivind@yes.no> To: Terry Lambert <tlambert@primenet.com> Cc: current@FreeBSD.ORG Subject: Re: Heads up: static -ification Message-ID: <19980213004401.13104@follo.net> In-Reply-To: <199802122311.QAA04342@usr02.primenet.com>; from Terry Lambert on Thu, Feb 12, 1998 at 11:11:45PM %2B0000 References: <19980212143844.44164@follo.net> <199802122311.QAA04342@usr02.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Feb 12, 1998 at 11:11:45PM +0000, Terry Lambert wrote: > > 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. > > It wants the kernel build tree reorganized on module boundries. This isn't a necessity, though it would be nice. See below for details. > As an aside, so does multiple architecture support. > > As another aside, filesystems want to be in /sys/fs instead of spread > all over the source tree at random locations. > > So a source tree reorganization is due. As a first step on this, could you help me try to define which files ought to belong in which module? You can see the start of one of my attempts in the patch at http://freefall.freebsd.org/~eivind/module-link.patch which goes against a config'ed LINT from today's current; as you can see, it tend to show a lot of exposure, and possibly not match the module boundaries too well :-( If the basic idea here seems feasible, I was thinking along the lines of an extra file for config(8) with a syntax somewhat like makefiles, but with allowed symbols replacing the shell commands of a regular makefile. Could I ask you another favour, too? Can you look over the proposal I sent to -hackers about a week ago under the subject "Proposal for IPFW interface change, w/potentially larger application"? It is basically a system for building binary objects in kernel space from userland by starting with a default and modifying it; it should allow the IPFW interface to be upgraded without breaking binary compatibility. I wasn't able to solicit _any_ feedback on this :-( I have three potential levels for it: (1) IPFW interface only, with the above benefits (2) Generalized kernel interface for building and retrieving objects this way; would allow us to kill most of kmem dragons fairly easily. (3) Generalized object and capability buildning system. Would allow us to view ipfw as a routing capability, and would allow a lot of other capability manipulation (including port access limitations and file system access limitations for child processes). and I desperately need feedback on what (if any) of this people think would be useful, and in what direction to target my implementation (which I need for work purposes). 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?19980213004401.13104>