Subject: Re: dev_t changes & partitions
To: Todd Vierling <tv@NetBSD.ORG>
From: Charles M. Hannum <email@example.com>
Date: 01/15/1998 22:10:30
Todd Vierling <tv@NetBSD.ORG> writes:
> On 15 Jan 1998, Charles M. Hannum wrote:
> : > 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.
> Um, you never rebuilt with 32 bit nodes, so you're still using 16 bit nodes.
> These are translated with the compatibility code. `Where's the breakage?'
So, this is a prime example of why I'm getting agitated at you:
I *specifically* said `I run MAKEDEV to add a new disk'. Did you read
that? If you did, then it should be obvious that the (old, which I
pointed out in text you didn't quote) MAKEDEV just wrote a `32-bit'
device node using the old major and minor number. (So it's now
pointing to the wrong disk device. When I run newfs(8), it blows away
my other disk.)
> There is no breakage by having a minor number translated at vnode creation
> time, and just used as a 32 bit node as-is. And there's also zero
> renumber handling required by the devices--they _are_ renumbered, but you
> don't see it because you're using the same nodes you've used all along.
> (With a split minor you have to selectively renumber 16 bit devices to 32
> bit devices.)
With my proposal, you do the renumbering in almost exactly the same
way I suggested doing it for your proposal -- except that you detect
whether you have to reformat the minor number for a given device node
in a different way. You can do it `selectively' if you want, or you
can deprecate all 256 of the old major numbers. I *clearly* mentioned
doing is selectively as an *option*, because it's administratively
easier to not require everyone to change their ports at the same time.
In short, `What the Hell are you talking about?'