Be careful what you wish for, you might just get it 🙂
Date: Thu, 12 Jan 2006 00:08:15 -0800 From: Linux Kernel Mailing List [linux-kernel(at)vger.kernel.org] To: git-commits-head(at)vger.kernel.org Subject: [PATCH] x86_64: Use function pointers to call DMA mapping functions tree b6b3b55318336adf769bf57141a01a9defbbb202 parent 8a6fdd3e912e0ce6f723431d66baf704bf8a1d26 author Muli Ben-Yehuda [mulix(at)mulix.org] Wed, 11 Jan 2006 22:44:42 +0100 committer Linus Torvalds [torvalds(at)g5.osdl.org] Thu, 12 Jan 2006 11:04:55 -0800 [PATCH] x86_64: Use function pointers to call DMA mapping functions
Muli Ben-Yehuda's journal 
Why is it the kernel of doom?
Comment by yrk — January 12, 2006 @ 11:13 AM |
my patch has been included 🙂
Comment by mulix — January 12, 2006 @ 3:54 PM |
kernel of doom
Dum Dum Dummmmmmmm!
I was actually going to switch to FreeBSD anyway… 😉
Comment by xavishayx — January 12, 2006 @ 11:35 PM |
Re: kernel of doom
Some of my best friends are FreeBSD developers. NetBSD, on the other hand – the one NetBSD developer I have the misfortune of being acquainted with is a complete and utter ass.
You know you’ve been doing this open source thing for a loong time when you pick the programs you use based on who developed them.
Comment by mulix — January 13, 2006 @ 11:25 AM |
But function pointers are *bad*!
Comment by taral — January 13, 2006 @ 7:14 AM |
err… why?
Comment by mulix — January 13, 2006 @ 11:25 AM |
I was making fun of some people, but I don’t blame you for not recognizing it. Function pointers are bad in that they block speculation, requiring an effective pipeline flush. Almost certainly not an issue for you, and, in my opinion, pretty much not an issue ever, but some people claim it is and seem to do a lot of convoluted work to avoid them.
Comment by taral — January 13, 2006 @ 3:17 PM
Definitely not an issue for this patch – I went through a bit of trouble at first to keep the “default” path through the DMA ops function pointer free (i.e., added an
if (unlikely(ops->func)
ops->func(…)
else
default_func()
). gcc knows which path is going to be taken (via unlikely) and the CPU should be smart enough to speculate correctly. Then Andi Kleen made everything go through the ops function pointers. If he thinks it’s acceptable, I’m certainly happy.
Comment by mulix — January 13, 2006 @ 3:29 PM
w00t w00t!!!
Comment by omerm — January 13, 2006 @ 2:41 PM |
Muli, x86_64 needs to be stable
We plan to use it here at work for our product, so please..
Just kidding. Keep up the good work 🙂
Comment by da_x — January 24, 2006 @ 9:29 PM |