Sharing code between kernel and userland....

[Julian Elischer]

I prefer option 4
either a macro or an inline

Note that fsck uses macros from the kernel ufs includes.
So there is a precedent.

On Wed, 9 Apr 2003, Poul-Henning Kamp wrote:

> 
> 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.
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
>