Em Tue, Mar 02, 2010 at 05:46:03PM +0100, Paolo Bonzini escreveu: > On 02/26/2010 03:23 PM, Ingo Molnar wrote: >> I do think tools/X and tools/libc would make quite a bit of sense - this is >> one of the better design aspects of FreeBSD et al. It's a mistake that it's >> not being done. > > I don't see what it would buy to have tools/libc. You cannot force > users to update kernel-space and user-space in lockstep (Apple forced > you to do that sometimes when I used Macs at work, and it was very very > inconvenient), so it's not like libc would be able to always assume the > latest system calls. There is (relatively) a lot of > backwards-compatibility code in libc; it's ugly code, but you have to > live with it. > > Any case in which you need lockstep upgrades of kernel and libc for > bisectability is a bug in libc, and I haven't seen it happen enough to > be a problem. You imply lockstep updates because both are on the same source tree? I don't see why that would be required, there is an ABI contract to be respected no matter where the sources for the signatories live. perf lives in the kernel sources and while developing it I use all sorts of combinations of userland and kernel perf bits so as not to be rebooting the many machines of different arches where I test the userspace bits all the time with a new kernel, even if it indeed has new in-kernel perf bits. As an instance where I could have worked on tools/libc recently was the recvmmsg syscall I introduced. Till it got into glibc (IIRC it was, but I wasn't involved in it, google alert told me) interested parties had to use 'man syscall' and pick the syscall number for their specific architecture, etc. I could've done both the kernel and userspace bits in the same patch. - Arnaldo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
