Older blog entries for Zaitcev (starting at number 161)

mulix:

For 2.5, you must send patches to a designated subsistem leutenant instead of Linus. In your case that would be Perex@suse.cz (Jaroslav Kyzela), unless you want to support the OSS part. That one is tougher, because nobody cares about it. Since it's a god forsaken subsystem, I do not remember who takes care of that. You might want to try a generic patch aggregator, such as DJ or Trivial (if the patch is trivial).

I still remember good old times when you could send a patch to Linus and expect it to get in, but it is a matter of folk legend now.

== From the desk of a fellow ymfpci maintainer.

One point about the Sun Java memo which I do not see discussed is how a project never generates fixed releases, but incorporates fixes into new releases instead, together with scores of new bugs. Apparently, certain dynamics made this effect devastating for JRE on Solaris/sparc. This does not mean other projects in general and free software in particular are immune to it. My personal expirience suggests that GNOME suffers from this a great deal. Getting bugs wontfixed is the norm, probably because the monkey people have no resources to triage bugs, fix, QA and ship them (my last bug treated this way was 57453, though I recall it happening before).

For the Linux kernel, the whole problem is addressed with the dual-track odd/even releases, and with an economic model which allows vendors to support old kernels. The mechanism is imperfect still. For instance, Red Hat had to switch ancient 2.4.7 and old 2.4.9 based distros to 2.4.18 stream with an update, because it was not possible to retrofit fixes into those codebases, given the resources. I think what former Javasoft does may be likened to Red Hat shipping kernel 2.5.34, because it was "current" at the moment of the release. The scary part is that it's not impossible. My memory is getting fuzzy, but I think Red Hat shipped something like 2.1.59 once upon a time. I guess we improved a bit since then... I am sure Sun can improve, too, if only they wanted.

Indeed, Advogato looks like crap on Mozilla with Xft, which comes with Red Hat beta Phoebe. I borrowed advice from jooon with great many thanks. Only I did not want to bother with any Java fonts with dubious licenses, so I added the following to my ~/.font.conf:

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
    <!-- From http://www.advogato.org/person/jooon/diary.html?start=18 -->
        <match target="pattern">
                <test qual="any" name="family">
                        <string>Lucida</string>
                </test>
                <edit name="family" mode="assign" binding="strong">
                        <string>Luxi Sans</string>
                </edit>
        </match>
</fontconfig>

Good news: s390

My s390 runs 2.4.21-pre3 with RH patches, which is nice. I'll get s390x going and send rmap updates to Riel.

Bad news: USB

IBM report that my fix for the initial USB caps lock does not work for them. This is entirely unexpected. The bug was obvious, and the fix was obvious, I tested the result, and Vojtech approved it. Userland is not involved. Something is very fishy here...

What a day. Some time ago, I had to port tg3 to an upcoming product, and since the locking was different, management decided that it would be more reliable to ship it as alternative driver, rather than the primary. Just to be safe, you know. So, guess what, nobody ever tested the alternative, until yesterday, when it turned out that it did not work at all. By a succession of miracles, I made it working in a day, but it was disappointing, because it was completely preventable. Every time such an alert happens, I lose momentum. Hmm... What was I doing on Wednesday? Was it s390? Can't remember now. :0

My diary rating continues to climb for no reason, and it's about time to do somehting about it. To that end, here's my views on the war with Islamists.

The war is a perfect example of denial of reality when it is too hurting. Leftists simply deny that they all will die prematurely if Islamists are not stopped, because most of leftists are good people. They cannot comprehend the scale of murderous villany which engulfed the Middle East. It is unreal to them, they do not believe that no matter how much we appease, help the poor, donate hospitals and schools, etc., it is all in vain. I think Raph is one of those good natured and tragically misguided souls, and it's sad.

In other news, I am confronted with a port of rmap to s390. It may not be a big deal, but only if PMD entries form full pages on the platform (crossing fingers).

Val's re-emergence to linux-kernel is off to a bad start, pushing agenda with which we are all too familiar. Honestly, I expected better.

Sparc saw a thremendous progress over the weekend. I did not do much, only changed 3 or 4 lines in sunzilog.c, but this removed old the chokes from my wheels. It was a little tough to debug kernels without a console output. I used JavaStation (PCI based) to keep with Linus' pace, but recent (~ 2.5.49) breakage in NFS client made it problematic. And all SMP boxes are SBus based, anyhow.

Turned out we shipped a beta (Phoebe) with broken USB, but I think I fixed it, thanks to Bill Nottingham's help. Good thing it was a beta, and not a product! Now crossing fingers and barring gates against 11th hour vital features required by product management.

