Messages in this thread | | | Date | Fri, 4 Jan 2002 16:10:16 -0500 (EST) | From | Alexander Viro <> | Subject | Re: 2.5.2-pre7 still missing bits of kdev_t |
| |
On Fri, 4 Jan 2002 Andries.Brouwer@cwi.nl wrote:
> If init_special_inode() has major,minor arguments instead of > the present rdev, then the line > > inode->i_rdev = to_kdev_t(rdev); > > just becomes > > inode->i_rdev = mk_kdev(major,minor); > > I consider every occurrence of mk_kdev() and of to_kdev_t() > a flaw in the kernel, so this change does not make things > better or worse inside init_special_inode().
Well, to start with, any use of kdev_t for block devices is a flaw (fortunately most of fs/*/*.c ones are gone by now and buffer cache will follow).
As for the init_special_inode() I'd rather have le16_to_dev() et.al. so that ext2_read_inode() and friends would do init_special_inode(inode, mode, le16_to_dev(raw->i_rdev));
Reasons: a) foo_mknod() - why the hell would we take dev_t, pass it into ->mknod() only to split it into major:minor there and immediately rebuild dev_t from them? And that - for _all_ instances of ->mknod() b) what happens in ->read_inode() is "here's on-disk encoding, we want to know which dev_t value it is". Sure, helpers that do mapping will need to know encoding. ->read_inode() itself, though... Why do we care about major:minor split at that level?
- 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/
| |