On Thu, 5 Apr 2007 16:56:19 +0530 Amit K. Arora wrote:
> On Fri, Mar 30, 2007 at 02:14:17AM -0500, Jakub Jelinek wrote:
> > 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.
>
> This should work on all the platforms. The only concern I can think of
> here is the convention being followed till now, where all the entities on
> which the action has to be performed by the kernel (say fd, file/device
> name, pid etc.) is the first argument of the system call. If we can live
> with the small exception here, fine.
>
> Or else, we may have to implement the
>
> int fd, int mode, loff_t offset, loff_t len
>
> as the layout of arguments here. I think only s390 will have a problem
> with this, and we can think of a workaround for it (may be similar to
> what ARM did to implement sync_file_range() system call) :
>
> asmlinkage long sys_s390_fallocate(int fd, loff_t offset, loff_t len, int
> mode)
> {
> return sys_fallocate(fd, offset, len, mode);
> }
>
>
> To me both the approaches look slightly unconventional. But, we need to
> compromise somewhere to make things work on all the platforms.
>
> Any thoughts on which one of the above should we finalize on ?
>
> Thanks!
If s390 can work around the calling order that easily, I certainly
prefer the more conventional ordering of:
> int fd, int mode, loff_t offset, loff_t len
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
|