[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070420145918.GY355@devserv.devel.redhat.com>
Date: Fri, 20 Apr 2007 10:59:18 -0400
From: Jakub Jelinek <jakub@...hat.com>
To: "Amit K. Arora" <aarora@...ux.vnet.ibm.com>
Cc: Andreas Dilger <adilger@...sterfs.com>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-ext4@...r.kernel.org, xfs@....sgi.com, cmm@...ibm.com,
suparna@...ibm.com, Andrew Morton <akpm@...ux-foundation.org>,
torvalds@...ux-foundation.org
Subject: Re: Interface for the new fallocate() system call
On Fri, Apr 20, 2007 at 07:21:46PM +0530, Amit K. Arora wrote:
> Ok.
> In this case we may have to consider following things:
>
> 1) Obviously, for this glibc will have to call fallocate() syscall with
> different arguments on s390, than other archs. I think this should be
> doable and should not be an issue with glibc folks (right?).
glibc can cope with this easily, will just add
sysdeps/unix/sysv/linux/s390/fallocate.c or something similar to override
the generic Linux implementation.
> 2) we also need to see how strace behaves in this case. With little
> knowledge that I have of strace, I don't think it should depend on
> argument ordering of a system call on different archs (since it uses
> ptrace internally and that should take care of it). But, it will be
> nice if someone can confirm this.
strace would solve this with #ifdef mess, it already does that in many
places so guess another few lines don't make it significantly worse.
Jakub
-
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