Re: [RFC PATCH] xfs: support for non-mmu architectures

From: Brian Foster <bfoster@redhat.com>
To: Octavian Purdila <octavian.purdila@intel.com>
Cc: Richard Weinberger <richard.weinberger@gmail.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>, xfs <xfs@oss.sgi.com>
Subject: Re: [RFC PATCH] xfs: support for non-mmu architectures
Date: Fri, 20 Nov 2015 10:43:36 -0500	[thread overview]
Message-ID: <20151120154336.GE60886@bfoster.bfoster> (raw)
In-Reply-To: <CAE1zotK1Gjb_gzDjU_dnQoYQnP4azvsDtzi6f=RANH-wDOKhSA@mail.gmail.com>

On Fri, Nov 20, 2015 at 05:31:59PM +0200, Octavian Purdila wrote:
> On Fri, Nov 20, 2015 at 5:24 PM, Brian Foster <bfoster@redhat.com> wrote:
> > On Fri, Nov 20, 2015 at 04:26:28PM +0200, Octavian Purdila wrote:
> >> On Fri, Nov 20, 2015 at 2:58 AM, Dave Chinner <david@fromorbit.com> wrote:
> >> > On Fri, Nov 20, 2015 at 12:54:02AM +0100, Richard Weinberger wrote:
> >> >> On Fri, Nov 20, 2015 at 12:24 AM, Dave Chinner <david@fromorbit.com> wrote:
> >> >> > On Wed, Nov 18, 2015 at 12:46:21AM +0200, Octavian Purdila wrote:
> >> >> >> Naive implementation for non-mmu architectures: allocate physically
> >> >> >> contiguous xfs buffers with alloc_pages. Terribly inefficient with
> >> >> >> memory and fragmentation on high I/O loads but it may be good enough
> >> >> >> for basic usage (which most non-mmu architectures will need).
> >> >> >
> >> >> > Can you please explain why you want to use XFS on low end, basic
> >> >> > non-MMU devices? XFS is a high performance, enterprise/HPC level
> >> >> > filesystem - it's not a filesystem designed for small IoT level
> >> >> > devices - so I'm struggling to see why we'd want to expend any
> >> >> > effort to make XFS work on such devices....
> >> >>
> >> >> The use case is the Linux Kernel Library:
> >> >> https://lkml.org/lkml/2015/11/3/706
> >> >>
> >> >> Using LKL and fuse you can mount any kernel filesystem using fuse
> >> >> as non-root.
> >> >
> >> > IOWs, because we said no to unprivileged mounts, instead the
> >> > proposal is to linking all the kernel code into userspace so you can
> >> > do unprivielged mounts that way?
> >> >
> >>
> >> LKL's goal is to make it easy for various applications to reuse Linux
> >> kernel code instead of re-implementing it. Mounting filesystem images
> >> is just one of the applications.
> >>
> >> > IOWs, you get to say "it secure because it's in userspace" and leave
> >> > us filesystem people with all the shit that comes with allowing
> >> > users to mount random untrusted filesystem images using code that
> >> > was never designed to allow that to happen?
> >> >
> >>
> >> It is already possible to mount arbitrary filesystem images in
> >> userspace using VMs . LKL doesn't change that, it just reduces the
> >> amount of dependencies you need to do so.
> >>
> >
> > Perhaps a dumb question, but I'm not quite putting 2+2 together here.
> > When I see nommu, I'm generally thinking hardware characteristics, but
> > we're talking about a userspace kernel library here. So can you
> > elaborate on how this relates to nommu? Does this library emulate kernel
> > mechanisms in userspace via nommu mode or something of that nature?
> >
> 
> LKL is currently implemented as a virtual non-mmu architecture. That
> makes it simpler and it will also allow us to support environments
> where it is not possible to emulate paging (e.g.  bootloaders).
> 

Ok, so we aren't necessarily talking about running on typically limited,
mmu-less hardware. Thanks!

Brian

> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs