On Fri, Jun 16, 2006 at 06:37:02PM +0000, Thomas E. Spanjaard wrote:
> Christos Zoulas wrote:
> >Still you have to do the ugly symbol renames to avoid symbol collisions
> >to make lkms work standalone, without depending on others.
>=20
> Can't you ease that by using macros to define any exported symbol=20
> instead of regular C code? Of course, a potential LKM would need to use=
=20
> those for function signatures etc. instead of the usual ones, but you=20
> could provide for an #ifdef _KERNEL for instance when it's compiled in=20
> to create 'regular' symbols.

	ugh.  That's horrible.  Right now it only takes a little bit of glue
to pick up basically any bit of kernel code and turn it into a LKM.  (which,
incidentally, I started working on making config be able to generate, but
then ran into ENOTIME)  Having to rewrite the code to wrap all the functions
in macros just woouldn't be workable.

	I vaguely remember thinking that the solution to a lot of the symbol
collisions, at least when you're talking about common shared function that
two LKMs might need, is to make the LKM more fine grained.  So, if you've
got the linux emul lkm, and a freebsd emul lkm, and they both use emul_find=
(),
rather than having emul_find() included in linux_lkm.o and freebsd_lkm.o,=
=20
you have a emul_lkm.o that gets loaded first.  Of course, doing so only
really becomes feasable when you can do something as simple as a
	echo "options COMPAT_LINUX" | config -b . - && make
to build any piece of the kernel.

eric