From owner-freebsd-current Sun Feb 8 18:37:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA14908 for current-outgoing; Sun, 8 Feb 1998 18:37:45 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA14893; Sun, 8 Feb 1998 18:37:38 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id TAA13758; Sun, 8 Feb 1998 19:37:31 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp02.primenet.com, id smtpd013720; Sun Feb 8 19:37:26 1998 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id TAA22548; Sun, 8 Feb 1998 19:37:20 -0700 (MST) From: Terry Lambert Message-Id: <199802090237.TAA22548@usr06.primenet.com> Subject: Re: Custom init(8) (and some ideas) To: reilly@zeta.org.au (Andrew Reilly) Date: Mon, 9 Feb 1998 02:37:20 +0000 (GMT) Cc: mike@smith.net.au, tlambert@primenet.com, dyson@FreeBSD.ORG, abial@nask.pl, freebsd-current@FreeBSD.ORG, jkh@FreeBSD.ORG In-Reply-To: <199802082219.JAA03349@gurney.reilly.home> from "Andrew Reilly" at Feb 9, 98 09:19:11 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > If this is likely to become a popular game (paging from compressed > binaries), would it be useful to build a special "binary gzipper" that > split and separately compressed independent 4k pages? I believe that > the V.42 compression in modems forces blocking at 256-byte boundaries, > to minimise the amount that needs to be re-transmitted on errors, and > that still manages reasonable error rates. You would need to build a > table of pointers to each of the blocks to avoid scanning the whole > thing, but there could be some gain. Is there an obvious reason for > this not to work? If you could be *guaranteed* that the compressed imaged of 8k would become at most 4k, then you could do page doubling. The problem is that you need a VM object for the executable to grab pages off of on page boundries, and you *also* need to grab pages off of disk in page boundries. The closest thing to this currently is the vn? devices configured by vnconfig. They just *happen* to present 4k as 4k; they could just as easily present a smaller amount as 4k (after uncompression). You would *still* have the block-boundry issues, though. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe current" in the body of the message