On Tue, 2010-01-19 at 16:21 +0900, Paul Mundt wrote:
IE. I'd rather have them all duplicated into real syscalls than some of
them only in socketcall and some on both since that will make any kind
of userspace transition even more hellish.
Presumably you're going to have to support both given that binaries with
both ABIs are going to be left around for the forseeable future. We
started out with socketcall on sh64 with the initial ABI and then
transitioned over to broken out direct system calls. While having both is
a bit inconsistent, it's not really something that can be avoided until
all of the old binaries go away. There are certainly enough architectures
today that provide both that you shouldn't really run in to any nasty
surprises at least.
I agree, my point was more like I'd rather not add the syscall for
recvmmsg only right now, and others later, and instead of an
all-or-nothing approach, ie, add all the syscalls at once (while keeping
the socketcall around of course). That would make glibc work easier not
having to track syscall availability on a per-syscall basis etc...
Cheers,
Ben.
32-bit SH only uses socketcall at the moment, but I'm also inclined to
add in the broken out versions and start migrating glibc over.
Unfortunately there are not a lot of good options for the syscall checker
with things like this however, given that some platforms will want one or
the other or both ;-)
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
