Sharing code between kernel and userland....

Poul-Henning Kamp phk at phk.freebsd.dk
Wed Apr 9 02:39:55 PDT 2003


This is a problem I have hit before, and now I hit it again:  I need
to share a function between kernel and userland.

In the present case it is the endianess conversions for struct disklabel
which currently live in 

	src/sys/geom/geom_bsd.c
as 
	g_bsd_ledec_partition() & g_bsd_ledec_disklabel()

which now are needed in disklabel(8), libdisk and possibly other
places as well also.

The other partitioning formats will result in the same issue.

It is vitally important that there be no discrepancy between the kernel
and userland versions, so obviously they should share the same source
code.

We have a rule that it should be possible to compile the kernel
with only the src/sys tree, so obviously the source code should live
somewhere in src/sys, but the good question is: where and how ?

As I see these functions, they are library functions, and the library
is used both by userland and the kernel, but right now we have no
such library in our system.

We have a number of other bits of code which are in the same set
of circumstances, the sbuf stuff for instance and various bits in
libkern as well.

Amongst the options I see for avoiding code duplication are:

1.
	put it in sys/geom/bsdlabel_encode.c
	have libdisk pull it into userland from there.

2.
	put it in sys/libkern/disklabel.c
	have libdisk pull it from there.

3.
	put it in some more or less random place in the kernel
	have libdisk pull it from there.

4.
	use static __inline ... in <sys/disklabel.h>
	It is after all a rather trivial bit of code, but not quite
	trivial enough to make me comfortable with this.

What do people think ?

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


More information about the freebsd-arch mailing list