From owner-freebsd-current@FreeBSD.ORG Tue May 27 21:28:23 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8CB4237B401 for ; Tue, 27 May 2003 21:28:23 -0700 (PDT) Received: from magic.adaptec.com (magic-mail.adaptec.com [208.236.45.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id E992143F85 for ; Tue, 27 May 2003 21:28:22 -0700 (PDT) (envelope-from scott_long@btc.adaptec.com) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id h4S4NiZ30354; Tue, 27 May 2003 21:23:44 -0700 Received: from btc.adaptec.com (hollin.btc.adaptec.com [10.100.253.56]) by redfish.adaptec.com (8.8.8p2+Sun/8.8.8) with ESMTP id VAA13803; Tue, 27 May 2003 21:28:02 -0700 (PDT) Message-ID: <3ED43A34.7020704@btc.adaptec.com> Date: Tue, 27 May 2003 22:25:24 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Q References: <200305281147.53271.doconnor@gsoft.com.au> <1054090968.1429.10.camel@boxster> <3ED4294B.4040108@btc.adaptec.com> <1054092793.1429.39.camel@boxster> <3ED4315F.8080709@btc.adaptec.com> <20030528040406.GA46917@basement.kutulu.org> <1054095955.1429.52.camel@boxster> In-Reply-To: <1054095955.1429.52.camel@boxster> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: Kernel module inconsistency was policy on GPL'd drivers? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2003 04:28:23 -0000 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 [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