lkml.org 
[lkml]   [2002]   [Jan]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:15    [W:0.214 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site