Re: fallocate-implementation-on-i86-x86_64-and-powerpc.patch

Re: fallocate-implementation-on-i86-x86_64-and-powerpc.patch

[Jeff Garzik]

Andrew Morton wrote:
> So I dropped everything.  Let's start again from scratch.  I'd suggest that
> for now we go with just an i386/x86_64 implementation, let the arch
> maintainers wire things up when that has settled down.


It's my observation that that plan usually works the best.  Arch 
maintainers come along and wire up batches of syscalls when they have a 
chance to glance at the ABI, and catch up with x86[-64].

	Jeff

Re: fallocate-implementation-on-i86-x86_64-and-powerpc.patch

[Paul Mackerras]

Jeff Garzik writes:

> Andrew Morton wrote:
> > So I dropped everything.  Let's start again from scratch.  I'd suggest that
> > for now we go with just an i386/x86_64 implementation, let the arch
> > maintainers wire things up when that has settled down.
> 
> 
> It's my observation that that plan usually works the best.  Arch 

... except when the initial implementer picks an argument order which
doesn't work on some archs, as happened with sys_sync_file_range.
That is also the case with fallocate IIRC.

We did come up with an order that worked for everybody, but that
discussion seemed to get totally ignored by the ext4 developers.

Paul.

Re: fallocate-implementation-on-i86-x86_64-and-powerpc.patch

[Andrew Morton]

On Wed, 11 Jul 2007 09:27:40 +1000
Paul Mackerras <paulus@samba.org> wrote:

> We did come up with an order that worked for everybody, but that
> discussion seemed to get totally ignored by the ext4 developers.

It was a long discussion.

Can someone please remind us what the signature of the syscall
(and the compat handler) should be?

Re: fallocate-implementation-on-i86-x86_64-and-powerpc.patch

[Paul Mackerras]

Andrew Morton writes:

> On Wed, 11 Jul 2007 09:27:40 +1000
> Paul Mackerras <paulus@samba.org> wrote:
> 
> > We did come up with an order that worked for everybody, but that
> > discussion seemed to get totally ignored by the ext4 developers.
> 
> It was a long discussion.
> 
> Can someone please remind us what the signature of the syscall
> (and the compat handler) should be?

long sys_fallocate(loff_t offset, loff_t len, int fd, int mode)

should work for everybody.  The compat handler would be

long compat_sys_fallocate(u32 offset_hi, u32 offset_lo, u32 len_hi, u32 len_lo,
			  int fd, int mode)

for big-endian, or swap hi/lo for little-endian.  (Actually it would
be good to have an arch-dependent "stitch two args together" macro and
call them offset_0, offset_1 etc.)

Paul.

Re: fallocate-implementation-on-i86-x86_64-and-powerpc.patch

[Theodore Tso]

On Wed, Jul 11, 2007 at 10:50:49AM +1000, Paul Mackerras wrote:
> > On Wed, 11 Jul 2007 09:27:40 +1000
> > Paul Mackerras <paulus@samba.org> wrote:
> > 
> > > We did come up with an order that worked for everybody, but that
> > > discussion seemed to get totally ignored by the ext4 developers.

Well, in the end it was a toss-up between

asmlinkage long sys_fallocate(int fd, int mode, loff_t offset, loff_t len)

and 

asmlinkage long sys_fallocate(loff_t offset, loff_t len, int fd, int mode)

There were a number of folks who preferred having int fd first, and I
*thought* Amit had gotten agreement from either Martin or Heiko that
it was ok to do this as an exception, even though it was extra work
for that arch.  But if not, we can try going back the second
alternative, or even the 6 32-bits args (off_high, off_low, len_high,
len_low) approach, but I think that drew even more fire. 

Basically, no one approach made everyone happy, and at the end of the
day sometimes you have to choose.  I thought we had settled this in
May with something that people could live with, but if we need to
reopen the discussion, better now than later.....

						- Ted

Re: fallocate-implementation-on-i86-x86_64-and-powerpc.patch

[Heiko Carstens]

On Wed, Jul 11, 2007 at 11:39:39AM -0400, Theodore Tso wrote:
> On Wed, Jul 11, 2007 at 10:50:49AM +1000, Paul Mackerras wrote:
> > > On Wed, 11 Jul 2007 09:27:40 +1000
> > > Paul Mackerras <paulus@samba.org> wrote:
> > > 
> > > > We did come up with an order that worked for everybody, but that
> > > > discussion seemed to get totally ignored by the ext4 developers.
> 
> Well, in the end it was a toss-up between
> 
> asmlinkage long sys_fallocate(int fd, int mode, loff_t offset, loff_t len)
> 
> and 
> 
> asmlinkage long sys_fallocate(loff_t offset, loff_t len, int fd, int mode)
> 
> There were a number of folks who preferred having int fd first, and I
> *thought* Amit had gotten agreement from either Martin or Heiko that
> it was ok to do this as an exception, even though it was extra work
> for that arch.  But if not, we can try going back the second
> alternative, or even the 6 32-bits args (off_high, off_low, len_high,
> len_low) approach, but I think that drew even more fire. 

The second approach would work for all architectures..  but some people
didn't like (no technical reason) not having fd as first argument.

Just go ahead with the current approach. s390 seems to be the only
architecture which suffers from this and I wouldn't like to start this
discussion again.

Re: fallocate-implementation-on-i86-x86_64-and-powerpc.patch

[Martin Schwidefsky]

On Wed, 2007-07-11 at 20:47 +0200, Heiko Carstens wrote:
> > There were a number of folks who preferred having int fd first, and I
> > *thought* Amit had gotten agreement from either Martin or Heiko that
> > it was ok to do this as an exception, even though it was extra work
> > for that arch.  But if not, we can try going back the second
> > alternative, or even the 6 32-bits args (off_high, off_low, len_high,
> > len_low) approach, but I think that drew even more fire. 
> 
> The second approach would work for all architectures..  but some people
> didn't like (no technical reason) not having fd as first argument.

For s390 we would have liked the second approach with the two int's as
last arguments since it would avoid the wrapper in the kernel. It does
not avoid the wrapper in user space since the call uses 6 register on 31
bit. So the fallocate call need special treatement in glibc so I don't
mind that it needs another wrapper in the kernel.

> Just go ahead with the current approach. s390 seems to be the only
> architecture which suffers from this and I wouldn't like to start this
> discussion again.

Yes, don't worry about s390 for fallocate, the patch that had been in
-mm only had an incorrect system call number. The wrapper is fine.

-- 
blue skies,
  Martin.

"Reality continues to ruin my life." - Calvin.