From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 25 21:07:18 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB51B16A4CE for ; Tue, 25 Jan 2005 21:07:18 +0000 (GMT) Received: from coe.ufrj.br (roma.coe.ufrj.br [146.164.53.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B1BD43D62 for ; Tue, 25 Jan 2005 21:07:18 +0000 (GMT) (envelope-from jonny@jonny.eng.br) Received: from localhost (localhost [127.0.0.1]) by coe.ufrj.br (Postfix) with ESMTP id C62883F411; Tue, 25 Jan 2005 19:07:16 -0200 (BRST) Received: from coe.ufrj.br ([146.164.53.65]) by localhost (roma.coe.ufrj.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43273-04; Tue, 25 Jan 2005 19:07:11 -0200 (BRST) Received: from [200.217.93.42] (unknown [200.217.93.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by coe.ufrj.br (Postfix) with ESMTP id F34F43F410; Tue, 25 Jan 2005 19:07:10 -0200 (BRST) Message-ID: <41F6B509.2080101@jonny.eng.br> Date: Tue, 25 Jan 2005 19:07:21 -0200 From: =?ISO-8859-1?Q?Jo=E3o_Carlos_Mendes_Lu=EDs?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Dillon References: <86pszu639o.fsf@borg.borderworlds.dk> <86brbe6052.fsf@borg.borderworlds.dk> <200501242240.j0OMeIXP043763@apollo.backplane.com> <41F59242.7090900@jonny.eng.br> <200501251948.j0PJmpYG048845@apollo.backplane.com> In-Reply-To: <200501251948.j0PJmpYG048845@apollo.backplane.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: amavisd-new at coe.ufrj.br cc: ctodd@chrismiller.com cc: hackers@freebsd.org cc: Christian Laursen cc: Dominic Marks Subject: Re: Resuming from a crashdump X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2005 21:07:18 -0000 Matthew Dillon wrote: > Well, I don't want do disuade you from trying, but I think you are > seriously underestimating the effort required to restore device state. > > You basically would either have to make all device drivers support a new > hibernation/restore API (because it is not really possible to restore Shouldn't it be very similar to the suspend API? > a device driver based on a dump), or you would need to implement some > higher level utility code (e.g. scripts and such) to try to record and > restore the state at a higher level, such as for network interfaces, > and not allow any restored processes to run until that's done. Either > way it would get messy very quickly. > > Also, if the machine has a lot of memory it could take longer to save > and restore then to reboot from scratch. A typical laptop HD is Indeed true, but when I use windows hibernate I don't intend to simply bypass boot procedures, I want to keep the workspace active. If the workspace is not important, I simply shutdown, as it is also a profilatic memory cleaning. ;-) > I think it would probably be more realistic to persue a process > save/restore rather then a kernel save/restore. The overhead is going > to be the disk I/O anyway and that seems to be about the same either > way (maybe less for a process restore), plus you can at least demand-load > the process restore. Let's suppose I want to keep my X desktop intact. Should I save/restore processes in which order? X server or X clients? They need to interact with each other, and if one try to interact while the other has already "died", it will simply close and die too. That's why I think a kernel save/restore is better for a full hibernation situation. Of course single process hibernation is also useful! I am a very old user, from the times where LaTeX had to core dump after initializing variables to startup faster later. ;-) Jonny -- João Carlos Mendes Luís - Networking Engineer - jonny@jonny.eng.br