From owner-freebsd-stable@FreeBSD.ORG Tue Nov 13 06:31:18 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3184416A419 for ; Tue, 13 Nov 2007 06:31:18 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 7DB6D13C48D for ; Tue, 13 Nov 2007 06:31:16 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: (qmail invoked by alias); 13 Nov 2007 06:30:48 -0000 Received: from nat-wh-1.rz.uni-karlsruhe.de (EHLO mobileKamikaze.norad) [129.13.72.169] by mail.gmx.net (mp044) with SMTP; 13 Nov 2007 07:30:48 +0100 X-Authenticated: #5465401 X-Provags-ID: V01U2FsdGVkX18ZM4c9V0cZj2lSVhNPYeWP+f/UVR0ahDhB1O8U5c fIhRCqGG9SShLN Message-ID: <47394497.8000802@gmx.de> Date: Tue, 13 Nov 2007 07:30:47 +0100 From: "[LoN]Kamikaze" User-Agent: Thunderbird 2.0.0.6 (X11/20071101) MIME-Version: 1.0 To: Adrian Chadd References: <20071102095628.GA796@0lsen.net> <472AF94B.1020600@gmx.de> <20071104200325.T91647@fledge.watson.org> <20071104211009.GC20861@0lsen.net> <4736BB24.8010905@gmx.de> In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: freebsd-stable@freebsd.org, Clint Olsen Subject: Re: Source upgrade from 5.5 to 6.X not safe? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2007 06:31:18 -0000 Adrian Chadd wrote: > On 11/11/2007, [LoN]Kamikaze wrote: >> If a binary/library that is currently used gets removed/replaced, it will be >> copied to memory. The process will not even recognize this. Only restarting >> the process will remove the old version from memory and cause the new one to >> be used. I thought every OS did it like that, so I'm surprised that there are >> systems causing problems in this case. > > Wha, when did that happen? I was always under the impression that > binaries/libraries were demand paged in and referenced as a VM object > via VFS; you could unlink/rename the file and the currently open > reference would still be valid. I didn't know that binaries and libraries keep a reference to the file they were created from. Anyway, to the user the whole thing is transparent.