From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 17 20:25:48 2004 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 D934116A4CE for ; Tue, 17 Aug 2004 20:25:48 +0000 (GMT) Received: from afields.ca (afields.ca [216.194.67.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6ADAE43D1D for ; Tue, 17 Aug 2004 20:25:48 +0000 (GMT) (envelope-from afields@afields.ca) Received: from afields.ca (localhost.afields.ca [127.0.0.1]) by afields.ca (8.12.11/8.12.11) with ESMTP id i7HKPl4o039010 for ; Tue, 17 Aug 2004 16:25:47 -0400 (EDT) (envelope-from afields@afields.ca) Received: (from afields@localhost) by afields.ca (8.12.11/8.12.11/Submit) id i7HKPln7039009 for freebsd-hackers@freebsd.org; Tue, 17 Aug 2004 16:25:47 -0400 (EDT) (envelope-from afields) Date: Tue, 17 Aug 2004 16:25:47 -0400 From: Allan Fields To: freebsd-hackers@freebsd.org Message-ID: <20040817202547.GB33859@afields.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Subject: Crunchgen (Was Re: actual boot device) 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, 17 Aug 2004 20:25:49 -0000 On Tue, Aug 17, 2004 at 07:54:14PM +0300, Sergey Lyubka wrote: > Probably kenv loaddev is the answer, my problem is that I cannot fit > loader into the image - it is already packed enough. Are you using/have you tried crunchgen(1)? This is how the rescue binaries are done. It might save on space in your image where memory is very tight and this could free up space for a loader. (I don't know if this has any relation to what your doing, but...) On a side note: I was experimenting around with a single process image that locked a shell and basic binaries into memory for administrative purposes (w/o using md), but haven't done much to eliminate problems with file descriptors, etc. (It also does strange things w/ some libraries, which isn't unexpected given the simplistic approach I took.) Even though it isn't something you want to use everyday: crunchgen made it quite space efficient. The idea was that the main() in each binary would be called from the shell with-in the same address space and it would then hook exit and return to the shell command-loop: which warps the unix binary tools based approach, but might be handy in some situations. It makes tools such as ps, kill and fsck shell built-ins. Sort of taking a statically linked base to the extreme while keeping the size down. If there is interest it could be rewritten properly to supplement rescue infrastructure. I did make mlockall(2) and rtprio(2) work (where it is supported) but haven't updated the project files yet. It's done in the style of a pseudo-port which needs the freebsd sources to build and uses some rather nasty patching techniques (patching on output of a tool, rather than patching crunchgen). Another approach would be to simply keep the crunched rescue binary & hardlinked entries in a memory disk which is loaded from rc scripts and then mounted at /rescue. I'm not sure if in all cases that would do it, but in case of a failed disk or other fs problems, it might be helpful. I'm also a fan of kill in the debugger, very handy in case a machine on the edge is still able to be resuscitated. -- Allan Fields, AFRSL - http://afields.ca 2D4F 6806 D307 0889 6125 C31D F745 0D72 39B4 5541