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.
To try to avoid needing to solve the correct RUMPHIJACK incantation, I just
tried building a
RUMPPRG= vnconfig
with
const struct vnconfig_prog_ops vnconfig_prog = {
.op_init = rumpclient_init,
.op_open = rump_sys_open,
.op_close = rump_sys_close,
.op_ioctl = rump_sys_ioctl,
};
Now a "rump.vnconfig -l" gets a
Program received signal SIGSEGV, Segmentation fault.
0x00007f7ff740c538 in doputwait (spc=0x7f7ff7613560, rw=0x7f7fffffb880,
rhdr=0x7f7fffffb8e0)
at /usr/src/lib/librumpclient/../librumpuser/sp_common.c:371
371 TAILQ_INSERT_TAIL(&spc->spc_respwait, rw, rw_entries);
...
#5 0x0000000000401683 in show (v=3, n=0)
at /home/prlw1/NetBSD/vnd/vnconfig/vnconfig.c:217
That v=3 is the fd as returned by opendisk, which looks like a non-rump
range. Does this mean a rump_sys_opendisk is necessary? Or I need to
go back to working on the correct HIJACK incantation? Thoughts?
That looks like a missing prog_init().
