Cc: <monstr@...>, Matthew Wilcox <matthew@...>, Will Newton <will.newton@...>, Linux Kernel list <linux-kernel@...>, <linux-arch@...>, <git@...>, Stephen Neuendorffer <stephen.neuendorffer@...>, John Linn <John.Linn@...>, Ulrich Drepper <drepper@...>
I think for glibc, you also need to look for INLINE_SYSCALL and
INTERNAL_SYSCALL, possibly more.
However, note that many of the syscall numbers that are referenced
by glibc are not _required_ by it, because it already contains
alternative implementations.
openat was added in glibc-2.4 as a syscall, see
http://sourceware.org/cgi-bin/cvsweb.cgi/libc/sysdeps/unix/sysv/linux/openat.c?rev=1.2...
What is not yet there is code to implement open() using openat() in the
absense of __NR_open.
I think your approach is flawed, it doesn't help at all to look at what
your libc currently does if you already think that you will need to change
the libc code.
A more relevant question is what changes should be done in glibc for this
in the first place, and I would like to hear Ulis opinion on that.
Uli: The question at hand is what syscalls a new linux architecture
should implement. To take utimes() as an example, the kernel currently
has utime(), utimes(), futimesat() and utimensat(), while glibc
provides utime(), utimes(), futimes(), futimesat(), futimens() and
utimensat(). In theory, all the glibc interfaces could be provided
on top of the utimensat() syscall, but should they?
Currently, glibc has fallback code to implement utime() using utimes(),
but not any of the others.
The same argument can be made about others, including
{,f}{mknod,mkdir,symlink,rename,access,chmod,open}{,at}
select/pselect,poll/ppoll,epoll_wait/epoll_pwait
vfork/fork/clone
{,rt_}{sigaction,sigsuspend,sigreturn,sigprocmask,sigpending}
any of your newly proposed syscalls with flags
If a new architecture should override these, should that be
done in the architecture specific code, or should the common
code be modified to handle this implicitly?
On a similar note, do you agree that a new 32 bit architecture should
define 32 bit uid_t and 64 bit off_t, and consequently leave
out all the uid16_t and loff_t based syscalls that are then simple
duplicates?
This list is possibly more useful as a "what's wrong with uClibc" list.
Most of these syscalls were added recently and should be added in uClibc
eventually, at least the subset of them that is also provided by glibc.
You are obviously missing the INLINE_SYSCALL and INTERNAL_SYSCALL here.
I do think that having this list (in a correct form) is useful for the
discussion, so it would be nice if you could do it again, including those.
Arnd <><
--
