> Hi,
>
> On Mar 29 2007 17:21, Amit K. Arora wrote:
>>
>> We need to come up with the best possible layout of arguments for the
>> fallocate() system call. Various architectures have different
>> requirements for how the arguments should look like. Since the mail
>> chain has become huge, here is the summary of various inputs received
>> so far.
>
>> 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
>
> Quoting that...
> |len -> r6 + second halve on stack
>
> Then, is not this a gcc glitch? (IMO, it should put all of "len" on the
> stack)
>
>> Platform: ppc, arm
>> ------------------
>> 6 arguments. Thus the desired layout by ppc32 is:
>> int fallocate(int fd, int mode, loff_t offset, loff_t len)
>>
>> Option of loff_t => high u32 + low u32
>> --------------------------------------
>> Matthew and Russell have suggested another option of breaking each
>> "loff_t" into two "u32"s. This will result in 6 arguments in total.
>>
>> What are your thoughts on this ? What layout should we finalize on ?
>> Perhaps, since sync_file_range() system call has similar arguments, we
>> can take hint from the challenges faced on implementing it on various
>> architectures, and decide.
>>
>> Please suggest. Thanks!
>
> Does it actually matter? Glibc can have its own argument ordering
> different from the syscalls, so at least it would be possible to lay out
> the syscall arguments in the most portable way while retaining nice
> userspace C code. Hey, glibc might even wrap it up in a struct! (Using a
> pointer, as suggested in one of the proposals.)
>
> int fallocate(int fd, loff_t offset, loff_t len, int mode)
> {
> struct fallocate_foobar d = {fd, offset, len, mode};
> return _syscall(..., &d);
> }
>
> Jan
> --
