Older blog entries for Zaitcev (starting at number 135)

The sparc in 2.5.30 boots now to the point where init enters level 3, and promptly runs out of so-called "nocache memory". This is a significant achievement in my book.

KT noticed last week that sparc was marked unmaintained. Actually I asked Rusty and DaveM about this, but we decided to stick with de-facto maintainership for now. This way I always can fall off without warning. Also it's interesting to experiment how soon people wise up to the fact that Linus bk tree can be compiled and runs (somewhat :). uzi already figured it out, but I asked him not to spoil the joke for the moment.

Seagull hackery, yes!

I see more and more people who describe their struggle with booting from a software mirror, one of them even found his way to Advogato. I struggled with them during my Sun tenure for years, and now they are catching with me again. When will they learn that it is a very bad idea?

For intelligent Advogato readers, I would like to point out that booting from a software RAID presents a chicken and egg problem fundamentally. To read a boot image you need the RAID software, and to load RAID software you need a working OS. This is the main problem.

It is possible to break the loop, but the result is invariably fragile. It any little piece of the puzzle falls out of its place, the whole scheme crumbles. The most dangerous thing about it is that very often you get to discover how it breaks when it is time test your mirror in a degraded mode. If may be way too late to reconsider at that time.

If you really want to have your root filesystem on a software RAID, boot from some other place, then remount or pivot your root.

I am digging into the Anton's inheritance that I've got. Some parts of it are pretty witty...

/* This makes sense. Honest it does - Anton */
#define __nocache_pa(VADDR) (((unsigned long)VADDR) - SRMMU_NOCACHE_VADDR + __pa((unsigned long)srmmu_nocache_pool))
#define __nocache_va(PADDR) (__va((unsigned long)PADDR) - (unsigned long)srmmu_nocache_pool + SRMMU_NOCACHE_VADDR)
#define __nocache_fix(VADDR) __va(__nocache_pa(VADDR))

OLS: unintended consequences

At the conference, I bumped into Quintela and he said: "Oh by the way, I still have two JavaStation Krups, they run [something very ancient]". Later we had a sparc(32) mini-BOF with Rusty, WLI, Uzi and Anton (as a guest of honor :). Rusty delivered a short, but energetic speach, in which he threatened to throw the port out of the kernel tree if it does not get updated (I advocated such action at one time myself).

Of course, I am not afraid of Rusty, or not sufficiently afraid, anyhow. OTOH, to win the dubious honours of the only architecture requiring syscalls for futexes... and coding special traps for them... hmmm... I do not understand how it happened, but I fixed up 2.5.24 to compile on sparc and DaveM was going to take the patch into the vger tree.

This is all fine and dandy, but we still do not have anyone to take over the DaveM's mantle. WLI has some serious Linux work at IBM, and so does Anton. At best they can perform so called "seagull maintainership" (I stole this term from Willy). Uzi may do it, but something interfered when he tried. Elsewhere we have Tom Sczerpe (sp?), and Spot. I am not exactly sure about them. Spot definitely has an access to a sparc64, and it may be too much of a siren call. Oh well... I'll just keep a tree alive in case anyone decides to take over.

OLS: wireless

Wireless during OLS was nothing short of fabulous. The only problem I saw or heard about was pump(1) dying on laptops of some participants, and thus failing to renew leases. Once the IP is reassigned to someone else, it conflicts. Happened to me once; of course I have no idea who caused it. Everything else worked flawlessly, including migration between rooms and floors (which typically caused dropoffs last year). Rooms were packed even more than this time around, so I am surprised at the better infrastructure quality.

I saw dyork writing how good is 801.11 at Mac. Perhaps it is, but I can top his story. He did "two simple downloads", I did none. I took an obsolete 486/75 laptop, installed Red Hat 7.2, and asked Arjan to lend me a card (which he bought apparently before boarding the plane in England). Everything else worked automagically. So, I think MacOS and OSX enthusiasts need to find some other topic for bragging. Fonts, perhaps?

I am in a hacking frenzy, so no OLS updates. Also, hardlinked trees rule. I just realized that "cp -al" creates perfectly good hardlinked trees without any mucking with find(1) and ln(1). RTFM.

This year OLS had so much personal content that I am going to write it down in small installments.

OLS: bk

Recently I observed that many kernel hackers switched to bk and seem to be genuinely satisfied with it. So [sic], I decided to use it too, and was frustrated. The whole expirience was an unending pain (even though I was good with Teamware during my Sun tenure). I really could not understand what was going on. Why it's ok with everyone except me? Was I really that dumb? Then I had an extremely enlightening conversation with Val Henson and it clicked.

