hpa: And so how do you distinguish between (0,2000) and (7,208)?
aeb: The former does not exist.
alan: Conceptually 0:something is a multiplexor device for
legacy device nodes.
hpa: But 0 isn't that. I suggested making 0xffff the legacy device.
That was the point I was trying to make.
aeb: There aren't yet any conventions for 32-bit device numbers
so you cannot say "0 isn't that". It is up to us now to choose.
The present code in fs/ext2/inode.c does
if (S_ISCHR(inode->i_mode) || S_ISBLK(inode->i_mode))
raw_inode->i_block[0] = cpu_to_le32(kdev_t_to_nr(inode->i_rdev));
that is, stores a 32-bit dev_t already, precisely following
my format. Thus, if one uses 0xffff then disk conversion
would be required. With my format the same disk can work
with old and new kernels and with old and new user space programs.
hpa: I'd still like to suggest a 64-bit dev_t.
aeb: I entirely agree. With 32 the partitioning may become significant
and 16+16 is suboptimal. With 64 there is no reason to not just
use 32+32. However, some things I haven't checked (or have forgotten
again), like: is raw_inode->i_block[1] guaranteed to be zero today
for a device node? At first sight this seems not to be the case,
which means that for a 64-bit dev_t a "conversion" is required,
namely finding all device nodes on the file system and writing
a zero into the presently unused raw_inode->i_block[1].
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/