[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20071004125916.dbe4fd13.akpm@linux-foundation.org>
Date: Thu, 4 Oct 2007 12:59:16 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Trond Myklebust <trond.myklebust@....uio.no>
Cc: drzeus-list@...eus.cx, staubach@...hat.com, nfsv4@...ux-nfs.org,
nfs@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: [NFS] What's slated for inclusion in 2.6.24-rc1 from the NFS
client git tree...
On Thu, 04 Oct 2007 15:16:03 -0400
Trond Myklebust <trond.myklebust@....uio.no> wrote:
> > >
> > > That would be perfect. It can even be in non-legacy mode by default,
> > > just as long as you can go back to the old behaviour when/if you run
> > > into a non-LFS application.
> > >
> >
> > Wouldn't a mount option be better?
>
> I suppose that might be OK if you know that the 32-bit legacy
> applications will only touch one or two servers, but that sounds like a
> niche thing.
>
> On the downside, forcing all those people who have portable 64-bit aware
> applications to upgrade their version of mount just in order to have
> stat64() work correctly seems unnecessarily complicated. I'd prefer not
> to have to do that unless someone comes up with a good reason why we
> must.
Confused. You don't need to modify mount(8) when adding a new mount option?
-
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