Subject: Re: dev_t changes & partitions
To: Bill Studenmund <firstname.lastname@example.org>
From: Charles M. Hannum <email@example.com>
Date: 01/15/1998 18:51:00
Bill Studenmund <firstname.lastname@example.org> writes:
> On 15 Jan 1998, Charles M. Hannum wrote:
> > Bill Studenmund <email@example.com> writes:
> > > True. But then we will be splicing minor numbers together until we move to
> > > 64-bit dev_t's. :-) That just seems kinda goofy.
> > If `seems kinda goofy' is the best argument anyone can come up with,
> > I'd say that's flat out ridiculous. You're *going* to screw over
> > users by making old MAKEDEVs DTWT. Making the device numbers look
> > `pretty' in hex is, quite frankly, a *stupid* reason to screw over
> > users.
> Wait. Why are we going to screw over users?
Dude, have you actually been reading what I wrote? Pretend I'm a
user. I install a snapshot, or I rebuild everything and install it.
I run MAKEDEV to add a new disk and newfs(8) it. Oops; I trashed the
wrong disk because I didn't reinstall MAKEDEV. At this point I find
an OS that doesn't screw me over in this way periodically, because I
have better things to do with my time. (Unfortunately, there are none
-- at least not Unix-like. Hence we get continual screams of pain and
Un*x maintains its position as being arcane and user-hostile.)
> We have two ideas of what the dev_t is. One, the one returned by stat and
> fstat & friends, is what's on the disk. The other, used internally by the
> kernel, is in the kernel's internal representation (stored in va_rdev).
That's si_rdev, a.k.a. v_rdev. va_rdev is something very different.
> The thing I don't like about the split-minor proposal is that it's bending
> over backwards for compatability. Since we DO have a smooth upgrade path
> w/o this trick, I'd rather we make a clean break with the past.
`Bending over backwards'? Any more than keeping old version of
library functions or system call interfaces? Or making certain
combinations of bogus mmap(2) flags work for old X servers? Or making
386BSD executables continue to run? Or a hundred other little things
that few people ever notice? I mean, why even have the old-style
syscall interface at all? There are much better ways to do it.
In practice, the layout of dev_t is something that virtually noone
ever sees, except through the tinted specs of ls(1), which splits them
into a nice format for you anyway. (And the dump routine -- like that
shouldn't use major() and minor() anyway.) Worrying about what the
numbers look like in hex, when there are more serious factors at hand,
is just plain silly.