Date: Mon, 6 Feb 1995 10:59:11 -0500 (EST) From: "Jonathan M. Bresler" <jmb@kryten.atinc.com> To: hackers@FreeBSD.org Subject: Re: MIT SHM X11 extensions? (fwd) Message-ID: <Pine.3.89.9502061021.F3332-0100000@kryten.atinc.com>
next in thread | raw e-mail | index | archive | help
i need a person better versed in the kernel than myself to look at this explaination of why you dont want to 'cp' a running kernel. Jonathan M. Bresler jmb@kryten.atinc.com | Analysis & Technology, Inc. | 2341 Jeff Davis Hwy play go. | Arlington, VA 22202 ride bike. hack FreeBSD.--ah the good life | 703-418-2800 x346 ---------- Forwarded message ---------- Date: Sun, 5 Feb 1995 15:26:20 -0500 (EST) From: Jonathan M. Bresler <jmb@kryten.atinc.com> To: David O'Byrne <dave@odyssey.ucc.ie> Subject: Re: MIT SHM X11 extensions? On Sun, 5 Feb 1995, David O'Byrne wrote: > > > mv /386bsd /386bsd.alt <--- DO NOT USE 'cp' > > Hi Jonathan, sorry to pick you up an a small point on your recent post > to the list. But why is it important to use mv ? What goes wrong of I > use cp to back up the old kernel ? 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. think of it as arbitrary opcodes inserted into the kernel (unless you have the good forturn that the pages in both kernels are identical) dont ask where in the kernel/vm system this takes place. i have not dug into it. but that's what i understand to be the problem. jmb ps. okay, so you got my interest piqued. mv uses the rename() system call unlike cp. (actually mv can call cp to do the work, but only if the file is NOT a regular file (eg a directory, fifo...man 2 stat) rename is syscall 128. this system call is implemented in /sys/kern/vfs_syscalls.c:rename(). the work is done by the fucntion referenced by VOP_RENAME. this function is particular to each type of filesystem (shaking again). the vnode stores a pointer to a stucture of some 30 operations that are implemented for each filesystem type. (/sys/sys/vnode.h) the vnode associated with the file's data in memory/swap (i am on shaky ground here) is invalidated if the file is renamed (/sys/kern/vfs_cache.c:cache_purge()) so the crux of the matter must be the cache_purge call. learn something new everyday! thanks! jmb Jonathan M. Bresler jmb@kryten.atinc.com | Analysis & Technology, Inc. | 2341 Jeff Davis Hwy play go. | Arlington, VA 22202 ride bike. hack FreeBSD.--ah the good life | 703-418-2800 x346
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.3.89.9502061021.F3332-0100000>