Re: Interface for the new fallocate() system call
On Thu, Mar 29, 2007 at 10:10:10AM -0700, Andrew Morton wrote: Platform: s390 -- s390 prefers following layout: int fallocate(int fd, loff_t offset, loff_t len, int mode) For details on why and how int, int, loff_t, loff_t is a problem on s390, please see Heiko's mail on 16th March. Here is the link: http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg133595.html Platform: ppc, arm -- ppc (32 bit) has a problem with int, loff_t, loff_t, int layout, since this will result in a pad between fd and offset, making seven arguments total - which is not supported by ppc32. It supports only 6 arguments. Thus the desired layout by ppc32 is: int fallocate(int fd, int mode, loff_t offset, loff_t len) Even ARM prefers above kind of layout. For details please see the definition of sys_arm_sync_file_range(). This is a clean-looking option. Can s390 be changed to support seven-arg syscalls? Wouldn't int fallocate(loff_t offset, loff_t len, int fd, int mode) work on both s390 and ppc/arm? glibc will certainly wrap it and reorder the arguments as needed, so there is no need to keep fd first. Jakub - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Interface for the new fallocate() system call
Even ARM prefers above kind of layout. For details please see the definition of sys_arm_sync_file_range(). This is a clean-looking option. Can s390 be changed to support seven-arg syscalls? Option of loff_t = high u32 + low u32 -- Matthew and Russell have suggested another option of breaking each loff_t into two u32s. This will result in 6 arguments in total. Following think that this is a good alternative: Matthew Wilcox, Russell King, Heiko Carstens Following do not like this idea: Chris Wedgwood It's a bit weird-looking, but the six-32-bit-args approach is simple enought to understand and implement. Presumably the glibc wrapper would hide that detail from everyone. s390 can be changed to support seven-arg syscalls. But that would require creating an additional stackframe in *libc to save original register contents and in addition it would make our syscall hotpath slower. That is because we have to take care of an additional register that might contain user space passed contents and needs to be put on the kernel stack. If possible I'd prefer the six-32-bit-args approach. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Interface for the new fallocate() system call
On Fri, Mar 30, 2007 at 02:14:17AM -0500, Jakub Jelinek wrote: On Thu, Mar 29, 2007 at 10:10:10AM -0700, Andrew Morton wrote: Platform: s390 -- s390 prefers following layout: int fallocate(int fd, loff_t offset, loff_t len, int mode) For details on why and how int, int, loff_t, loff_t is a problem on s390, please see Heiko's mail on 16th March. Here is the link: http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg133595.html Platform: ppc, arm -- ppc (32 bit) has a problem with int, loff_t, loff_t, int layout, since this will result in a pad between fd and offset, making seven arguments total - which is not supported by ppc32. It supports only 6 arguments. Thus the desired layout by ppc32 is: int fallocate(int fd, int mode, loff_t offset, loff_t len) Even ARM prefers above kind of layout. For details please see the definition of sys_arm_sync_file_range(). This is a clean-looking option. Can s390 be changed to support seven-arg syscalls? Wouldn't int fallocate(loff_t offset, loff_t len, int fd, int mode) work on both s390 and ppc/arm? glibc will certainly wrap it and reorder the arguments as needed, so there is no need to keep fd first. That would be fine for s390. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Interface for the new fallocate() system call
Heiko Carstens writes: If possible I'd prefer the six-32-bit-args approach. It does mean extra unnecessary work for 64-bit platforms, though... Paul. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Interface for the new fallocate() system call
Jakub Jelinek writes: Wouldn't int fallocate(loff_t offset, loff_t len, int fd, int mode) work on both s390 and ppc/arm? glibc will certainly wrap it and reorder the arguments as needed, so there is no need to keep fd first. That looks fine to me. Paul. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Interface for the new fallocate() system call
On Fri, 30 March 2007 19:15:58 +1000, Paul Mackerras wrote: Heiko Carstens writes: If possible I'd prefer the six-32-bit-args approach. It does mean extra unnecessary work for 64-bit platforms, though... Wouldn't that work be confined to fallocate()? If I understand Heiko correctly, the alternative would slow s390 down for every syscall, including more performance-critical ones. Jörn -- tglx1 thinks that joern should get a (TM) for Thinking Is Hard -- Thomas Gleixner - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Interface for the new fallocate() system call
On Fri, Mar 30, 2007 at 12:44:49PM +0200, Jörn Engel wrote: On Fri, 30 March 2007 19:15:58 +1000, Paul Mackerras wrote: It does mean extra unnecessary work for 64-bit platforms, though... Wouldn't that work be confined to fallocate()? If I understand Heiko correctly, the alternative would slow s390 down for every syscall, including more performance-critical ones. That is correct. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
