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.
video mode. "vesa on" will now select the preferred mode @ 8bpp if it can
be determined and is supported by the display adapter, otherwise it will
use 640x480 @ 8bpp.
2 and a bit ethernet packets. Check and increase SO_RCVBUF on startup
so that we have buffers for 10 complete packets, should solve a
reported problem with overruns at higher connection speeds (our L2CAP
does not have any flow control).
(the default can still be adjusted upwards using sysctl)
copyright. Confirmed by Mike Hibler, mike at cs.utah.edu - thanks!
Also, merge UCB and Utah copyright texts back into one, as they
originally were.
Extra verification by snj@.
so provide the TARGMACH definition to the compiler here.
(makes no difference to the currently imported sources, but
will be easier for people wanting to try newer sources)
libc resolver uses it. Error out in case of rump fd kevent (TODO).
Fixes one more problem pointed out by Alexander Nasonov.
Also, implement dup().
(TODO: implement it along the fcntl path too)
