Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Mar 2003 06:25:10 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Mar 2003 06:25:10 -0500 Received: from smtpzilla2.xs4all.nl ([194.109.127.138]:47369 "EHLO smtpzilla2.xs4all.nl") by vger.kernel.org with ESMTP id ; Fri, 28 Mar 2003 06:25:08 -0500 Date: Fri, 28 Mar 2003 12:36:18 +0100 (CET) From: Roman Zippel X-X-Sender: roman@serv To: Andries.Brouwer@cwi.nl cc: greg@kroah.com, Alan Cox , Subject: Re: 64-bit kdev_t - just for playing In-Reply-To: Message-ID: References: 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: 1321 Lines: 37 Hi, On Fri, 28 Mar 2003 Andries.Brouwer@cwi.nl wrote: > Roman, Your questions are misguided. Thanks for your trust. :-( > A larger dev_t is infrastructure. > A sand road that is turned into an asphalt road. > > Nobody has to use this improved infrastructure. > But many uses are conceivable. The size of dev_t doesn't matter at all, what matters is how this number is managed and used. The kernel has somehow to generate a number for a device and tell the user about it, so that he can use it to access the device. This requires infrastructure and the actual size of this number is only a small detail in the whole picture. I want to know how the whole picture looks like, so could you please stop talking bullshit and answer my questions? > I can imagine that there will be people wanting > to take part of the available space for a universal > hash of disk serial number or partition label or > I don't know what, so that devices are addressable > by content instead of path. This won't happen, dev_t is the wrong place to encode such information. bye, Roman - 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/