Allow vfork()ing an external gunzip binary instead of using fork().

Patch from Mike Westerhof, with minor modifications to allow the use of both
GNU gunzip and busybox gunzip. His original patch header follows.

This patch allows a user to set an environment variable to cause opkg to
select either the built-in gunzip code or an external gunzip utility, in
order to dodge the OOM Killer.

The built-in code is, of course, is the most desirable way to use opkg,
since it is far more efficient.  However, the built-in code can trigger
the OOM (out of memory) killer on small-memory machines, like the 32MB
NSLU2.  This occurs because a standard fork will duplicate the entire
address space of the parent.  Since opkg reads the entire feed database
into memory, this problem is compounded by large feeds.

This patch introduces a means for the user to cause opkg to use vfork()
instead -- vfork() does not behave in the same manner as fork(), and
does not trigger the OOM killer.  However, the semantics of vfork() are
such that it cannot run the built-in gunzip code.  Instead, it must
exec() an external utility to perform the gunzip operation.  It seems
counter-intuitive, but the vfork()/exec() approach is the only good way
to avoid triggering the dreaded OOM killer.

In order to use this, the user must manually set the OPKG_USE_VFORK
environment variable to any value.  For example:

$ OPKG_USE_VFORK=1 opkg install samba

The external utility used to do the gunzip operation is "busybox gunzip".
It would have been nice to be able to just invoke "gunzip", but the
full gunzip executable behaves slightly differently than does busybox,
generating annoying warning messages.

This is an update of the original patch by Mike Westerhof, Dec 2008.

Mike Westerhof, Feb 2011

git-svn-id: http://opkg.googlecode.com/svn/trunk@604 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358

0 files changed, 0 insertions, 0 deletions