I did some other USB work, sent a patch to Vojtech. Hit CapsLock on PS/2 keyboard, then plug a USB keyboard into a box. The light on USB keyboard won't lit. Hit NumLock. Now both will come on! Trivial, but apparently annoys the hell of KVM users.

Meanwhile, sparc languishes. I wish I had Alan's productivity. Or DaveM's.

I remember that some time ago I posted a diary entry "Jerks from Gentoo", where I vented against an article at "Gentoo Linux News", which took a dim view of my work, berating me for not submitting patches up to Marcelo fast enough. At that time I thought that "Gentoo" was an online rag. Turned out that they were a distro maker! Now it all falls into place.

    Daniel Robbins recently proposed a new kernel development strategy for Gentoo Linux, with the main goals being to improve hardware support and stability of the kernels used in the Gentoo project. As part of this strategy, Gentoo would leverage many of the hardware patches that make their way into the Red Hat kernel tree since most hardware vendors seek out Red Hat as their primary/only Linux partner. In addition to taking advantage of the improved hardware support in the Red Hat kernel source tree, Gentoo users would also benefit from additional features and functionality not normally found in the Red Hat kernel, including XFS, EVMS and Win4Lin, as well as others.

So, no volunteering to help me to split patches and merge with Marcelo, or is there? How quaint. They just realized that they do not have to pretend to be working for the community benefit. Why help to merge upstream when you can take the whole thing? Not that many believed them, anyway.

BTW, the idea to ship EVMS when its creators decided to switch to LVM2 smacks of an attempt to "diffirentiate" at any cost, without an attempt to help users at all. Apparently, nobody thought what is going to happen to RAID arrays of Gentoo users in EVMS on-disk format in about a year, when kernel 2.6 rolls out.

Dunno what made me wound up so much about this. I guess I care a lot about my and Red Hat's community role.

In kernel 2.4.18 or so, if two Token Ring boards are used in a SMP computer, a lock-up happens. IBM asked me to look at a patch by Denis J. Barlow which was said to fix the lockup. The patch was too big and touched too much code, so I figured what it did to locking and wrote a small patchlet which fixed it. Today I received a mail from Arnaldo (the maintainer of weird networking stacks) which said that someone else did exactly the same thing for 2.5 already, so he is taking the patch and sending it to Marcelo. In a year or so we'll know if it actually worked...

I am a little sad to see all the rest of Denis' patch to fall by wayside, but he is stubbornly refusing to split it into manageable chunks.

Another moral of the story is: Avoid exotic locks, such as spin_lock_bh(). The "my" patch simply replaces spin_lock_bh with spin_lock_irqsave. Why did the author use spin_lock_bh in the first place? I place the blame squarely on premature optimization.

Somewhere in August, Robert Love wrote an article in Linux Journal about Linux locks. It was an honest article, which listed all lock varieties and even tried to explain how to use them. When I read it, I thought it was a wonderful article; the only omission I noticed was that he did not mention that semaphore down() cannot be used in an interrupt. But guess what, about a month ago, Grant Edwards, a comp.os.linux.development.system regular, made a posting where he told he was going to use exotic locking. He wrote that he went through RML's article, and so, everything was going to be ok, because he'll use those correctly. I had to step in to direct him to sane locking. Of course, his code would be correct - in that particular version of the kernel. One step left, one step right, and it bitrots. Just like Token Ring did.

I extend the KISS phylosophy way beyond spin_lock_bh, into the realm of reader-writer locks. They can improve performance of contented locks a lot, but they are rife with pitfalls. In this regard Bill Irwin grieves me especially, because he advocates using reader-writer locks by default while being sharp and respected. He probably corrupted minds of hundreds of newbie driver writers. He does not understand that they are not ready for the sophisticated stuff.

Newbies need something simple instead, which may not be the most scalable, but working robustly, like a set of these "Zaitcev's Commandments":

  • If you are in a process context (any syscall) and want to lock other process out, use a semaphore. You can take a semaphore and sleep (copy_from_user or kmalloc(x,GFP_KERNEL)).
  • Otherwise (== data can be touched in an interrupt), use spin_lock_irqsave and spin_unlock_irqrestore.
  • Avoid holding spinlock for more than 5 lines of code and across any function call (except accessors like readb).

That would be it. Just keep it simple. Any of these rules can be broken under some circomstances, but the problem is that newbies cannot judge adequately. This is why they are "Commandments", to prevent them from confusing themselves.

Today, Advogato article system was DoSed by our local DCE and Microsoft worshipper. It was pretty funny, because it reminded me about my buddy Sergey, who went to work for Microsoft and got assigned to support DCE. His comments about the code were quite entertaining, if a little harsh.

152 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!