Date: Wed, 15 Mar 95 17:29:08 -0800 From: Bakul Shah <bakul@netcom.com> To: Bruce Evans <bde@zeta.org.au> Cc: freebsd-hackers@freefall.cdrom.com Subject: Re: install compressed binary patch Message-ID: <199503160129.RAA26182@netcom11.netcom.com> In-Reply-To: Your message of "Wed, 15 Mar 95 14:40:42 %2B1000." <199503150440.OAA31147@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199503160129.RAA26182>