On 28/05/15 20:09, Patrick Welche wrote:
On Thu, May 28, 2015 at 10:59:52AM +0000, Antti Kantee wrote:
On 28/05/15 10:30, Patrick Welche wrote:
I'm having an entertaining time trying to debug vnd by running vnconfig
against a rump kernel. It seems that my HIJACK incantation of a year ago:
export RUMPHIJACK=path=/rump,blanket=/dev/vnd:/dev/rvnd
no longer works. The problem seems to be because vnconfig does
opendisk() want vnd0 -> rump's /dev/rvnd0d
open() want e.g. /tmp/foo.img (works if add /tmp/foo.img to blanket)
in vnconfig vnd0 /tmp/foo.img case
ioctl() usually does run rump's vndioctl if we get that far
You need to vnconfig /rump/tmp/foo.img, not /tmp/foo.img.
OK, trying again with
export RUMP_SERVER=unix:///tmp/sock
export RUMPHIJACK=path=/rump,blanket=/dev/vnd:/dev/rvnd
export RUMPHIJACK_RETRYCONNECT=inftime
export LD_PRELOAD=/usr/lib/librumphijack.so
$ dd if=/dev/zero of=/rump/tmp/foo.img count=12000
12000+0 records in
12000+0 records out
6144000 bytes transferred in 27.818 secs (220864 bytes/sec)
$ ls -lh /rump/tmp
total 5.9M
-rw-r--r-- 1 root wheel 5.9M May 28 20:47 foo.img
$ vnconfig -l
vnd0: not in use
vnd1: not in use
vnd2: not in use
vnd3: not in use
$ vnconfig vnd0 /rump/tmp/foo.img
vnconfig: /dev/rvnd0d: VNDIOCSET: No such file or directory
Ah, you're right, you do need to blanket /tmp/foo.img since the path is
passed to syscalls both via opendisk (which I assume uses open() or
something like that) and via ioctl() which just hides the path in some
covert ioctl protocol. Since rumphijack doesn't see inside the ioctl
parameter -- and let's not start teaching hijack about all gazillion
ioctl parameters -- it cannot adjust the path.
btw, dd in your use case will be a lot faster if you specify bs=1m or
so. 512 bytes is rather small since every call to write() is min 4 full
context switches.
To try to avoid needing to solve the correct RUMPHIJACK incantation, I just
tried building a
RUMPPRG= vnconfig
...
That looks like a missing prog_init().
Indeed - thanks! And then I get stuck down that avenue as NetBSD gdb
can't cope with pthread_sigmask as per PR bin/49662, so it seems that
HIJACK incantation is the only way forward... (or linux gdb I suppose)
Hijack or not, the syscall path on the client side is exactly the same
(through rumpclient_syscall), so using a different route to get there
will do nothing for solving the problem.
I thought I filed a PR on the subject of gdb+sigprocmask() failing like
4+ years ago, and I also thought it was fixed.
Why do you want to single-step the syscall path on the client side
anyway? It does practically nothing interesting.
