Messages in this thread | | | Date | Mon, 7 Jun 1999 01:02:58 +0200 (MET DST) | From | (Guest section DW) | Subject | Re: Migrating to larger numbers |
| |
aeb: my current code for device numbers does dev_t is 32+32 bits for major,minor unless that would give zero major, in which case dev_t is 16+16 bits for major,minor unless that would give zero major, in which case dev_t is 8+8 bits for major,minor.
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/
| |