Kernel module inconsistency was policy on GPL'd drivers?

[Scott Long]

Q wrote:
> 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.
> 

Don't forget that some modules need to be loaded at boot time.  Also, if 
I recompile my kernel to trim down an unused driver, the MD5 will
change.....

Scott

> 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