Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 2 Sep 2002 23:43:31 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 2 Sep 2002 23:43:31 -0400 Received: from neon-gw-l3.transmeta.com ([63.209.4.196]:44813 "EHLO neon-gw.transmeta.com") by vger.kernel.org with ESMTP id ; Mon, 2 Sep 2002 23:43:29 -0400 Date: Mon, 2 Sep 2002 20:55:47 -0700 (PDT) From: Linus Torvalds To: Andries.Brouwer@cwi.nl cc: aebr@win.tue.nl, , , Subject: Re: PATCH - change to blkdev->queue calling triggers BUG in md.c In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1405 Lines: 45 On Tue, 3 Sep 2002 Andries.Brouwer@cwi.nl wrote: > > Why? > Because in some cases it is undesirable. Again, Why? You can always use the flat device as-is. > Because in some cases it crashes the kernel. But moving it to user space would cause the kernel to crash anyway. Bugs are bugs. > Because it involves guessing and heuristics. The same guesses and heuristics would have to be in user space. > Because policy belongs in user space. It's not policy. It's a fact of life that disks need to be split up into parts, and the partitioning schemes are well-defined and shared across multiple operating systems. > Yes - that is my main point: doing it on demand. On demand only. But I actually _agree_ with this. However, that has nothing to do with whether it is in user space or kernel space. In many ways it is _easier_ to do on demand in kernel space: when somebody opens /dev/sda1 and it isn't partitioned yet, you know it needs to be. The fact that partitioning right now is to some degree handled by device drivers is a problem, but that's not a user space vs kernel space issue. It's slowly getting moved to higher levels. Linus - 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/