* Re: Microblaze toolchain - libc
2008-05-11 22:43 ` John Williams
@ 2008-05-12 22:56 ` Arnd Bergmann
0 siblings, 0 replies; 3+ messages in thread
From: Arnd Bergmann @ 2008-05-12 22:56 UTC (permalink / raw)
To: John Williams
Cc: monstr, Stephen Neuendorffer, John Linn, Linux Kernel list,
microblaze-uclinux, Grant Likely
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 <><
^ permalink raw reply [flat|nested] 3+ messages in thread