Re: compat code function pointers

[David Holland <dholland-tech%netbsd.org@localhost>]

On Sun, Mar 18, 2018 at 09:00:06PM -0400, Christos Zoulas wrote:
 > Paul and I have been working towards separating the compat code from the
 > main kernel and eliminating all the COMPAT_XX ifdefs. This will allow
 > the compat modules to work properly even if the kernel is not compiled
 > with the compat options.
 > 
 > The general approach to this is to move all the compat code out of the
 > main kernel leaving behind function pointers that typically point to
 > noops (enosys) that the compat code can then repoint to the compat code
 > functions when it loads (and re-point them to noops when it unloads).
 > 
 > The question came up where to store the function pointers for device
 > drivers that are not always present in the kernel. We could use weak
 > references in the compat code so that the code links, but the kernel
 > linker does not currently support weak pointers. Another alternative
 > is to create a file in the kernel that contains those function pointers.
 > 
 > Paul suggested:
 > 
 > 	src/sys/kern/kern_junk.c
 > 	src/sys/sys/kern_junk.h
 > 
 > I suggested:
 > 
 > 	src/sys/kern/kern_compat.c
 > 	src/sys/sys/compat.h
 > 
 > Opinions?

compat_stubs.h?

But, if this is for drivers that have internal compat logic, do we
really want to spew the innards into src/sys/sys? Wouldn't it be
better to give such drivers their own compat modules so the
abstractions are preserved? (And for things where there are ioctls
that changed in a bunch of drivers, improve the ioctl handling so
compat ioctls don't need to appear in drivers ever?)

also I'm not sure adding a ton of new spectre gadgets is really the
best plan...

-- 
David A. Holland
dholland%netbsd.org@localhost