2.5.2-pre7 still missing bits of kdev_t
From [email protected] Fri Jan 4 19:11:10 2002
On Fri, 4 Jan 2002, Linus Torvalds wrote:
> On Fri, 4 Jan 2002, Jeff Garzik wrote:
> >
> > As mentioned to viro on IRC, I think init_special_inode should take > > major and minor arguments, to nudge the filesystem implementors into > > thinking that major and minor should be treated separately, and be > > given additional thought as to how they are encoded on-disk. >
> Yes. If somebody sends me a patch, I'll apply it in a jiffy.
Guys, wait a minute with that. There is a related issue (->i_rdev becoming dev_t) and I'd rather see it handled first.
Those are independent issues.
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().
Andries
Quoted 5 lines · On Fri, 4 Jan 2002 [email protected] wrote:
If
init_special_inode()has major,minor arguments instead of the present rdev, then the lineinode->i_rdev = to_kdev_t(rdev);
Quoted 7 lines
just becomes
inode->i_rdev = mk_kdev(major,minor);I consider every occurrence of
mk_kdev()and ofto_kdev_t()a flaw in the kernel, so this change does not make things better or worse insideinit_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?
Quoted 5 lines · Alexander Viro
Reasons:
a)foo_mknod()- why the hell would we takedev_t, pass it into
->mknod() only to split it into major:minor there and immediately rebuilddev_tfrom them? And that - for _all_ instances of ->mknod()
No, if you make init_special_inode() take minor/major, then you have to make mknod do the same.
At that point it becomes a ABI issue how the mknod _system_call_ argument is split up into major/minor, and the rest of the kernel wouldn't really care.
However, looking more at this, we clearly need to have the same ABI for stat() as for mknod(), so it probably makes sense to just continue to have "dev_t is a standard mix of minor/major" numbers approach, and just continue passing "dev_t" around exactly as such a combination (and then let people do the proper MKNOD/MAJOR/MINOR macros on it).
So you may be right - there are no real advantage from splitting the two, as long as dev_t and kdev_t cannot be mixed up by mistake (which is largely true already now).
Linus
Quoted 3 lines
At that point it becomes a ABI issue how the mknod _system_call_ argument is split up into major/minor, and the rest of the kernel wouldn't really care.
You need a mknod2() system call assuming we want hotplug to be able to create 32bit dev_t's. At the point glibc calls mknod its got an internal 32:32 representation so passing mknod2(char *,int,int) and making sure mknod doesnt break if we expand further some years hence doesn't seem to be daft.