Hi -
I'm writing to update the list on my current work and possibly get some
useful suggestions.
I'm trying to test the multi-client libpager in a subhurd, but I'm having
problems even getting the old libpager code to work cleanly in a subhurd,
so I know I've got problems that aren't just in my code.
My problematic test case is to boot a subhurd that's got a full hurd system
on a second (virtual) hard drive and run dpkg-buildpackage -b on the hurd
packge's source tree. You just need to make a copy of your disk available
on hd1 and run boot /dev/hd1.
It runs for a while, and then the whole system hangs. I get some invalid
right / invalid name errors from the proc server at in its
S_mach_notify_new_task routine (looks like its getting a bogus task port)
and then everything stops. Doesn't always stop at the same point, but I
can't get through a package build.
This is what I'd really appreciate some help with, from somebody who knows
the proc server better than me. Like I said, it fails with just stock
code. I'm thinking it's some kind of race condition relaying messages
between the two proc servers in the main hurd and the subhurd, but I can't
quite puzzle it out.
So, I thought to myself, why not modify rpctrace so that it can attach to
the proc server and trace it? Maybe I could modify startup to start proc
with rpctrace wrapped around it, but we eventually want rpctrace to attach
and detach running programs, so let me at least get the attach code written.
Went and wrote an attach subroutine for rpctrace (about 400 lines of code),
that seems to work, but with one major problem. rpctrace sets up its
receive rights so that they have either a send right or a send-once right
associated with them, and the two cases are completely separate. If you're
importing ports from an attached process, however, you might end up with
receive rights that have both send and send-once rights attached to them.
OK, so I went and modified rpctrace so that it now has a single port
structure that handles both send and send-once rights.
Now, it turns out that I can't detect which kind of right (send or
send-once) a message comes in on, which makes the code a mess (still don't
have it working). The reason I can't detect it is that the protected
payload optimization doesn't report which type of right the message came in
on. So, I think, I'll disable the protected payload optimization by
clearing the protected payload first thing after the port is created. That
doesn't work either, because libports puts a simulated protected payload
right back in. I'd sure like to have an option on libports to disable
protected payloads and let me see the unmodified Mach messages, but that
doesn't exist.
Or, for that matter, it would be nice if the kernel reported two different
values in MACH_MSGH_BITS_LOCAL (one for send and one for send once) when
protected payloads are in use.
agape
brent
