On Fri, Apr 20, 2007 at 10:59:18AM -0400, Jakub Jelinek wrote:
> 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
On Fri, Apr 20, 2007 at 10:59:18AM -0400, Jakub Jelinek wrote:
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,
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
On Wed, Apr 18, 2007 at 07:06:00AM -0600, Andreas Dilger wrote:
> On Apr 17, 2007 18:25 +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
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
On Wed, Apr 18, 2007 at 07:06:00AM -0600, Andreas Dilger wrote:
On Apr 17, 2007 18:25 +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
On Apr 17, 2007 18:25 +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,
On Apr 17, 2007 18:25 +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
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.
>
I think more people
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.
I think more people are
On Mon, 9 April 2007 23:01:42 +1000, Paul Mackerras wrote:
> Jörn Engel writes:
>
> > 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.
>
> The alternative
Jörn Engel writes:
> 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.
The alternative that Jakub suggested wouldn't slow s390 down.
Paul.
-
To unsubscribe from
Jörn Engel writes:
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.
The alternative that Jakub suggested wouldn't slow s390 down.
Paul.
-
To unsubscribe from this
On Mon, 9 April 2007 23:01:42 +1000, Paul Mackerras wrote:
Jörn Engel writes:
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.
The alternative that Jakub
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
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
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
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
On Thu, Apr 05, 2007 at 04:56:19PM +0530, Amit K. Arora wrote:
Correction below:
> asmlinkage long sys_s390_fallocate(int fd, loff_t offset, loff_t len, int
> mode)
> {
> return sys_fallocate(fd, offset, len, mode);
return sys_fallocate(fd, mode, offset, len);
> }
--
Regards,
On Thu, Apr 05, 2007 at 04:56:19PM +0530, Amit K. Arora wrote:
Correction below:
asmlinkage long sys_s390_fallocate(int fd, loff_t offset, loff_t len, int
mode)
{
return sys_fallocate(fd, offset, len, mode);
return sys_fallocate(fd, mode, offset, len);
}
--
Regards,
Amit
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
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
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
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
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-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
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:
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
> > 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
> > --
> >
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,
On Thu, Mar 29, 2007 at 07:01:54PM +0200, Jan Engelhardt wrote:
> 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
On Thu, Mar 29, 2007 at 07:01:54PM +0200, Jan Engelhardt wrote:
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
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
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
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
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-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
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:
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
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
On Thu, 29 Mar 2007, Jan Engelhardt wrote:
>
> I have to disagree, since wrapping it into a struct and copying the struct
> in kernelspace from userspace requires more code.
Not just more code, but more security issues too.
Passing system call arguments by value means that there are no subtle
On Mar 29 2007 13:18, linux-os (Dick Johnson) wrote:
>
>I think it's always better to put only a pointer on the stack as
>above.
I have to disagree, since wrapping it into a struct and copying the struct
in kernelspace from userspace requires more code. Pointers only become
useful at 3 (rarely)
On Thu, 29 Mar 2007, Jan Engelhardt wrote:
> 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.
On Thu, 29 Mar 2007 17:21:26 +0530 "Amit K. Arora" <[EMAIL PROTECTED]> wrote:
> Hello,
>
> 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
>
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
On Thu, Mar 29, 2007 at 05:21:26PM +0530, Amit K. Arora wrote:
>int fallocate(int fd, loff_t offset, loff_t len, int mode)
Right now there are only two possible values for mode --- it's not
clear what additional values there will be in the future.
How about two syscalls? If we decide later
On Thu, Mar 29, 2007 at 05:21:26PM +0530, Amit K. Arora wrote:
int fallocate(int fd, loff_t offset, loff_t len, int mode)
Right now there are only two possible values for mode --- it's not
clear what additional values there will be in the future.
How about two syscalls? If we decide later
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
On Thu, 29 Mar 2007 17:21:26 +0530 Amit K. Arora [EMAIL PROTECTED] wrote:
Hello,
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
On Thu, 29 Mar 2007, Jan Engelhardt wrote:
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
On Mar 29 2007 13:18, linux-os (Dick Johnson) wrote:
I think it's always better to put only a pointer on the stack as
above.
I have to disagree, since wrapping it into a struct and copying the struct
in kernelspace from userspace requires more code. Pointers only become
useful at 3 (rarely) or
On Thu, 29 Mar 2007, Jan Engelhardt wrote:
I have to disagree, since wrapping it into a struct and copying the struct
in kernelspace from userspace requires more code.
Not just more code, but more security issues too.
Passing system call arguments by value means that there are no subtle
50 matches
Mail list logo
