On Fri, Nov 20, 2015 at 5:24 PM, Brian Foster <bfoster@xxxxxxxxxx> 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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> 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). -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
