Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1162782AbbKTO0b (ORCPT ); Fri, 20 Nov 2015 09:26:31 -0500 Received: from mail-wm0-f52.google.com ([74.125.82.52]:35706 "EHLO mail-wm0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752989AbbKTO03 (ORCPT ); Fri, 20 Nov 2015 09:26:29 -0500 MIME-Version: 1.0 In-Reply-To: <20151120005843.GP14311@dastard> References: <1447800381-20167-1-git-send-email-octavian.purdila@intel.com> <20151119232455.GM14311@dastard> <20151120005843.GP14311@dastard> Date: Fri, 20 Nov 2015 16:26:28 +0200 Message-ID: Subject: Re: [RFC PATCH] xfs: support for non-mmu architectures From: Octavian Purdila To: Dave Chinner Cc: Richard Weinberger , xfs , linux-fsdevel , LKML Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2257 Lines: 48 On Fri, Nov 20, 2015 at 2:58 AM, Dave Chinner 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 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. Could you expand of what burden does this use-case put on fs developers? I am sure that, if needed, we can put restrictions in LKL to avoid that. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/