Hi dear GSoC fellows (mentors and students), this is André Günther. My project is to port 9vx to Windows. You all know, that we are supposed to make weekly status updates. Now I am a little late with this. (Still I am the only one! Students, where are you?).
So I make the start, by first shouting out a big thanks to Russ Cox, who's been an invaluable help for me in the last weeks. The communication is direct and very helpful. Perfect! I've started investigating the portability issues we face with windows already before start of the coding time and thus I am in the fine situation to be a bit a head of the schedule. The status is that i can run simple program using vxrun. Error handling is not completely there yet and blows up every now and then. But this is to be expected because I am in the middle of exploring that field. However what is clear is also, that I found an error handling approach that definitely works and is no dead alley. If you are not so much interested in all this you can probably stop now. However, for those who are interested I will write up some of challenges I had to face and how I solved them: - Creating custom LDT segments. Luckily the Nt* API has an undocumented possibility to set custom LDT segments via the NtSetInformationProcess interface. (If you look around you'll find a great wine patch that enables this api in wine together with illustrative test cases. Unfortunately however somehow no one dared to commit it upstream. What a shame!) - The windows API has no mmap or comparable interface. Instead you have to look around and tailor something for your needs. In this case a windows friendly replacement for libvx32/chunk.c. I've recreated the chunk system with a VirtualAlloc call that does only acquire a virtual address space but commits the pages on catched page access traps. This seems the only feasible solution in windows. There is one drawback I don't want to hide from you. Due to the mmap/file nature of the posix version of chunk you can just truncate the file to grow the memory. You cannot do that so easily with my windows version. But the bottom line is: allocate 1GB or something of virtual address space and a 9vx app is unlikely to need more than that. (If there is still need to grow that memory bit...I am sure to find a possibility to do it just in case. But that has not a high priority for now) Ah yes... we need error handling for this on demand page committing..now we get to the "fun" part. Windows error handling is cruel. And I will shoot anybody saying to me I should use SEH. I've read just about every useful information about SEH and came to the conclusion: You cannot do error handling in a libvx32 enabled app with SEH. And the reason is the following... When the windows kernel sees a trap coming, he does (some unimportant stuff ommited): 1) Is there a kernel debugger attached? If yes: let him handle it 2) Is there a user debugger attached? If yes: let him handle it 3) Did the app dared to change %ss? If yes: kill the process right on the spot and make it's programmers hope to do sane error handling on windows forever go away 4) ...some stuff and then eventually SEH vx32 messes with %ss? Oh yes! So you are hosed (And no there is no hero like SEH-Man coming to rescue your poor process). The only option is writing a usermode debugger. I've succeeded so far doing just that. When an error occurs in vx32 mode i can reset the process to a sane state and let it run in it's context with a saved context of the faulting vx32 code. And this is where I am. I am currently trying to convert the whole signal terminology and idioms used in the other implementations to this debugger solution. The next step would then be to finally enable the on demand page commiting. (Yes i currently just commit 1GB of ram for every process! And windows doesn't even burp. amazing.) When this is done i can basically start working on getting actually some 9vx stuff to run. (I originally estimated that for 7th of July). So when everything works well I am 3 weeks ahead of schedule. Best regards, André PS: All other students. Get your asses up: 1) do something productive 2) show it to us. I am also eager to see your progress :) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Plan 9 Google Summer of Code" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/plan9-gsoc?hl=en -~----------~----~----~----~------~----~------~--~---
