Patchwork klibc sparc sockets foo

hello dave,

could you have a look at this sparc klibc trouble:
ipconfig: eth0: socket(AF_INET): Function not implemented

git clone git://git.kernel.org/pub/scm/libs/klibc/klibc.git

and review belows proposed fix?

thanks
maks


commit 4d0c11edfdad0493d97466b00e75b33786bab762
Author: jeremy buisson <jeremy.buisson@st-cyr.terre-net.defense.gouv.fr>
Date:   Wed May 27 08:57:23 2009 +0200

    [klibc] sparc64: fix bad 32 bits socket syscalls
    
    
    The 32 bits version of socket-related syscalls for sparc/sparc64 does
    not seem to conform to the interface provided by the kernel. As a
    result, klibc-utils commands such as ipconfig ends with a "ipconfig:
    eth0: socket(AF_INET): Function not implemented".
    
    See bug #444087 for the log with an older version. See for the following
    session for another evidence of the problem with a newer version:
    jeremy@sunny:~$ /usr/lib/klibc/bin/ipconfig lo
    ipconfig: lo: socket(AF_INET): Function not implemented
    /usr/lib/klibc/bin/ipconfig: no devices to configure
    
    Looking at the source code, it seems there is 2 call mechanisms:
    - if the kernel header files (asm/unistd.h) defines __NR_socket (and so
    on), the makefiles uses the syscall interface ;
    - otherwise, the makefiles uses the socketcall interface, which wraps
    the call into a common syscall (named socketcall).
    See the <src>/usr/klibc/syscalls.pl and <src>/usr/klibc/socketcalls.pl
    for details.
    
    Looking at the kernel source code for the 32 bits syscall table for the
    sparc64 architecture <src-2.6.26>/arch/sparc64/kernel/systbls.S, we see
    at index __NR_socket (97 according to asm-sparc/unistd.h and to
    asm-sparc64/unistd.h) that the entry points to sys_nis_syscall. Looking
    in <src-2.6.26>/arch/sparc64/kernel/syscalls.S, it branches to
    c_sys_nis_syscall, which (<src-2.6.26>/arch/sparc64/kernel/sys_sparc.c)
    returns ENOSYS, the error code for non-implemented syscalls.
    
    According to my quick tests, there are 2 workarounds:
    1) compile klibc to sparc64, as the 64 bits syscall table of the kernel
    provides the direct socket (and related) syscalls
    2) patch klibc such that it uses socketcall when targeting sparc(32).
    
    
    http://bugs.debian.org/444087
    
    Here is a sample patch for the 2nd option:

--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Well, on sparc32 we implement sys_socketcall() and on sparc64 we don't
and instead provide the direct system calls for things like that.

What's the trouble?
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

From: David Miller <davem@davemloft.net>
Date: Sun, 14 Mar 2010 15:06:38 -0700 (PDT)

> 
> Well, on sparc32 we implement sys_socketcall() and on sparc64 we don't
> and instead provide the direct system calls for things like that.

Wait a second, both sparc64 and sparc32 provide sys_socketcall.

Look in the compat syscall table for sys32_socketcall and in
the native 64-bit one we have sys_socketcall.
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

From: David Miller <davem@davemloft.net>
Date: Sun, 14 Mar 2010 15:35:40 -0700 (PDT)

> From: David Miller <davem@davemloft.net>
> Date: Sun, 14 Mar 2010 15:06:38 -0700 (PDT)
> 
>> 
>> Well, on sparc32 we implement sys_socketcall() and on sparc64 we don't
>> and instead provide the direct system calls for things like that.
> 
> Wait a second, both sparc64 and sparc32 provide sys_socketcall.
> 
> Look in the compat syscall table for sys32_socketcall and in
> the native 64-bit one we have sys_socketcall.

The fact of the matter is that on sparc64 some, but unfortunately
not all, of the socket system calls are provided natively.

However, in my tree for sparc64, unlike the klibc commit message
claims, I do in fact see sys_socket provided in slot 97.

/*90*/	.word sys_dup2, sys_nis_syscall, sys_fcntl, sys_select, sys_nis_syscall
	.word sys_fsync, sys_setpriority, sys_socket, sys_connect, sys_accept

But things like sys_bind do not appear in the sparc64 syscall
table.

So probably the best thing to do is, like the commit presented
at the top of this thread, use sys_socketcall unconditionally.
From some simple tests this is what glibc does too.

But the factual errors in the commit message need to be fixed
:-)

--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On 03/14/2010 03:45 PM, David Miller wrote:
> 
> So probably the best thing to do is, like the commit presented
> at the top of this thread, use sys_socketcall unconditionally.
> From some simple tests this is what glibc does too.
> 

It's worth noting that if the syscall number macros for unimplemented
system calls are removed, then klibc will automatically use socketcall
for the remaining calls.  It is always a major headache when an
architecture breaks automation by advertising a system call and then not
actually implementing it.

	-hpa
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html