Older blog entries for riscgrl (starting at number 15)

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". :)

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. :)

Today, I drank from a firehose.

We've been planning on re-naming the codebase we're working on from "OpenMosix", a dead project to... something. After a week and a half of getting names and options, intending on having a slow voting process, I heard a name I liked well enough to have a kind volunteer register, since no-one who'd come up with any names agreed with each other.

Aparently, that was a shot that echoed in the halls. As soon as I set it up(actually during that process), my phone started ringing, with local individuals, who prefered one of the other names. then more people on irc started popping in, agreeing. In the end, it looks like my first unilateral decision got vetoed by the community(and they say OpenMosix is dead!).

I also seem to have picked up a few more developers along the way, we'll see how long they stay. I hope my documentation comes in handy, as this was the moment it was meant for. I'd be more than glad to be relegated to the task of documenting only, instead of having all this on my shoulders.

patch 40 commentaried. you'd think commenting on a patch that contains just config options would be easy, but it isnt. found a dead entry, probably inherited from the old 2.4 "weee! wooo!" code. other than that, nothing eventful. one more down.

well, my friends have been bugging me about using a blog, instead of yammering on on IRC, so here goes!

I've stopped hacking Gnu Gift at the moment. decided i needed OpenMosix to accomplish any real Big Jobs. just in time to watch moshe bar kill OpenMosix. without even consulting the dev team, on IRC, who was working hard at the time! needless to say, this disheartening development stopped us cold. nothing like the luminary of your project giving speeches and interviews about why your product is useless, and saying some opinion based / factually incorrect reasons. (there, wasn't that politically correct?). I'm continuing on, first writing a commentary of each patch from the last 2.6 based tree. you can see my work at my "homepage", which is really just a trac wiki. i've concentrated on documentation, due to the wise saying "if you cannot explain it, you do not understand it.". i want to understand what i'm doing, before i run around trying to fix the last grevious bugs. the source tree really isn't in that bad of a shape, its just that moshe wasn't performing linus' job of "project managment" during the 2.6 cycle, and the patches show it.

there are a couple of developers other than myself associated with the project, but after moshe's actions, we're looking to rename it. take our "luminary"'s name from the project. not that we have any good ideas, as "transparent process migration" conflicts with the trusted computing module, and "In Kernel Process Migration Infrastructure" conflicts with some power managment thingie. all the good acronyms are taken.

We're still alive, on irc, waiting for more developers, or someone with a good name! :)

This month's round of patches took a while longer. basically, AMD64 porting issues, making gift build where $(builddir) != $(top_srcdir), and a few insignificant bug fixes.

Nothing too exciting, for 29(!) patches.

Not yet comitting, due to a bit of a slowdown in both the 32bit and 64bit versions. i'm thinking the sizes of my datatypes changing is killing it...

More catching up on gift's patches.

I've now sped gift up from 1.9 seconds per image, to .8. (on a P4 2.2Ghz)

The next steps of optimization have more to do with multi-tasking the extraction process, and re-using the extraction program for more than one image at a time. I'm thinking of converting the program into a tool that accepts absolute file paths of all the files to be converted on stdin, and writing to stdout the name of the file dropped to. wolfram's idea, basically. between that, and running multiple feature extraction processes at once, i should speed things up quite a bit more.

Things have been very quiet on the mailing list, I suppose it has to do with the darpa urban challenge having closed last week, and everyone being way too busy to audit my patches. Not that it matters much anyways, as I have commit access, but a second set of eyes is always a good thing.

I really wish there was more than me programming on this, especially because gift is written in C, Perl, and C++, and I normally don't touch C++ or Perl with a ten foot pole.

But, what needs done needs done. *reads O'reilly perl books/Bjarne's C++ book*