From mboxrd@z Thu Jan 1 00:00:00 1970 From: Trond Myklebust Subject: Re: NFS4 mount problem Date: Sun, 17 Apr 2005 15:33:35 -0400 Message-ID: <1113766415.13680.79.camel@lade.trondhjem.org> References: <17895.1113566268@redhat.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Linux Filesystem Development , Steve Dickson Return-path: Received: from pat.uio.no ([129.240.130.16]:23291 "EHLO pat.uio.no") by vger.kernel.org with ESMTP id S261421AbVDQTdt (ORCPT ); Sun, 17 Apr 2005 15:33:49 -0400 To: David Howells In-Reply-To: <17895.1113566268@redhat.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org 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 do people have absolutely no alternative but to run a 32-bit version of the mount program on top of a kernel that was compiled as PPC64? A simple script that runs "uname -r" and switches a soft-link between the 32-bit and 64-bit version of "mount" is not rocket science. > I would prefer option (4), otherwise we have to find _all_ usages of the > mount() system calls and fix them. mount() is not a documented syscall. The binary formats for filesystems like NFS are only documented inside the kernels to which they apply. There should therefore be exactly ONE instance of usage, and that is in the "mount" program itself. Cheers, Trond -- Trond Myklebust