Older blog entries for Zaitcev (starting at number 128)

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.

Today I decommisioned the last sparc in the house. I still can cross-compile Sparclinux kernels, and I keep old userland in case JavaStation needs an urgent attention, but I cannot build PROLL myself anymore. The 32 bit sparc was a toy for BSD people for a while. They are good at using obsolete computers, so let them bother, while Linux people move on to the best and latest hardware (such as Infiniband, wink wink wink :).

[Update: A terrible thought just occured to me. Since the Classic is not in production use anymore, I can use it for experiments. The temptation!]

The Sun eclipse was cool.

I received my JNCA-5 chart from Sporty's and already extracted some benefit from it. A year ago, paxing on Air Canada on a return leg from OLS, I saw an airport with crossing runways. A scan of Airnav turned out nothing. A goverment conspiracy or Airnav problem? The chart has it, under the name "Crow Landing".

[update: I just talked to acme and he dropped cert for Anarchy]

Infiniband

I am in agony. I just finished a milestone: my Micro Subnet Manager assigns LIDs, so I turned my attention to multicast and, thus, to Subnet Administration.

The amount of crap in this part of the spec is staggering. Worse, the structure of the problem seems to require an enormous daemon, which keeps the operational status of the subnet. DHCP daemon, move over. Hell, this thing may rival BIND. Of course, there is nothing in this job to cause an agony in someone forged in the furnace of Fibre Channel. But I agonize over a simple choice: what language to use?

The Micro SM was written in C, because I had visions of better compartmentalization and UNIX style components. But perhaps the beast daemon calls for Python. But I do not know Python. But the best way to learn a language is to program a big project in it. But Python may turn off contributors. Heck, I better go play Pikmins...

So, the United Linux thing.

One well known community leader said (IIRC): It'll be curious to see Andrea and Rik to work on the United kernel 8-)

I had an opportunity to poke my curious nose into the BSD universe. I prepared an RPM of a program called mptable, which prints APIC related control blocks on x86. My collegue Doug Ledford added a printout of other control block, called $PIRQ, and I had a fancy to contribute that code. Doug put it under BSD license. So, I went to freebsd.org and read the guidelines for contributors. Instead of posting patches to a list They request all patches to be filed as bugs (called "PR" in their bug system), and so I did. I am intrigued, what happens next. I would not be surprised if all such bugs get ignored until patches rot and cease to apply, then someone closes them, by the SOP. I observed that Dillon simply posts his changes to freebsd-hackers, but hey... I am not Dillon, I cannot just barge into their social fabric :)

I have no idea why alan got a second account. I think it was an experiment with case sensitivity of Advogato accounts.

I do not have stats, but I suspect that Advogato readership is growing still, because I get requests to update diary more often. I am not sure it would be a great idea. Side by side with raph's profound entries my ones seem like a contribution to poor S/N. For instance, do not expect any explantions about Red Hat patent policy from me (Mark Webbink has this job :) Now, Infiniband may be interesting to the community, so I'll post updates about it now and then.

If I think of something groundbreaking, I'll let the world know, not to worry.

Mental note: create a vanity domain.