linux-kernel - Re: Microblaze toolchain

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 for Android: free password hash cracker in your pocket

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

Message-Id: <200805130056.13950.arnd@arndb.de>
Date:	Tue, 13 May 2008 00:56:12 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	John Williams <john.williams@...alogix.com>
Cc:	monstr@...nam.cz,
	Stephen Neuendorffer <stephen.neuendorffer@...inx.com>,
	John Linn <John.Linn@...inx.com>,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	microblaze-uclinux@...e.uq.edu.au,
	Grant Likely <grant.likely@...retlab.ca>
Subject: Re: Microblaze toolchain - libc

On Monday 12 May 2008, John Williams wrote:
> > is it any movement in libc?
> > I would like clear code around syscalls.
> 
> I can't see anything radical happening with glibc / uClibc in the short
> term.  My suggestion is you make sure the kernel builds with current
> toolchain.  

What happened to the idea of making it an add-on patch for the short
term then?

I think you should use the short generic syscall list in the mainline
series, and add source level support for uClibc back in as an out-of-tree
patch, under an #ifdef.

I guess that you can mostly do this by adding back the currently
required syscalls for uClibc at the end of sys_call_table, and
introducing a new file with the old implementation of the removed
arch specific calls (ipc, vfork, mmap, ...).

BTW: after a private discussion I had with some other kernel hackers,
I believe now that it will be easier for you to leave off_t as
32 bit but instead make sure that you only list the syscalls using
loff_t, e.g. stat64 instead of new_stat, contrary to what I claimed
earlier. You should probably try that yourself and do whatever
is easier to implement in uClibc.

> I'm not personally concerned about minor bloat of adding syscalls like
> openat() that are not currently used - 1 or 2 K for extra entries in
> syscall table, and a few hundred bytes per sys_wrapper really is not on
> the radar if glibc is considered a sensible library for Microblaze +
> MMU!

You still have it backwards -- you need to have openat() anyway because
applications can legally call that function, and if uClibc doesn't have
it, that's just a bug. The discussion was about leaving out the open()
syscall in favour of a libc based implementation based on openat().
Besides, these syscalls don't matter much, as you said those only save
a few bytes.
The real killers are uid16, 32 bit off_t, old style signals and some
minor annoyances things like sys_ipc(). If you change those, you might
just as well get it right because you're breaking compatibility already.

	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/