Arnd Bergmann wrote:
Chris, are there any existing binaries that rely on your implementations
of old_mmap, sys_fork, sys_vfork, sys_olduname or sys_ipc and need to
work with future kernels? Otherwise, you should probably drop these.
For sys_ipc, you would need to add the subcalls directly to the table,
like parisc does.
Hmm, xtensa is now in -rc1, with the obsolete syscalls still in there,
so I guess this about the last chance to correct the ABI. Applying the
patch obviously breaks all sorts of user space binaries and probably
also requires the appropriate changes to be made to libc.
I have to admit, the -rc1 caught me a bit by surprise; I have a few
patches pending that I want to send out today.
The question is, if we had to break glibc compatibility, shouldn't we
use the opportunity to clean-up the syscall list? It was copied from
MIPS and, thus, has inherited a lot of legacy from there. As a new
architecture, maybe we should even go as far as removing all ni-syscalls
and start fresh?
On the other hand, if a decision is made to keep the broken interface,
it should at least be a conscious one instead of an oversight.
I will try out your patch and see if there are any obvious problems.
Thanks,
~Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
