From owner-freebsd-current Fri Feb 6 19:34:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA27226 for current-outgoing; Fri, 6 Feb 1998 19:34:11 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA27208; Fri, 6 Feb 1998 19:34:07 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id TAA03469; Fri, 6 Feb 1998 19:32:59 -0800 (PST) Message-Id: <199802070332.TAA03469@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Andrzej Bialecki cc: Terry Lambert , freebsd-current@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: Custom init(8) (and some ideas) In-reply-to: Your message of "Thu, 05 Feb 1998 10:40:21 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 06 Feb 1998 19:32:58 -0800 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe current" > A bit of background, if you're interested: I'm working on the next version > of PicoBSD, and after some shuffling with the layout and adding new > features I found that I can no longer fit into 8MB RAM... I.e. it fits, > but I can't start enough processes to make a dialup connection. What does the process listing look like? (use ddb and the 'ps' command rather than try to squeeze 'ps' into the crunch image). > There was one really nasty surprise which I experienced: the way the > gzipped binaries are executed. It wastes a LOT of RAM. How else would you do it? You can't easily page off an LZW-compressed image (for obvious reasons), so you have to put the uncompressed thing *somewhere*. Have you shrunk the kernel as much as possible? > I had some ideas how to fix it, but the implementation of this is far > beyond my knowledge: to modify imgact_gzip NOT to load the gzipped binary, > but just to mmap it, and then unpack it. When I asked John Dyson he said > that it would require a lot of work to change it... Pity. I'm not sure I follow you there. The imgact_gzip code doesn't load the gzipped binary at all; it mmap's it one page at a time, uncompressing it as it goes. > Also, IMHO it would be a good option to the kernel and/or ld.so to tell > them not to load .text at all (it could apply to .text section of binaries > as well as shared libs), just to mmap it, if the backing filesystem is of > MFS type. For non-gzip binaries, execution starts by mmapping the entire text section, and jumping to it. Nothing is "loaded" in any case. What you're suggesting really is "execute-in-place", which is quite a tough thing to implement. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com