On Friday 28 July 2006 21:53, Zachary Amsden wrote: > Jeremy Fitzhardinge wrote: > > Xen relies on the kernel image being an ELF file, and it uses an ELF > > section to hold various pieces of useful information about the kernel, > > including the preferred entrypoint. It doesn't rely on entry code being > > at a specific address or anything; maintaining it should be transparent > > to, and independent from, anything else going on in head.S. > > > > Approaching the problem from the mindset "Xen relies on.." is not always > the right thing for Linux. It might make your task easier, but it makes > things significantly more complicated when you consider multiple > hypervisors. Setting the precedent that Xen can insert some arbitrary > stringified ELF section that is completely hypervisor specific is really > a bad precedent to set for Linux. I don't see a big problem with adding a paravirt ops X specific section to the ELF image. After all each paravirt client will have some code in the kernel and it's not unreasonable to let it add a custom section too. Also the Xen requirement to get some information about the kernel before building the domain sounds reasonable. At least as long as it's nicely separated, but an own section is that by definition. > When you have 100 hypervisors, all > with their own wacked out section requirements, some of which might > require things being at (overlapping) fixed addresses, you've got a > much, much worse problem than if you had a clean boot ABI spec'd out to > begin with. At least in the brave new paravirt ops world you would have code in the kernel for all of these :/ > The mindset I think we should be using and scrutinizing every patch with > is - "Is this a good thing for the future maintainability and stability > of Linux?" That's a good thing to ask, but I don't see it applying particularly to the section here. -Andi
