Date: Tue, 14 Mar 95 12:50:45 -0800 From: Bakul Shah <bakul@netcom.com> To: freebsd-hackers@freefall.cdrom.com Subject: Re: install compressed binary patch Message-ID: <199503142050.MAA06074@netcom17.netcom.com>
next in thread | raw e-mail | index | archive | help
Notice that decompression is a `pure' function; the same
compressed input will produce the same uncompressed output
every time. Can't this fact be used some way?
The idea is this: given a compressed binary `foo', create an
uncompressed binary somewhere. Upon every invocation of foo
check if the uncompressed version exists. If so continue as
if the user is really invoking the uncompressed version.
The uncompressed version disappears once the last running
instance is gone (or it may be cached for a while to save on
decompression cost).
You can do a pretty good imitation of this by a #! script.
- The compressed version `foo' gets a #!/usr/bin/decodebin
or some such header followed by the compressed data.
- decodebin checks if .cache/foo exists.
- If not,
- decodebin tries to create .cache/foo.lock.
- If .cache/foo.lock already exists,
- decodebin waits till .cache/foo is created.
Now it execs .cache/foo.
- If decodebin can create .cache/foo.lock,
- foo.lock is filled with the uncompressed data,
marked executable, and renamed .cache/foo
- Now .cache/foo exists.
- decodebin execs .cache/foo.
- Periodically files in .cache are purged.
The only danger is that if there are long running binaries,
all binaries started between two such purges will share an
(already unlinked) copy. Very very rarely we might get each
running binary with its own copy but this is no worse than
what will happen now all the time with compressed binaries.
Figuring out where to put the .cache dir is left as an
exercise for the reader. Ideally it belongs in the same
directory as the compressed binary but that can't be done if
the binary is on a readonly file system.
The same scheme can be used for things other than compressed
binaries. For instance, you replace infrequently used
binaries with such a script as part of some backup. The
next time you tried executing this script, the system will
ask you to read back the real file from a backup tape. At
this point you can even replace the script with the
original. The well connected among you can ftp the file
from elsewhere!
Years ago we used to talk about implementing a file type
called `portal'. When you opened a portal file, a program
would be run by the system. Read/write calls would be
delivered to this program in some fashion. [Such files were
called portals because in effect this program acts as a
sentry at the `port' to the file] With portals you can do
some very nifty things. e.g. a file from which you can read
current time, a file that will deliver 2^32 (now 2^64 :-)
digits of pi, etc. Anyway, if portals were available, you
could do also compress data files or move them elsewhere. [I
don't think the portal filesystem of 4.4BSD does anything
like this].
Bakul
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199503142050.MAA06074>