Re: rump newbie question

[Antti Kantee <pooka%iki.fi@localhost>]

Well, the short answer is "not unless you want a hobby".  Given that you 
seem to be in for a hobby with kgdb anyway, I'll proceed with the long 
answer and let you decide for yourself which hobby you find more 
interesting.

On 18/02/14 21:28, Justin Cormack wrote:
> On Tue, Feb 18, 2014 at 12:33 PM, Patrick Welche <prlw1%cam.ac.uk@localhost> 
> wrote:
> > As I am having issues with kgdb over serial, I thought I would try kernel
> > debugging using rump. My first attempt has been to run rump_allserver, and
> >
> > (gdb) attach 24469
> > Attaching to program: /usr/bin/rump_allserver, process 24469
> > Reading symbols from /usr/lib/librumpdev_audio.so.0...done.
> > Loaded symbols for /usr/lib/librumpdev_audio.so.0
> > ...
> > (gdb) break sys_modctl
> > Breakpoint 1 at 0x7f7fe6c49971: file 
> > /usr/src/lib/librump/../../sys/rump/../kern/sys_module.c, line 111.
> > (gdb) c
> > Continuing.
> >
> >
> > Then:
> >
> > quark# rump.modload /stand/amd64/6.99.31/modules/hdaudio/hdaudio.kmod
> > rump.modload: prog init failed: No such file or directory
> >
> > Is this a sensible way of looking at hdaudio? What am I missing?

Judging by the error message, I'd guess $RUMP_SERVER is not set properly.

> Looking at ktrace on my machine it loads hdaudio fine but then fails
> trying to  open /stand/amd64/6.99.28/modules/pci , not sure if you
> have the same issue, what does ktrace output say?

... but this is a more interesting point.  There is currently no support 
for pci as a loadable module, at least as far I can see from looking as 
src/sys/modules.  As hdaudio depends on a pci module, and, unlike a 
monolithic kernel, a rump kernel does not have pci builtin, the hdaudio 
module cannot load in a rump kernel because a dependency is missing.

Even if a pci module (non-builtin) existed, there is currently no 
support for the pci bus access in userspace in rump kernels.  It is 
easy('ish) to support pci in a rump kernel as shown by rump kernels on 
top of Xen, at least assuming you don't care about DMA safety.  However, 
no matter how easy someone must write the code for userspace for pci bus 
access to work.

There's also the issue that amd64 kernel module binaries can't generally 
be loaded into userspace because the kernel modules use 32bit pointer 
offsets, which understandably doesn't work very well in a 64bit address 
space.  It's not difficult to hack around this in a private tree 
(trivial solution example: compile sys/module without -mcmodel=kernel), 
but slightly more difficult to turn the workaround into something that 
could be committed.  I'm not saying a committable solution is 
impossible, it's just a bit more convoluted.

So, as is always the case with open source, fixing something trivial has 
recursed into coming up with solutions to n problems (*).  If you're 
just interested in just the hdaudio problem, the fastest way is most 
likely printf-reboot-printf-reboot-.... but that won't help the next 
person, or yourself, with the next driver under the hammer.

  - antti

*) incidentally, that's why I enjoy Windows where problems can't be fixed