Messages in this thread | | | From | Arnd Bergmann <> | Subject | Re: Microblaze toolchain - libc | Date | Tue, 13 May 2008 00:56:12 +0200 |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |