From owner-cvs-all Mon Jun 21 22:11:22 1999 Delivered-To: cvs-all@freebsd.org Received: from dingo.cdrom.com (castles519.castles.com [208.214.165.83]) by hub.freebsd.org (Postfix) with ESMTP id C20EE1514C; Mon, 21 Jun 1999 22:11:18 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id WAA00443; Mon, 21 Jun 1999 22:07:58 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199906220507.WAA00443@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Brian F. Feldman" Cc: Peter Wemm , Jean-Marc Zucconi , hoek@FreeBSD.org, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: Re2: cvs commit: src/sys/kern imgact_gzip.c In-reply-to: Your message of "Mon, 21 Jun 1999 21:02:05 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Jun 1999 22:07:57 -0700 From: Mike Smith Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk > Actually, would it be too hard to implement gzip as a stacking VFS layer? > That way, you really could just pass a gzip-backed vnode to the elf > interpreter... Paging in from a gzipped object would be difficult; you'd have to un-gzip entirely into some temporary storage, which would be even less efficient. Actually, the principal use for gzipped executables (single-floppy environments) has gone away with the general advent of gzipped MFS images. It's much more efficient to keep all the binaries unpacked in RAM and run them from the MFS than it is to un-gzip them from either MFS or disk and then run them. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message