Older blog entries for riscgrl (starting at number 20)

re-commentaried patch 41.

this entire time, i've been very sick. i've got my regular winter series-of-flu. today, i'm being brave, by not living under a blanket.

hpc/kernel.c seems to be just a resting place for callbacks from both PMI code, and hooks we add to the kernel. i'm not sure if my complete confusion is due to the illness, or the code itsself just dosent go together that well.

i guess you need somewhere to put the random stuff.

wow. been a while since i updated this. i've gone back to work at a previous employer, with a nice raise and a company car. i'm currently commenting on patch 40 of my linuxpmi patches, after re-restarting from the begining again. so, the first time through, i got to 141, second time 47, and am now on 40. this time, it feels more like my documentation is coming together however. I wouldn't feel too bad submitting these 40 commentaries for review, even if not the patches themselves. ;)

at this rate, it will be years until i'm done... but its still work worth doing. i'm actually somewhat enjoying the process, even if it takes *forever*.

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.

Patch 43 commentaried!

this week was a hard week on me. still no job prospects (lots of prospects, no panning out). in addition, a car i had put in a lot of work to get got towed off while i was at akon. i'd have been notified about it, and done something, but my openmoko was a brick in dallas. to make matters worse, the car was a gift from a family member that i've been very estranged from, and would like to know better. there goes that. i got into an argument with my best friend of.. egads, 14 years? once upon a time, we were very close, now he can only stand me in "small doses", and thinks i can't even be rationally debated. *sigh*. i fear i have lost him completely, to an "its all about me" corporate speak mindset. he believes so much in the Accursed Linux Company he works for, that he's forgotten open source philosophy, and replaced it with corporate policy.

He really needs to re-read the cathedral and the bazzar.

i'm having troubles with my landlord, as well. he's moved in, and taken over half the place. he's willing to third the bills with me and my other roommate.. but he's not even helping with rent. and the kind of people he brings around...

all that, and i havent even talked about the patch!

patch 43 is the "central clearing house" of migration. it dosent do any of the migration related activities, but it handles calling the right function, and asking permission between kernels/tasks. i concider it the highest level of the migration API. and its horrid. :) rare error checking, wrapper functions that are later ignored.. it even uses 0 for success AND failure in several functions. at least thats one more patch down.

i'm still waiting on the person who popped up to play administrator to get done setting up anongit. i'm using the git tree myself, but no-one else can get at it. oh well, thats why my docs are on the website, right?

again, quite a difficult week. lost a friend, lost a chance at a real relationship with a long-estranged family member, problems with my landlord, problem with finances, and no job yet. i've got some friends who seem to want to help, but i've been in such a funk, its hard to ask for help. i don't *want* it.

heres hoping next week goes better. and that i don't take a week between posts/patches!

patch 42 commented. simple kernel Makefile fragment.

I went to A-Kon over the weekend. i got nabeshin to sign two of my books of yamato nadeshiko shichi henge! </fangirl>

seriously, I had a blast, other than having a mizerable cold that started the moment I stepped into the car to go. got lots of pics, and some neat cosplay ideas for next year. i'm still not over the cold. *sigh*

I heard back from a job i really wanted. they had a volunteer crop up to do the work they were going to hire me for, but they were impressed enough to offer to fly me up for an interview when they have another opening. so i got a "get out of the phone interview free" card. yay! :)

I've still got help with linuxpmi. maybe I'm actually doing my job as "cheif necromancer". :)

29 May 2008 (updated 3 Jun 2008 at 16:54 UTC) »

got through hunk #41 today. aparently, the new mail account i set up is broken. makes it hard to extend an olive branch to the old simple openmosix team.

technically, about a year ago, we butted heads. they wanted to drag the dev work to a more modern kernel, before geting core openmosix components stabilized. i went my way, they went theirs.. and seem to have been inactive all of 2008.

I've asked a friend to contact them, while i'm fighting my mail. I hope he's a bit more political than I am, I think I have spent too much time on irc with kernel hackers. :)

i was always of the opinion we should be documenting and fixing the current 2.6.17 tree, rather than trying to keep up with the kernel itsself. while i know the kernels dveloped some new APIs, and merged some code that we're still "maintaining" (in-kernel sockets, kgdb), I'm of the opinion that until we can prove 2.6.17 isn't going to work, we should be trying to fix our code, not introduce new bugs during repeated porting efforts.

Hunk 41 was interesting. It contains the logic for moving from kernelspace to userspace for an openmosix process, as well as several other kernel<->openmosix APIs. It seems most of the code we've added to kernel .c files calls something in this patch.

Google has indexed the new site URL. this time I disabled two trac modules that were confusing google, and that we were not using (the milestones, and the timelines). we're going a bit too slow to use them.

I'm still disapointed we couldnt come up with a zombie themed name for the project. after all, we're slowly moving forward, and looking for BRAAAINS...

oh! and we got git set up. we don't have anonymous git set up, but the usage problem isn't getting docs out (thats what trac is for), but for syncing my two laptops. and best of all, it wasn't done by me. i actually have help for a change. now, its too bad my help is so well spoken and highly educated in physics/maths. holding a conversation has a tendancy to make me feel two feet tall. :)

11 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!