On 09/17/2007 11:22 PM, Adrian Bunk wrote: > On Mon, Sep 17, 2007 at 10:33:07PM +0200, Oliver Falk wrote: >> At Alphacore we used to patch the kernel headers for a while now; We >> added syscalls __NR_openat (447) until __NR_tee (466). > > Why did your numbers differ from the numbers that were used in the > upstream kernel?
Afaik, our patch was done a while ago and nobody every submitted it upstream - don't know why... At AC, we follow RH/Fedora packages and there we had glibc-kernheaders - where our patch originates. When the glibc/kernel packages changed and glibc-kernheaders died, I patched the syscalls into kernel headers; Not thinking that I better submit it upstream. :-( > The Alpha maintainers (Cc's added) might now better what happened here. > >> However, since 2.6.23 these syscall where added upstream, but with >> different syscall numbers; What happens is the following: >> ... > > These syscalls were added in 2.6.22, not 2.6.23, and are therefore in > the officially released kernel since more than two months. Yes, 2.6.22, I've just encountered the problem with 2.6.23... > Changing a userspace ABI that has already been part of an officially > released kernel because someone patched other syscall numbers into his > private kernel doesn't sound like a good solution. As I wrote in my previous mail, that's true, but if Debian folks haven't recompiled glibc against the new headers we can change it without breaking something... -of - 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/
