Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 1 Oct 2002 23:05:40 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 1 Oct 2002 23:05:40 -0400 Received: from neon-gw-l3.transmeta.com ([63.209.4.196]:39685 "EHLO neon-gw.transmeta.com") by vger.kernel.org with ESMTP id ; Tue, 1 Oct 2002 23:05:39 -0400 Date: Tue, 1 Oct 2002 20:12:28 -0700 (PDT) From: Linus Torvalds To: Alexander Viro cc: Christoph Hellwig , Kernel Mailing List Subject: Re: Linux v2.5.40 - and a feature freeze reminder 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: 1121 Lines: 30 On Tue, 1 Oct 2002, Alexander Viro wrote: > > Umm... Speaking of 32bit dev_t, I'd rather do it right way. Hey, if you drive that part, I'll be very happy. I don't doubt you can fix up the block device handling quite nicely by now, but I worry about all the other crud, including how to make the interfaces be backwards-compatible etc, and making sure we convert correctly in all the right places. The explicit dev_t<->kdev_t conversion has fixed only a subset of the problems, and we still use dev_t as keys into things (ie we have this notion that two different dev_t never map to the same "bdev *", for example - which totally breaks aliases etc). There's also all the user-level interfaces for dev_t, and the disk layout interfaces used by various filesystems. We can easily make kdev_t be 32-bit, but without a 32-bit dev_t that doesn't help much. 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/