Date: Tue, 26 Nov 1996 17:39:01 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: guido@gvr.win.tue.nl (Guido van Rooij) Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@freebsd.org, kjk1@ukc.ac.uk Subject: Re: A simple way to crash your system. Message-ID: <199611270039.RAA26124@phaeton.artisoft.com> In-Reply-To: <199611262049.VAA18493@gvr.win.tue.nl> from "Guido van Rooij" at Nov 26, 96 09:49:20 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Altough I am speculating here, I think this has to do with the fact that > > > I do not have msdosfs compiled in with the kernel. After installing a > > > different kernel, I asked the system to modload msdosfs, with the above > > > result. > > > > Running a kernel with the wrong LKMs is known to cause you grey hairs. > > I'm often falling into this trap, but the other way around: by > > rebooting a new kernel without rebuilding and reinstalling the LKMs > > first. > > Can't we built in some way of detecting that an lkm is for the wrong kernel? > If things are so dependant, why not take the uname -a string as an > identifier.... How about moving the relocator and the symbol space into kmem, like I just suggested? Then it would "just work", always, with no more version mismatches (unless you lie about the size of struct proc or something, and it should be an abstract type anyway). Worse comes to worse, you put a version number in the header (I made provision for one in the code anyway) and you bump it when you change the "kernel consumer" interface (ie: size of proc struct, etc.). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611270039.RAA26124>