On Mon, 2007-06-25 at 02:11 -0700, Andrew Morton wrote: > On Mon, 25 Jun 2007 09:49:17 +0100 David Woodhouse <[EMAIL PROTECTED]> wrote: > > > +/* It would be nice if people remember that not all the world's an i386 > > + when they introduce new system calls */ > > I think we could do without the smartarse comments, frankly. It took about > two weeks and 1000000000 emails for you guys to sort out the fallocate() > ABI.
It's exactly the same case -- two ints and two loff_ts. If we'd already sorted it out properly for sys_sync_file_range() then it would have been a no-brainer for fallocate(). > How would you like "it would be nice if maintainers of oddball > architectures would pay attention"? Seems like a reasonable observation, although 'oddball' isn't really the case here. There are a bunch of architectures which align 64-bit arguments into even pairs of registers. And a lot of people who forget that 64-bit quantities are often aligned to 8 bytes, on non-x86. cf. f4d2781731e846c2f01dd85e71883d120860c6dd But aside from nit-picking the wording, I do agree with the sentiment -- and that's precisely why you'll see warnings about sys_sync_file_range() being unimplemented, when you build current kernels on certain platforms. So that all arch maintainers pay attention to new syscalls. > the naming, the implementation and the types are all inconsistent. Can we > pick one style and stick to it? It might actually be useful to merge all these into fs/compat.c. I think the only reason most of them are arch-specific at the moment is because we have to deal with endianness when we put the two 32-bit integers together into a 64-bit integer. And MIPS copes well enough with that, with its merge_64() macro. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
