9vx - Status 1
André Günther
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 :)
maht lawless
but come along to vex us anyway.
It's going to be fun when one of your processes runs away and gets 1Gb
RAM :>
Good luck with it,
and YES where are the other reports!
Matt
Alex Shinn
> and YES where are the other reports!
Hi!
I'm Alex Shinn, a graduate student studying natural language
processing in Japan. My gsoc project is to port a Scheme
implementation to Plan 9. There is already a port of
TinyScheme available, but if you've ever tried it you'll
know that it's extrememly slow, even by scripting language
standards. So I'm porting my own implementation, which is
just as small but much faster, and overall a more complete
Scheme implementation, including hygienic macros.
Even if I can't get many Plan 9 users interested in Scheme,
I know a lot of Schemers have a healthy respect for Plan 9,
and making a usable implementation available may get some
converts in the other direction, and enable some healthy
cross-pollination, so to speak :)
Anyway, my first progress report is available at
http://synthcode.com/blog/2009/06/Garbage_Collection
You'll have to excuse the clumsy blog implementation, it's
still a work in progress. I'll add support for comments
later.
--
Alex
Iruata Souza
I'm Iruatã from Brazil. My project is called 9null and strives to make
Plan9's boot process a little more flexible by removing the need for
9load using a kernel and /dev/reboot.
My first blog post is being written right now explaining the project
is greater detail.
http://gsoc.9vx.org/hg/9null has the Plan 9 kernel, 9load, and some
notes I'm collecting.
I hope that at the end of the project we have a more flexible boot
scheme, allowing to boot and run on more pc hardware with less pain.
iru