In article <20030718011115.A2600@pclin040.win.tue.nl>,
Andries Brouwer <aebr@win.tue.nl> 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 <sys/sysmacros.h>.
>>
>> 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/
This archive was generated by hypermail 2b29 : Wed Jul 23 2003 - 22:00:31 EST