svn commit: r220755 - in head: . contrib/gcc/doc contrib/gcc/objc contrib/libobjc etc/mtree gnu/lib gnu/lib/libobjc gnu/usr.bin/cc gnu/usr.bin/cc/cc1obj gnu/usr.bin/cc/cc_tools gnu/usr.bin/cc/doc s...

[John Baldwin]

On Monday, April 18, 2011 4:02:10 pm Warner Losh wrote:
> 
> On Apr 18, 2011, at 12:48 PM, John Baldwin wrote:
> 
> > On Monday, April 18, 2011 1:06:42 pm Warner Losh wrote:
> >> 
> >> On Apr 18, 2011, at 1:01 AM, Roman Divacky wrote:
> >> 
> >>> please mark this in src/UPDATING, maybe bump freebsd_version too?
> >> 
> >> Please do not bump freebsd_version just for this.  Ports wishing to know can go off the last bump, if there are any.
> >> 
> >> Every freebsd_version bump forces rebuilding all modules and such and is a pita.
> > 
> > No, what it breaks is building a module with a newer source tree than your
> > running kernel and trying to kldload it.  That is never really supported,
> > but the kernel only notices when a version bump happens.  The real fix there
> > is to run a kernel + modules that are in sync on test boxes.
> 
> The problem is that this is a technical solution that precludes me from saying "look, I know that this will be OK, so let me do it"  I know 
nothing has changed that would cause a problem.
 
We could easily support some sort of cpp #define to disable the automatic
MODULE_DEPEND() on the kernel.  Then you could use

  'make DEBUG_FLAGS="-DDISABLE_KERNEL_VERSION"'

or whatever the variable is called when building your kernel modules.  You
could even have a DISABLE_KERNEL_VERSION make variable that adds that to
CFLAGS in bsd.kmod.mk and then set it to yes in your /etc/make.conf.

However, for normal users I think the precaution against loading an 8.x kld
on 7 is worth it.

-- 
John Baldwin