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