Hi,
On Thu, 27 Mar 2003 Andries.Brouwer@cwi.nl wrote:
> kdev_t is the kernel-internal representation
> dev_t is the kernel idea of the user space representation
> (of course glibc uses 64 bits, split up as 8+8 :-)
>
> kdev_t can be equal to dev_t.
>
> The file below completely randomly makes kdev_t
> 64 bits, split up 32+32, and dev_t 32 bits, split up 12+20.
It would really help, if you would explain how a larger dev_t will work
during 2.6.
Let's take an example, the first user is likely the scsi layer, so how
can I manage thousands of disks under 2.6?
How are these disks registered and how will the dev_t number look like?
How will the user know about these numbers?
Who creates these device entries (user or daemon)?
How have user space utilities to be changed, which know about dev_t (e.g.
ls or fdisk)?
How is backward compatibility done, so that I can still boot a 2.4 kernel?
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/
This archive was generated by hypermail 2b29 : Mon Mar 31 2003 - 22:00:29 EST