Re: 2.5.2-pre7 still missing bits of kdev_t

From: Alexander Viro (viro@math.psu.edu)
Date: Fri Jan 04 2002 - 16:10:16 EST


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/



This archive was generated by hypermail 2b29 : Mon Jan 07 2002 - 21:00:26 EST