Date: Mon, 06 Feb 1995 15:01:27 -0800 From: David Greenman <davidg@Root.COM> To: "Jonathan M. Bresler" <jmb@kryten.atinc.com> Cc: hackers@FreeBSD.org Subject: Re: MIT SHM X11 extensions? (fwd) Message-ID: <199502062301.PAA00617@corbin.Root.COM> In-Reply-To: Your message of "Mon, 06 Feb 95 10:59:11 EST." <Pine.3.89.9502061021.F3332-0100000@kryten.atinc.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> mv breaks the connection between the pathname "/386bsd" and the >kernel process in memory. cp does not. most of the time this doesnt >matter. but if the kernel (virtual memory system) decides to get kernel >pages from disk or swap, after you put the new kernel into "/" and before >the reboot (of course ;), then the memory image gets hammered. best you >can hope for is a panic. worst, it just starts doing gawd-knows what >with your system. The kernel binary is NOT paged. It is read in entirely by the boot code and always remains completely memory resident. Further, Terry's assertion that the binary's vnode has the VTEXT flag turned on (and thus prevents you from overwriting it [ETXTBUSY]) is also WRONG. It does NOT do this, and as such it is perfectly okay to clobber your binary. BEWARE, however, that if you load an LKM the system will link it using the symbols from the NEW binary which of course are completely bogus and will cause your machine to die. Also, things that attempt to read the kernel namelist for other reasons (like ps) will likely stop working until you reboot with the new kernel. So in summary, if you replace your kernel with cp kernel /, be sure to reboot shortly after doing that. -DG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199502062301.PAA00617>