Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 11 Sep 2000 16:49:35 +1100 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        Boris Popov <bp@butya.kz>
Cc:        freebsd-arch@FreeBSD.ORG
Subject:   Re: Shared kernel code
Message-ID:  <Pine.BSF.4.21.0009111610080.646-100000@besplex.bde.org>
In-Reply-To: <Pine.BSF.4.10.10009012148180.48047-100000@lion.butya.kz>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 1 Sep 2000, Boris Popov wrote:

I haven't seen any public replies to this.

> 	Currently I'm preparing smbfs bits for import into main tree.
> Since both nwfs and smbfs contains common parts I've tried to unify them
> in order to share code. Currently there are two common parts: kernel side
> of iconv library and encapsulation of mbuf management functions. Both can
> be statically compiled in the kernel or loaded as KLDs.
> 
> 	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.

> sys/lib directory which should be organized as src/lib directory. Eg:
> 
> 	sys/lib
> 		libiconv/
> 		libmbuf/
> 		etc...
> 
> 	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.

Bruce



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0009111610080.646-100000>