On Mon, 2007-09-10 at 20:45 -0400, Mathieu Desnoyers wrote:
> Code patching of _live_ SMP code is allowed. This is why I went through
> all this trouble on i386.
Oh, I was pretty sure it wasn't. OK.
So now why three versions of immediate_set()? And why are you using my
lock for exclusion? Against what?
Why not just have one immediate_set() which iterates through and fixes
up all the references? It can use an internal lock if you want to avoid
concurrent immediate_set() calls.
I understand the need for a "module_immediate_fixup()" but that can also
use your internal lock.
> > 2) immediate_if() needs an implementation before you introduce it. Your
> > assumption that it's always unlikely seems non-orthogonal.
>
> I could remove the unlikely(), no problem with that. Your point about
> this is valid. However, I would like to leave the immediate_if() there
> because it may become very useful if someday gcc permits to extract the
> address of a branch instruction (and to generate assembly that would not
> be reached without doing code patching).
Why is it easier to patch the sites now than later? Currently it's just
churn. You could go back and find them when this mythical patch gets
merged into this mythical future gcc version. It could well need a
completely different macro style, like "cond_imm(var, code)".
Rusty.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
