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: <Pine.LNX.4.64.1009281623320.22692@digraph.polyomino.org.uk>
Date:	Tue, 28 Sep 2010 16:41:41 +0000 (UTC)
From:	"Joseph S. Myers" <joseph@...esourcery.com>
To:	Arnd Bergmann <arnd@...db.de>
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 Tue, 28 Sep 2010, Arnd Bergmann wrote:

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

In my experience very little of a glibc port relates to the particular set 
of syscalls present on a particular architecture (and what does often 
consists of one-line files that #include the file for i386 or some other 
convenient architecture); changing a port from an old syscall ABI to the 
generic one would mean making it use the new set of generic files in 
preference to some existing sysdeps/unix/sysv/linux files, and maybe 
having fewer bits/ headers if some of the architecture differences there 
are avoided, but no real differences to any of the bits that aren't purely 
mechanical such as the implementation of each architecture's TLS ABI, 
other pieces of the ELF ABI, the set of atomic operations available, 
startup code, longjmp, profiling, clone, the interface used to call an 
individual syscall, etc. - remember that you can't build any vaguely 
recent glibc without full shared library and NPTL support.

A lot of the *changes made to maintain an existing port* relate to 
constants in the duplicated bits/* headers which it might be good to 
duplicate less if future architectures share values for all the constants, 
but that's not where most of the complexity in the port lies.  MIPS is 
probably the worst case for code dealing with syscall ABI peculiarities 
(given the three different ABIs, and n64 having different userspace stat 
and stat64 structures), but even there they aren't much of a source of 
complexity (MIPS ELF peculiarities are much more an issue).

-- 
Joseph S. Myers
joseph@...esourcery.com
--
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/