Kernel module inconsistency was policy on GPL'd drivers?

You could achieve the same result without breaking a bunch of cardinal
rules by taking an MD5 hash of the kernel when the port is first
installed, then modify the rc.d script that loads the module to only run
if that MD5 hash matches the current kernel. If a mismatch occurs it
should spew out an error saying the port should be reinstalled.

This would most definitely work, although I'm not sure if this is the
best way of resolving the issue in the longer term.

Seeya...Q

On Wed, 2003-05-28 at 14:04, Michael Edenfield wrote:
> * Scott Long <scott_long_at_btc.adaptec.com> [030527 23:51]:
> 
> > >I am thinking of ports like rtc, ltmdm or Vmware here.. where it is not
> > >uncommon that they require reinstalling after an upgrade. I have
> > >experienced kernel panics on several occasions from out of date vmware
> > >kernel modules.
> > 
> > I'm really of the opinion that these ports should either live in the
> > sys/ tree, or that magic should be devised to make sure that they are
> > built along with the rest of the modules.
> 
> Wouldn't it be sufficient to simply install the port modules into 
> /boot/kernel instead of /usr/local/wherever/it/goes/now?  I 
> understand why most aren't put there now, due to the seperation of 
> base system from ports etc.  But I would the benefits of violating 
> that principle outweigh the detriments: each time you reinstall your 
> kernel, /boot/kernel is moved out of the way... taking all the 
> outdated modules with it.  Your port modules would fail to load, not 
> being in the right place, but that's far better than a panic.
> 
> --Mike