slightly better in the multithreaded exec case in terms of partial
frames sent. Plus, it's theoretically a little cheaper.
There's still a gray area with partial transfer from sendmsg(),
but I'm not sure I care enough about some academic scenario to
start fixing it (it basically needs an OOB exec signaller).
function call instead of a call through a function pointer.
Apparently powerpc ld.elf_so gets __hackish_return_address() wrong
if the call is done through a function pointer (digging deeper into
that stuff is beyond my interest).
Thanks to riz for providing access to a macppc for debugging.
Unthanks to the broken toolchain in the default installation which
wasted approximately 4 hours of time last night.
while for some cases attempting retry after server restart works
brilliantly (e.g. firefox), in other cases it's quite disasterous
(sshd doesn't like its file descriptors going missing and does not
attempt to reopen them, leading to a quite catastophic loop of
EBADF once the server does come back)
* rename RUMPHIJACK_RETRY to the slightly more sensible
RUMPHIJACK_RETRYCONNECT
rump tcp/ip stack:
* sshd likes to fork and then re-exec itself
==> trap execve() and augment the env with the current parameters
essential to a rump kernel (kernel communication fd, information
about dup2'd file descriptors)
* sshd likes to play lots of games with pipes, socketpairs and dup{,2}()
==> make sure we do not close essential rump client descriptors:
dup() them to a safe place, except for F_CLOSEM where we
simply leave them alone. also, partially solved by the above,
make sure the process's set of rump kernel descriptors persists
over exec()
* sshd likes to chdir() before exec
==> for unix-style rump_sp(7) sockets save the full path on the
initial exec and use it afterwards. thread the path through
the environment in execve()
TCP/IP stack:
* mutt prepares to exec the smtp client: it forks and closes all
file descriptors
* when the next networking syscall is done, rumpclient detects that
the communication fd returned EBADF and does a reconnect,
gets descriptor 0 for the socket and descriptor 1 for kqueue
* mutt opens the mail file and implicitly assumes it'll get 0-2,
but in fact gets 2-4
* mutt execs the smtp agent which tries to read the mail from
stdin (rumpclient communication socket) and fails
Even if mutt correctly did dup2() things would go south when trying
to communicate with the kernel server the next time, since rumpclient
would actually be talking with some mail body instead (well, it
could work, but in that case you'd need to write *really* weird
mails ;).
Hence, prevent rumpclient from using the special fd's 0-2 for its
purposes.
Should fix mutt problem reported by Alexander Nasonov.
pooka