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-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
