From owner-freebsd-hackers Wed Mar 15 17:30:54 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id RAA04333 for hackers-outgoing; Wed, 15 Mar 1995 17:30:54 -0800 Received: from netcom11.netcom.com (bakul@netcom11.netcom.com [192.100.81.121]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id RAA04327 for ; Wed, 15 Mar 1995 17:30:53 -0800 Received: from localhost by netcom11.netcom.com (8.6.10/Netcom) id RAA26182; Wed, 15 Mar 1995 17:29:13 -0800 Message-Id: <199503160129.RAA26182@netcom11.netcom.com> To: Bruce Evans Cc: freebsd-hackers@freefall.cdrom.com Subject: Re: install compressed binary patch In-reply-to: Your message of "Wed, 15 Mar 95 14:40:42 +1000." <199503150440.OAA31147@godzilla.zeta.org.au> Date: Wed, 15 Mar 95 17:29:08 -0800 From: Bakul Shah Sender: hackers-owner@FreeBSD.org Precedence: bulk > I think the gzip image activator already does a better job than this. It does? Then why are people saying that running compressed binaries are not shared? > Neither does a very good job with the following issues: > > - caching. Everything should probably be cached for a while > (days?) if there is enough space. My scheme handles it (read the more detailed description in my email, just below the section you quoted). > - transparency. readdir() should act as if only the uncompressed > objects exist. Backups should act as if only the compressed > objects exist (although this is inconsistent :-). read() and > mmap() should give uncompressed objects. These are laudable goals; which is why mentioned `portals' in my email (they would allow you to implement what you want)! In fact there are many places where you want such dual views: some time you want what is *really* there and sometimes you want a transformed version of it. I am distrustful of adding new complicated things in an already big kernel so I'd rather have a kernel mechanism that allows me to implement such things in user mode. In effect I want user-defined file-types. Bakul