Date: 28 May 2003 15:20:02 +1000 From: Q <q_dolan@yahoo.com.au> To: Scott Long <scott_long@btc.adaptec.com> Cc: freebsd-current@freebsd.org Subject: Re: Kernel module inconsistency was policy on GPL'd drivers? Message-ID: <1054099201.31549.71.camel@boxster> In-Reply-To: <3ED43A34.7020704@btc.adaptec.com> References: <C90CF9CA-9040-11D7-941E-0003937E39E0@mac.com> <200305281147.53271.doconnor@gsoft.com.au> <3ED4294B.4040108@btc.adaptec.com><3ED4315F.8080709@btc.adaptec.com> <20030528040406.GA46917@basement.kutulu.org> <3ED43A34.7020704@btc.adaptec.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Yes, I'm aware of the implications.. I was merely proposing a "ports legal" way of achieving the same result that Mike put forward without stuffing a foreign module into /boot. Although, like I said, this is not really a long term solution to the problem. All the port's originating kernel modules I am aware of use /usr/local/etc/rc.d scripts to load the module, and would therefore work with my suggested approach. If you manually loaded it using /boot/loader.conf you would need to put the module into /boot/kernel anyway, which would get moved out the next time you installed a new kernel. I guess the real question is which is more acceptable to the average user. Reinstalling a couple of ports each time you install a new kernel, or risking a kernel panic by not doing it? Obviously it would be better if you only needed to reinstall something only IF it was really required, but unless their is some alternative way of knowing this before loading the module it's hard to determine when that might be without causing a kernel panic. Seeya...Q On Wed, 2003-05-28 at 14:25, Scott Long wrote: > 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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1054099201.31549.71.camel>