Bill Studenmund <wrstuden@vali.stanford.edu> writes:

> 
> On 15 Jan 1998, Charles M. Hannum wrote:
> 
> > Bill Studenmund <wrstuden@vali.stanford.edu> 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.