From owner-freebsd-hackers Mon Feb 6 15:01:43 1995 Return-Path: hackers-owner Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id PAA24050 for hackers-outgoing; Mon, 6 Feb 1995 15:01:43 -0800 Received: from Root.COM (implode.Root.COM [198.145.90.1]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id PAA24044 for ; Mon, 6 Feb 1995 15:01:40 -0800 Received: from corbin.Root.COM (corbin.Root.COM [198.145.90.18]) by Root.COM (8.6.8/8.6.5) with ESMTP id PAA27475; Mon, 6 Feb 1995 15:01:33 -0800 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.9/8.6.5) with SMTP id PAA00617; Mon, 6 Feb 1995 15:01:33 -0800 Message-Id: <199502062301.PAA00617@corbin.Root.COM> X-Authentication-Warning: corbin.Root.COM: Host localhost didn't use HELO protocol To: "Jonathan M. Bresler" cc: hackers@FreeBSD.org Subject: Re: MIT SHM X11 extensions? (fwd) In-reply-to: Your message of "Mon, 06 Feb 95 10:59:11 EST." From: David Greenman Reply-To: davidg@Root.COM Date: Mon, 06 Feb 1995 15:01:27 -0800 Sender: hackers-owner@FreeBSD.org Precedence: bulk > 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