* Microblaze toolchain - libc
@ 2008-05-11 14:05 Michal Simek
2008-05-11 22:43 ` John Williams
0 siblings, 1 reply; 3+ messages in thread
From: Michal Simek @ 2008-05-11 14:05 UTC (permalink / raw
To: John Williams, Stephen Neuendorffer, John Linn, Linux Kernel list,
Arnd Bergmann, microblaze-uclinux, Grant Likely
Hi John W,
is it any movement in libc?
I would like clear code around syscalls.
Thanks for info,
Michal
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Microblaze toolchain - libc
2008-05-11 14:05 Microblaze toolchain - libc Michal Simek
@ 2008-05-11 22:43 ` John Williams
2008-05-12 22:56 ` Arnd Bergmann
0 siblings, 1 reply; 3+ messages in thread
From: John Williams @ 2008-05-11 22:43 UTC (permalink / raw
To: monstr
Cc: Stephen Neuendorffer, John Linn, Linux Kernel list, Arnd Bergmann,
microblaze-uclinux, Grant Likely
Hi Michal,
On Sun, 2008-05-11 at 16:05 +0200, Michal Simek 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.
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!
Regards,
John
^ permalink raw reply [flat|nested] 3+ messages in thread
* 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
end of thread, other threads:[~2008-05-12 22:56 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-05-11 14:05 Microblaze toolchain - libc Michal Simek
2008-05-11 22:43 ` John Williams
2008-05-12 22:56 ` Arnd Bergmann
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.