[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: exec server and /dev/fd/N

From: olafBuddenhagen
Subject: Re: exec server and /dev/fd/N
Date: Wed, 26 May 2010 09:32:23 +0200
User-agent: Mutt/1.5.19 (2009-01-05)


On Mon, May 24, 2010 at 12:08:10PM +0200, Emilio Pozuelo Monfort wrote:

> Basically the problem is that in some cases the exec server can't find
> the file name of the file being executed (when it's a script), and
> then makes a hack passing /dev/fd/N to the interpreter.
> I tried to fix it with heuristics such as "if the file name contains
> no slashes, then it's relative" and passing just a flag to the exec
> server to avoid needing to create new RPCs, but that's not enough,
> since a call like execv("foo",{"bar", NULL}) (i.e. filename !=
> argv[0]) should work too. So the only option is to pass filename to
> the exec server, and just use that.

IIRC my major concern with this approach was that this way, the original
task has to guess what file name will be valid in the new task's
context... I don't remember though what my conclusion was regarding this
being better or worse than doing the guessing in exec :-(

> There's a little bootstrapping problem here: you can't apply the four
> Hurd patches directly and build the whole Hurd, because lib*fs will be
> using exec_exec_file_name, but the dynamic linker can't find it, since
> libhurduser.so should provide it but you haven't build glibc yet. So
> to bootstrap it (without hacks like partially building Hurd, e.g. what
> we would need to do in the Debian packages) one would need to apply
> all but 0004 patches to Hurd and build it, then build glibc with the
> new Hurd installed, and then finally build Hurd with the 0004 patch.

It's actually way easier than that: just copy the new .defs to
/include/hurd before building the new glibc, which you can then use
while building the new Hurd.

> I mentioned this on #hurd and antrik said that the Hurd specific parts
> of libhurduser.so should maybe be moved to Hurd.

Well, there are several levels there actually. One thing would be
splitting off libhurduser; another, splitting off the hurdish syscall
implementations alltogether. Also, they could be moved to a completely
separate library; or made part of the Hurd tree. I'm not sure which
option is preferable here -- either one would be an improvement over the
current situation IMHO...

BTW, patch series are normally sent with the patches as individual mails
in a thread -- see --thread, --cover-letter, and/or --in-reply-to
options to "git format-patch". You can send them off manually, or use
"git send-email".


reply via email to

[Prev in Thread] Current Thread [Next in Thread]