Todd Vierling <tv@NetBSD.ORG> writes:

> 
> : 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.)
> 
> The point I'm making is,
> 
> *why are you using a new MAKEDEV and an old mknod, or a new mknod and an old
> MAKEDEV?*

The point I'm making is:

People do it all the bloody time.  Get your head out of the sand!

It's even what happens by *default* when I upgrade -- because /etc and
/dev/MAKEDEV are not automatically changed.

> If this is the only problem you see, causing all of this commotion, [...]

J**** H. F****** C***** O* A P*** S****!!!  I listed several things in
my mail, several times, that I consider problems, and you've managed
to ignore all but one -- and it took *how many* exchanges of email
before you finally noticed that one?  This is ridiculous!  Go read my
mail again before you say *anything* more!

> - change mknod(8) NOW to accept two command line options to define the
>   number of contiguous major and minor bits (this will also win us the
>   ability to create nodes to NFS-export to other systems)
> - update all the MAKEDEV scripts NOW to make use of this new option and
>   deliberately make 16-bit nodes
> - tell people thrice to upgrade both NOW or they will break when the move
>   happens
> - when the nodes `update' to 32 bits, the MAKEDEV scripts will work in one
>   of two modes: `old mode' (creates the well-known 16 bit nodes) and
>   `new mode' (creates the 32 bit nodes).  No matter whether they update
>   MAKEDEV or not, it works.

That *still* doesn't solve any of the UI problems, it *still* doesn't
give us a clean solution for future minor number changes, and it
*doesn't* avoid having a flag day.  In other words, it only
half-addresses one of several points.