Arjan van de Ven wrote:
On Tue, 2005-11-15 at 08:04 -0800, Zachary Amsden wrote:
Gerd Knorr wrote:
Yep, extending alternatives is probably better than duplicating the
code. Maybe having some alternative_smp() macro which places both
code versions into the .altinstr_replacement table? If that sounds
ok I'll try to come up with a experimental patch.
i.e. something like this (as basic idea, patch is far away from doing
anything useful ...)?
You still need to preserve the originals so that you can patch in both
directions.
why do you insist on both directions? That still sounds like real
overkill to me.
It's not overkill in the virtualization context, and there are
(struggling, but infinite possibilities) opportunities for native here
as well. Run-time SMP->UP->SMP can benefit hotplug (albeit slightly).
But once you have a basic, generic mechanism for run-time code
modularization, there is very little cost to adding other features.
Run-time PAE / non-PAE conversion is far more radical, but not outside
the realm of possibility - and useful (in both directions) for memory
hotplug. Run-time CPU vendor migration is possible, if you, say hotplug
an AMD chip into a previously Intel socket.
Sure, most of this is science fiction. But the possibilities are great
- it's another tool you can use towards modularizing functionality -
specifically, scattered functionality like CPU instructions, spinlocks,
and MMU operations that really do deserve to be inlined, and really can
benefit from taking advantage of faster hardware instruction sequences.
That the tool already exists in a limited form means that with natural
extensions, it could easily be refined to allow bi-directional or
multidirectional run-time choices.
Basically, it removes a lot of the barriers that force configuration
time choices on the running kernel, and you can start to look at even
deeply entrenched parts of the kernel as modular.
Zach
-
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]
