* Zachary Amsden <zach at vmware.com> wrote: > [...] I can't comment on Ingo's patch as he failed to -cc me on it, it's on lkml, i'll bounce it to you separately. > despite the fact that we are the only ones affected by it. [...] actually, no, my motivation for it was KVM (a Linux based hypervisor and its paravirtual interface). You said that VMI wont hinder Linux development and design in any way and can adopt to whatever change the upstream kernel does, so i'm taking your word for that. > [...] We are not concerned so much with supporting legacy user land > deployments, as we expect for the most part, the install scenario to > happen when upgrading to new distros. that's not really the right argument. This obviously affects the host kernel too if it has CONFIG_PARAVIRT enabled. The other option is the removal (or temporary disabling) of the whole CONFIG_VMI and CONFIG_PARAVIRT stuff if you cannot get into minimal release shape, it's experimental stuff after all. > What we really need to do is to be able to detect an old user land and > drop VDSO support when that is found. [...] no. What you need is to keep existing mechanisms and not hack off the vdso and CONFIG_COMPAT_VDSO... > [...] But since we can't do that, the next best thing is to allow the > hypervisor to choose whatever workaround it wants when it moves the > fixmap and compat_vdso was enabled. In our case, the workaround we > will want is a boot option to disable VDSO for old user land, [...] there's no need to disable the VDSO for old userspace ... Ingo
