All of lore.kernel.org
 help / color / mirror / Atom feed
From: Denis Vlasenko <vda.linux@googlemail.com>
To: David Lang <david.lang@digitalinsight.com>
Cc: Rob Landley <rob@landley.net>,
	linux-kernel@vger.kernel.org,
	David McCullough <david_mccullough@au.securecomputing.com>
Subject: Re: Feature request: exec self for NOMMU.
Date: Wed, 27 Dec 2006 05:24:36 +0100	[thread overview]
Message-ID: <200612270524.36157.vda.linux@googlemail.com> (raw)
In-Reply-To: <Pine.LNX.4.63.0612261549050.24795@qynat.qvtvafvgr.pbz>

On Wednesday 27 December 2006 00:55, David Lang wrote:
> On Tue, 26 Dec 2006, Rob Landley wrote:
> 
> > I'm trying to make some nommu-friendly busybox-like tools, which means using
> > vfork() instead of fork().  This means that after I fork I have to exec in
> > the child to unblock the parent, and if I want to exec my current executable
> > I have to find out where it lives so I can feed the path to exec().  This is
> > nontrivial.
> >
> > Worse, it's not always possible.  If chroot() has happened since the program
> > started, there may not _be_ a path to my current executable available from
> > this process's current or root directories.
> 
> does this even make sense (as a general purpose function)? if the executable 
> isn't available in your path it's likly that any config files it needs are not 
> available either.

busybox needs it in order to spawn, for example, gzip/bzip2 helper
for tar. We know that our own executable has this function.
How to execute _our own executable_? exec("/proc/self/exe")
works only if /proc is mounted. I can imagine that some embedded
people want to be able to not rely on that.
--
vda

  parent reply	other threads:[~2006-12-27  4:25 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-26 23:23 Feature request: exec self for NOMMU Rob Landley
2006-12-26 23:55 ` David Lang
2006-12-27  0:39   ` Rob Landley
2006-12-27  4:24   ` Denis Vlasenko [this message]
2006-12-27  5:44     ` Rob Landley
2006-12-27  5:13 ` Ray Lee
2006-12-27  5:51   ` Rob Landley
2006-12-27  6:08     ` Vadim Lobanov
2006-12-27  8:29       ` Rob Landley
2006-12-27 18:49         ` Ray Lee
2006-12-27 21:13           ` Rob Landley
2006-12-27 18:35   ` Denis Vlasenko
2006-12-27 21:03     ` Rob Landley
2006-12-28  2:48       ` Denis Vlasenko
2006-12-28  5:32         ` Rob Landley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200612270524.36157.vda.linux@googlemail.com \
    --to=vda.linux@googlemail.com \
    --cc=david.lang@digitalinsight.com \
    --cc=david_mccullough@au.securecomputing.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rob@landley.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.