From owner-freebsd-arch Sun Sep 10 23:42: 4 2000 Delivered-To: freebsd-arch@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id 68EA437B422 for ; Sun, 10 Sep 2000 23:41:58 -0700 (PDT) Received: by relay.butya.kz (Postfix, from userid 1000) id 1784D2876C; Mon, 11 Sep 2000 13:41:53 +0700 (ALMST) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id 0312228766; Mon, 11 Sep 2000 13:41:52 +0700 (ALMST) Date: Mon, 11 Sep 2000 13:41:52 +0700 (ALMST) From: Boris Popov To: Bruce Evans Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Shared kernel code In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 11 Sep 2000, Bruce Evans wrote: > > But there is an interesting question arises - where to put source > > code for those modules which don't represent any device and may consists > > from multiple source files ? > > > > Historically such files were placed in the kern and libkern > > directories. But it seems that both aren't suitable for newly added > > interfaces because of the flat name space. So, my suggestion is to create > > Why not? I like flat name spaces :-), or at least flat directory trees. Looks good for me if each set of files have a prefix. Eg, iconv_*, mbuf_* (sys/kern as example). > > Basically, sys/libkern also can be moved under lib directory. > > I think libkern as an actual library should be brought back. I made > linkern object files normal kernel object files 5 years ago to avoid > configuration and linkage complications, especially for modules. I > think libraries can now be handled reasonably by the kernel linker. > Use libkern.a (and possibly other libraries) in the usual way for > static linkage. This would result in unreferenced objects not being > linked into the kernel. Turn libkern.a into a module (libkern.ko) > to satisfy references from modules that aren't satisfied by the kernel > proper. Most modules would depend on libkern.ko. Use other modules > containing special purpose objects to avoid bloating libkern.ko. Agreed. I think ongoing Peter's work on KLDs will handle it very well. The only disadvantage is that libkern.ko will load all functions despite of the fact some of them already compiled statically. So, time for MODULE_VERSION(libkern, X) and MODULE_VERSION(kernel, X) :) -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message