Trond Myklebust [EMAIL PROTECTED] wrote:
We've come across an interesting problem with NFS4 mount on a PPC64 box. If
the mount program is compiled as PPC32, then the mount() syscall is returned
EFAULT.
So, why is this not a case of Doctor it hurts...?
Because:
(1) The kernel is
Christoph Hellwig [EMAIL PROTECTED] wrote:
I don't think we should encourage filesystem writers to do such stupid
things as ncfps/smbfs do. In fact I'm totally unhappy thay nfs4 went
down that road.
The problem with NFS4, I think, is that the mount syscall sets a hard limit on
the amount of
Trond Myklebust [EMAIL PROTECTED] wrote:
Without such a library, it is pointless to contemplate other callers.
With such a library, you will have a single point for switching between
32bit and 64 bit.
Other callers include such as busybox, sash and uClinux. I'm not sure about
such as Perl,
m den 18.04.2005 Klokka 16:23 (+0100) skreiv David Howells:
Trond Myklebust [EMAIL PROTECTED] wrote:
Without such a library, it is pointless to contemplate other callers.
With such a library, you will have a single point for switching between
32bit and 64 bit.
Other callers include
On Fri, Apr 15, 2005 at 01:22:59PM -0700, David S. Miller wrote:
Make a -compat_read_super() just like we have a -compat_ioctl()
method for files, if you want to suggest a solution like what
you describe.
I don't think we should encourage filesystem writers to do such stupid
things as
On Mon, Apr 18, 2005 at 10:07:14AM -0700, Bryan Henderson wrote:
On Fri, Apr 15, 2005 at 01:22:59PM -0700, David S. Miller wrote:
Make a -compat_read_super() just like we have a -compat_ioctl()
method for files, if you want to suggest a solution like what
you describe.
I don't think
mount() is not a documented syscall. The binary formats for filesystems
like NFS are only documented inside the kernels to which they apply.
What _is_ a documented system call? Linux is famous for not having
documented interfaces (or, put another way, not distinguishing between an
interface
Al Viro [EMAIL PROTECTED] wrote:
Architecture-dependent blob passed to mount(2) (aka nfs4_mount_data).
If you want it to be a blob, at least have a decency to use encoding
that would not depend on alignment rules and word size. Hell, you
could use XDR - it's not that nfs would need
On Mon, Apr 18, 2005 at 06:33:09PM +0100, David Howells wrote:
Al Viro [EMAIL PROTECTED] wrote:
Architecture-dependent blob passed to mount(2) (aka nfs4_mount_data).
If you want it to be a blob, at least have a decency to use encoding
that would not depend on alignment rules and word
m den 18.04.2005 Klokka 10:17 (-0700) skreiv Bryan Henderson:
mount() is not a documented syscall. The binary formats for filesystems
like NFS are only documented inside the kernels to which they apply.
What _is_ a documented system call? Linux is famous for not having
documented
On Mon, 18 Apr 2005 11:36:25 +0100
David Howells [EMAIL PROTECTED] wrote:
Christoph Hellwig [EMAIL PROTECTED] wrote:
I don't think we should encourage filesystem writers to do such stupid
things as ncfps/smbfs do. In fact I'm totally unhappy thay nfs4 went
down that road.
The problem
m den 18.04.2005 Klokka 15:07 (-0700) skreiv Bryan Henderson:
We're already up to version 6 of the binary interfaces for v2/v3, and if
you count NFSv4 too, then that makes 7.
I don't know the NFS mount option format, but I'm having a hard time
imagining how a string-based format can take
On Fri, Apr 15, 2005 at 01:22:59PM -0700, David S. Miller wrote:
Make a -compat_read_super() just like we have a -compat_ioctl()
method for files, if you want to suggest a solution like what
you describe.
I don't think we should encourage filesystem writers to do such stupid
things as
fr den 15.04.2005 Klokka 12:57 (+0100) skreiv David Howells:
We've come across an interesting problem with NFS4 mount on a PPC64 box. If
the mount program is compiled as PPC32, then the mount() syscall is returned
EFAULT.
So, why is this not a case of Doctor it hurts...?
In exactly which case
We've come across an interesting problem with NFS4 mount on a PPC64 box. If
the mount program is compiled as PPC32, then the mount() syscall is returned
EFAULT.
It turns out that NFS4 requires potentially more data than can be put in a
single page, something sys_mount() enforces as a hard limit.
On Fri, 15 Apr 2005 12:57:48 +0100 David Howells [EMAIL PROTECTED] wrote:
(4) Have the ppc64 kernel detect whether it's a 32-bit or a 64-bit userspace
and translate the NFS4 mount() syscall if necessary.
I would prefer option (4), otherwise we have to find _all_ usages of the
mount()
We already have compat_sys_mount that treats the mount data for smbfs and
ncpfs specially, so you could you add an nsfv4 specific bit there?
Do we really want to pile filesystem-type-specific stuff into fs/compat.c?
It's bad enough that it's there for smbfs and ncpfs (and similar stuff
for NFS
Make a -compat_read_super() just like we have a -compat_ioctl()
method for files, if you want to suggest a solution like what
you describe.
Even better.
--
Bryan Henderson IBM Almaden Research Center
San Jose CA Filesystems
-
To unsubscribe
18 matches
Mail list logo
