> 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/