From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757446AbYDNLGc (ORCPT ); Mon, 14 Apr 2008 07:06:32 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752739AbYDNLGR (ORCPT ); Mon, 14 Apr 2008 07:06:17 -0400 Received: from bombadil.infradead.org ([18.85.46.34]:36453 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752673AbYDNLGQ (ORCPT ); Mon, 14 Apr 2008 07:06:16 -0400 Subject: Re: [PATCH 0/7] OMFS filesystem version 3 From: David Woodhouse To: Miklos Szeredi Cc: jamie@shareable.org, hch@infradead.org, akpm@linux-foundation.org, me@bobcopeland.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org In-Reply-To: References: <1208041121-26787-1-git-send-email-me@bobcopeland.com> <20080412170304.54f139e2.akpm@linux-foundation.org> <20080413033344.GA27494@hash.localnet> <20080412205544.5e12a7d4.akpm@linux-foundation.org> <20080413080130.GA9622@infradead.org> <20080413012001.8d7967f4.akpm@linux-foundation.org> <20080413082815.GA20108@infradead.org> <1208121358.2700.4.camel@shinybook.infradead.org> <20080414094215.GD2076@shareable.org> Content-Type: text/plain Date: Mon, 14 Apr 2008 12:05:43 +0100 Message-Id: <1208171143.31695.54.camel@pmac.infradead.org> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 (2.22.1-1.fc9) Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2008-04-14 at 11:58 +0200, Miklos Szeredi wrote: > Oh, you mean without having to run the whole kernel around the > filesystem? Well, that's a bit more tricky: filesystems use not just > the VFS API, but the block, VM, SLAB, etc. APIs as well. Porting all > of these to userspace and keeping them in sync with the kernel changes > doesn't sound much fun. That would be UML :) But seriously -- wouldn't our time be better spent on improving error handling in the kernel, rather than taking advantage of the benefits of microkernel design... but only for those parts which don't matter? -- dwmw2