linux-kernel - Re: asm-generic/unistd.h and glibc use of NR

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <201009281813.56443.arnd@arndb.de>
Date:	Tue, 28 Sep 2010 18:13:56 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	"Joseph S. Myers" <joseph@...esourcery.com>
Cc:	Chris Metcalf <cmetcalf@...era.com>, linasvepstas@...il.com,
	linux-kernel@...r.kernel.org, libc-ports@...rceware.org,
	andrew@...esourcery.com
Subject: Re: asm-generic/unistd.h and glibc use of NR_ipc

On Tuesday 28 September 2010, Joseph S. Myers wrote:
> (Removing libc-alpha as my comments aren't relevant to that list.)
> 
> Two of the three seem rather surprising to me as regards glibc ports being 
> ready to merge - maybe kernel ports are ready, however, it isn't clear to 
> me what (kernel or glibc) the original comment was referring to.

I was talking about kernel ports.
 
> C6X has no MMU so a glibc port isn't a possibility.  There are indeed 
> uClibc and GCC ports we will be contributing in due course - but the 
> linker support for shared objects is still in development (I contributed 
> the static linking binutils support upstream earlier this year) and is 
> required for building anything for uClinux userspace for this platform.

Right. Obviously the same question exists for uClibc though: The C6X syscall
ABI will need to be rewritten (as in deleted and replaced by generic
code) in the kernel in order to get merged, so the uClibc port will
have to gain the same kind of generic API that we need for glibc.

> As for Nios II, we have a fully functional glibc port at CodeSourcery.  
> It is I believe all our own work so there are no legal obstacles to our 
> contributing it to the FSF - but upstream contribution would not really be 
> useful without the GCC and binutils ports, and those ports (to which we 
> added PIC and TLS support among other things) are based on code from 
> Altera which is not covered by an FSF copyright assignment, so while the 
> code is available we have no current plans for Nios II upstream 
> contribution.
> 
> http://www.codesourcery.com/sgpp/portal/datasheet?target_arch=Nios+II&amp;target_os=GNU%2FLinux

Same thing here. I wouldn't call the glibc port "fully functional" because
it does not cover a mainline Linux and getting the architecture tree
upstream means replacing the syscall ABI with a proper one.

Once the kernel parts are upstream and use the generic syscall ABI, only
rudimentary architecture support in glibc would be needed.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/