Christian Limpach wrote: >> Zachary Amsden wrote: >> The crazy string extraction Xen has to do to figure out hypervisor >> features from the xen_guest section - which is a really bad idea. >> Putting this in the kernel is unnecessary if you have a paravirt_ops >> initialization function which can negotiate this information to the >> hypervisor. Putting this code into Linux sets an extremely bad >> precedent by encouraging ad-hoc, hypervisor specific sections >> to be put >> in the kernel. It is ugly, gratuitous, and unnecessary change to >> Linux, Please fix your loader so this doesn't need to be part of the >> maintained Linux code: >> > > Except that the domain builder needs to know most of this information to > setup the guest correctly (initial pagetables, hypercall page) and to > check compatibility (pae, version, features). I guess we could try to > agree on a structure, but that would only hinder evolution. > We don't need such a structure at all, and if you think really hard about it, Xen really doesn't either. Why does the domain builder need to know the hypercall page from a static string in the kernel? That seems completely backwards. Shouldn't the hypervisor be telling the guest about the hypercall page, not the other way around? And why can't you check compatibility in your own hypervisor specific way inside your own hypervisor specific initialization routine, instead of putting this string table in the binary? It's just messy, and looks rife to evolve in non-deterministic ways, as checking for the presence of arbitrary strings seems posed for a forward / backward compatibility nightmare - so I think you need to ask yourselves - is it really a good idea to put into Linux? The only field that actually does anything useful is the VIRT_BASE field, and there is no reason it needs to be an ASCII string instead of a number, in fact, is is very much better off being a field in the kernel's ELF header. Zach
