Ugh. what an ugly week.

I decided to start at the beginning on my documentation again. the stuff i was writing at patch 47 was much better than the level of detail i provided at the beginning. I naively thought i'd make it to patch 47 again inside of a week.

Then I ran into patch 17.

Patch 17 is the x86_64 entry.S system call insertion. in this patch, we do something evil to the stack (that i still don't quite understand), to make sure space for the userspace registers is allocated and available when we jump to the user_thread handler.

Its all written in X86_64 assembly. I haven't done assembly since before i started using linux.

So now, I'm reading "The Revolutionary Guide to Assembly Language". I'm about 100 pages in. it may be x86, not x86_64, and may cover dos and bios calls, but i'm pretty sure when i get through it, i'll be ready to tackle this file.

On an ironic note, I've already made it through the X86 version of this patch. I'll probably go through it again, before going on to patch 18.

This assembly makes my head hurt.

Patch 47 commentaried!

this patch was all functions for 'doing work' on the home node on behalf of the remote node. syscalls, fork(), execve, mmap.. several file related functions, all called only on the remote node. the quality of the code in this patch was pretty high.

i pounded through this commentary, listening to my usual xaphan.us monday night show. the code was rather straightforward, even if it seems complex. the most grevious error i could find in it was a case of memory leak if something went wrong in remote_execve.

on the plus side, this is the last patch of its side in the 'first 98' that makes a compilable version of openmosix. its all downhill from here, mostly headers. then at least I'll have something that compiles, to start cleaning up, piece by piece. only 322 patches in the set!

so, I've done two levels of review on 7,200 lines of patch, with 25,000 lines total. and its taken me 5 months. I'm way over my head. *shrugs*

and after all that, I've still got outstanding bugs.

my brain will pay for this in the morning.

Patch 46 commented! Even as i was going through this patch, i thought it was simple. just add some entries to /proc, right?

I underestimated how much of a pain it is to dig through incomplete code. after documenting all 391 lines of the stuff, I'm convinced that this version is being called by nothing, to accomplish nothing. later patches touch this file, however, so *shrugs*.

I went to a great dylan rymes show the other day. one of the neatest things was that he plays the stuff that my local associates at xaphan.us are playing.. then takes it farther. starting up, it sounded like xaphan's regular monday night show.. but then it built into something amazing.

other than that, i'm still job hunting, after 5 months. i've out-stripped the job market in the local area. the most advanced stuff i can find to do is port $EVIL_COMPANY's applications from one version of *nix to another, and i don't *write* non-free software, so thats out. Ugh. I guess its time to move out of the area.

one more patch down.. some 52 hunks to work through before i start actually laying hands on this stuff.

Patch 45 commentaried!

this patch was the mirror image of patch 44, called to actually send a process either home, or remote. theres some discrepancies between the two processor context send/recv functions i'll have to fix, an of course the vma file handling is broken, which is the thing that needs fixed to call this all 'beta' quality.

personally, recovering from patch 44 was hard. that was really like hitting myself in the head with a hammer. i've only got 5 more patches that should be near that ugly, however.

in theory, it should possible to migrate processes from ia32 to AMD64, and back. in practice.. the code isn't written for it.

while digging through this process teardown/buildup code, i can almost "smell" a process suspend-to-disk procedure, which would be neat to have on hand for things like kernel reboots without losing userspace state. likely also handy for suspend to disk, where you don't any longer have to 'save' userspace. outside the range of the problem i'm solving at the moment, however. process migration is such a big problem.. its truely overwhelming.

having watched the new Battlestar Galactica, i really feel some similarities between events in that, and how i ended up with this mess in my hands. unfortunately, none of my local friends are up-to-date on the series, so i can't talk about it. annoying!

its about time for classes to be over for the university students. i'm wondering how many of the irregulars will show up to the project this year.

in a massive frenzy, i commented patch 44, which contains all the code for constructing and launching a process passed in via a socket. lots of deep kernel magic, for which there IS no reference. over all, other than the broken rfile subsystem, and the pending re-organization to use per-process packet queues, this code wasn't half bad.

my bain, however, is mush. i'm not meant to review that much code at once. i just got "inspired".

ouch. my poor poor brain.

i really wish someone would review this stuff. i'm sure i made several mistakes, and this is my SECOND time commentarying..

i had a job inteview first thing this morning. i seem to do good on those. heres hoping.