Pavel Machek wrote:
Well, I guess we'd like VMI to be buildable in normal kernel build
tools ... and at that point, open sourcing it should be _really_ easy.
And we'd prefer legal decisions not to influence technical ones. Maybe
we will decide to use binary interface after all, but seeing GPLed,
easily-buildable interface, first, means we can look at both solutions
and decide which one is better.
I don't think you're actually arguing for the VMI ROM to be built into
the kernel. But since this could be a valid interpretation of what you
said, let me address that point so other readers of this thread don't
misinterpret.
On a purely technical level, the VMI layer must not be part of the
normal kernel build. It must be distributed by the hypervisor to which
it communicates. This is what provides hypervisor independence and
hardware compatibility, and why it can't be distributed with the
kernel. The kernel interfaces for VMI that are part of the kernel
proper are already completely open sourced and GPL'd. The piece in
question is the hypervisor specific VMI layer, which we have not yet
released an open source distribution of.
We do use standard tools for building it, for the most part - although
some perl scripting and elf munging magic is part of the build.
Finally, since it is a ROM, we have to use a post-build tool to convert
the extracted object to a ROM image and fix up the checksum. We don't
have a problem including any of those tools in an open source
distribution of the VMI ESX ROM once we finish sorting through the
license issues. We've already fixed most of the problems we had with
entangled header files so that we can create a buildable tarball that
requires only standard GNU compilers, elf tools, and perl to run. I
believe the only technical issue left is fixing the makefiles so that
building it doesn't require our rather complicated make system.
Hopefully we can have all this resolved soon so that you can build and
distribute your own ROM images, see how the code operates, and use the
base design framework as a blueprint for porting to other hypervisor
implementations, porting other operating systems, or just as a general
experimental layer that could be used for debugging or performance
instrumentation.
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]
