Keir Fraser wrote:
Yeah, point is the interface is normal C API, and has the similar free
form that normal kernel API's have.
i think this sounds very sane, and an OS-specific interface shim gets
around problems such as finding CPU-specific state -- we can get at
smp_processor_id() just the same as the rest of the kernel, for
example. We could extend the concept of the interface shim we already
have -- a set of OS-specific high performance shims, plus a fallback
OS-agnostic shim.
Getting at smp_processor_id() is exactly the type of thing you _don't_
want to do. You really can't have callbacks into the guest in the
hypervisor platform layer. It really is not efficient, and you cause
yourself more trouble than it is worth.
And where exactly is smp_processor_id() exported to modules? It's not.
You've just locked your module into the current kernel's idea of how to
get at smp_processor_id(). It changes based on compilation options of
the kernel - for example, it is different with 4K stacks. It has
changed from a number of other different options in the past.
The fact that XenoLinux needs smp_processor_id() at all is quite
ludicrous. To disable interrupts, which is used fairly commonly to
disable pre-emption as well, what does XenoLinux have to do?
It has to disable pre-emption to call smp_processor_id() so that it can
disable interrupts, the re-enable preemption so that it can disable
pre-emption.
That is truly convoluted, and is exactly why you should never get into
these types of situations to begin with.
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]
