Re: Microblaze toolchain - libc

[Arnd Bergmann]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/