We started off with considering workflows ('I do this *scribble* then copy the tree like this '*scribble*' 'This is what I did too'), then went on to advantages of bk, which I promptly dismissed ('Sure, mergetool is brilliant, but I never get big rejects'). Eventually Val got tired of me and asked: 'If your tar/diff/patch workflow works so well for you, what area are you trying to improve, exactly?'

Yeah, what, exactly? I started to think about it and realized that I totally fell victim to the "instinct of the herd", because I was psychologically insecure. To say "gregkh and jgarzik use foo, therefore foo must be good for me" was bogus. I made no analyzis and grabbed a fad instead.

I wrote a couple of diaries ago that a kernel hacker can live off FTP releases quite decently. In view of that and of what was said above, I am dropping my attempts to use the bk for now. Of course, once I hit dreaded merging difficulties, I'll be over the fence in a jiffy.

BTW, I am much happier now when I do not have this bk inferiority complex anymore. Which can only be a good thing.

mbp: Re: exceptions. How do you handle this:

int foo() {
    do_something();
    if ((x = bar()) == NULL) goto error_bar;
    if ((y = baz()) == NULL) goto error_baz;
   .......

    // undo_baz();
error_baz:
    undo_bar();
error_bar:
    undo_something();
    return -1;
}

An awful lot of code relies on falling through labels. With exceptions you have to re-raise it again and again. And IMHO, "finally" is a dangerous concept, in fact many Java oldtimers suggest that almost every instance of it is a bug.

OLS: I am digesting my OLS expirience and will post as appropriate.

At OLS and busy - diary later.

Re: pphaneuf and bcrl's aio, very briefly.

I suspect that we will hear from the pro-callback party yet at times. I may be mistaken, but it seems than many of those people honestly fail to account for two things: a protection boundary crossing and an existence of contexts in UNIX, and also the performance. This is very fundamental and explains why bcrl chose the non-callback interface (as opposed to Windows APC, as I was told). I did the same for Toy Infiniband Stack and had all these discussions at length with the leading Intel architect Ashok Raj.

Suppose for a moment that you try to implement the callback. You absolutely have to take over a process for it to run. You can not take over a random process due to protection differences (not to mention address space overlap, etc.). If the process you want to hijack runs wild in userspace, it must be pre-empted. No matter how you slice it, it is costly and hurts performance, and pulls the rag from under the process (e.g. pre-empting malloc and doing malloc from the callback). If a process deliberately sleeps in kernel, it is only a simple and fast wakeup. In a way, callback emthusiasts may consider forked waiters as a pool of anonymous contexts, it that helps them to feel comfortable.

I hope that it makes some sense. Later. We may yet have a hallway BOF during the last day.

I am wondering what genius came up with the idea to make the OLS a follow on for the Kernel Summit. First, it allows some first rate hackers to demonstrate exactly how low they value the OLS by attending the summit and leaving the town when OLS opens. Second, those who remain will be tired. Even though OLS is mostly about drinking, they will. Or more so.

In a way Tytso sends some very negative vibes with the KS for little benefit.

I say negative, because KS invitations are open for corruption. A good friend of mine and a port maintainer offered me once over a dinner to ask Tytso for an invitation. He obviously had good intentions and valued my kernel contribution too high, but still. I think KS erodes the meritocracy underpinnings of the kernel hackerdom.

As for the purported benefit, last KS pretended to discuss and approve some things, which obviously were doomed, were empty promises, and so on (e.g. Andre's IDE, ESR's CML2, Keith's kbuild). I cannot recall a single thing bandied around on the KS that came out good. Well, we can hope for the tight 2.6 schedule still, but that's about all, and has a very slim chance.

Having read what I wrote, I am sure someone will accuse me of having sore grapes over not being invited. I am not saying yeah or nay, but what if I would. It would only add a weight to the argument that KS creates an easy channel for destructive negativity, just like Dimwit rating on Advogato. If people used Dimwit right, it would work great. But of course they never did.

Another scary specter that KS recalls in my mind is a BSD core group. It was said that BSD splits when someone gets thrown out from the core group. Do we really want all that govermentalist shit? Personally, I was very happy with merry anarchy and a pinhead God.

All in all I was not going attend OLS this year, but when Bob Woodruff set up the Infiniband BOF I really had to. At least Red Hat promises to cover expenses this year.