[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070406095820.GF5967@schatzie.adilger.int>
Date: Fri, 6 Apr 2007 03:58:20 -0600
From: Andreas Dilger <adilger@...sterfs.com>
To: "Amit K. Arora" <aarora@...ux.vnet.ibm.com>
Cc: Jakub Jelinek <jakub@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
torvalds@...ux-foundation.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-ext4@...r.kernel.org,
xfs@....sgi.com, suparna@...ibm.com, cmm@...ibm.com
Subject: Re: Interface for the new fallocate() system call
On Apr 05, 2007 16:56 +0530, Amit K. Arora wrote:
> 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.
Yes, it is much cleaner to have fd first, like every other such syscall.
> 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);
> }
Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists