> VDSO is only a problem if (1) the hypervisor wants to reserve the top > virtual address space (CONFIG_PARAVIRT=y), and (2) the glibc is old and
It broke the boot even with native hardware, no hypervisor > > +config RESERVE_TOP > + bool > + help > + Many hypervisors want to reserve some amount of the top of > + virtual address space. Unfortunately, old glibc needs the > + vdso page there, so we must disable vdso if COMPAT_VDSO is > + enabled as well as this option. But this still means I would need to decide between a PARAVIRT kernel that either supports xen/VMI or cannot boot old user land without weird options. I don't think that's the correct solution. The goal is a single binary that runs everywhere and is still compatible. What would probably work is to somehow decide at runtime if a hypervisor is there or not and then set vdso default based on that. I guess that detection would be hypervisor specific though and probably would need paravirt ops extensions. -Andi - 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/
