Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S271636AbTGQXeV (ORCPT ); Thu, 17 Jul 2003 19:34:21 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S271638AbTGQXeV (ORCPT ); Thu, 17 Jul 2003 19:34:21 -0400 Received: from uucp.cistron.nl ([62.216.30.38]:33032 "EHLO ncc1701.cistron.net") by vger.kernel.org with ESMTP id S271636AbTGQXeU (ORCPT ); Thu, 17 Jul 2003 19:34:20 -0400 From: "Miquel van Smoorenburg" Subject: Re: [PATCH] print_dev_t for 2.6.0-test1-mm Date: Thu, 17 Jul 2003 23:49:15 +0000 (UTC) Organization: Cistron Group Message-ID: References: <20030716184609.GA1913@kroah.com> <20030718002451.A2569@pclin040.win.tue.nl> <20030717224307.GF19891@ca-server1.us.oracle.com> <20030718011115.A2600@pclin040.win.tue.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT X-Trace: ncc1701.cistron.net 1058485755 10992 62.216.29.200 (17 Jul 2003 23:49:15 GMT) X-Complaints-To: abuse@cistron.nl X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Originator: miquels@cistron-office.nl (Miquel van Smoorenburg) To: linux-kernel@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1524 Lines: 30 In article <20030718011115.A2600@pclin040.win.tue.nl>, Andries Brouwer wrote: >On Thu, Jul 17, 2003 at 03:43:08PM -0700, Joel Becker wrote: >> On Fri, Jul 18, 2003 at 12:24:51AM +0200, Andries Brouwer wrote: >> > Premise: some filesystems or archives store 32 bits. >> > Conclusion: we must be able to handle that. >> > This is unrelated to the kernel, unrelated to system calls, >> > it is related to . >> >> How does linux handle that today? IIRC, it ignores the high >> 16bits and treats that 32bit number as 8:8. That is what happens today, >> for every filesystem, whether it stores 32 or 16 bits. >> Why expand that? We can continue to treat 32bit numbers (eg, >> from NFSv2) as 16bit numbers. > >:-) A surprising question. >Why expand that? >Because we would like to use more than 16 bits in device numbers. But why do you need a 32bit interface to the kernel when a 32:32 interface exists? Userland can translate 32 bit major/minor into 32:32 to the kernel, if a 64 bits syscall exists, right CAse in point: mknod64() Same goes for filesystems. A 32 bit on-disk rdev doesn't need to be handled by the rest of the kernel. The filesystem driver just needs to translate it to 32 major 32 minor for the rest of the kernel. Mike. - 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/