Todd Vierling <tv@netbsd.org> writes:

> 
> On 15 Jan 1998, Charles M. Hannum wrote:
> 
> : > I integrated your suggestions on how to handle struct specinfo with zero
> : > trouble, and I did *not8 use the split minor format.  Pleas tell me how this
> : > screws over users?
> : 
> : Yes, you did so in a way that violates at least 1 standard (by adding
> : another mandatory argument to mknod(8) to get new-style device nodes).
> 
> The mknod(8) change proposals are unrelated to this....
> 
> : Also, your proposal:
> : 
> : * makes ls(1) display bogus info for old-style device nodes, and
> 
> Um, why does it matter?  On the old ls(1) binary, 32 bit nodes will look
> bogus too.  This is a ludicrous reason to make the structure of dev_t messy,
> yet as far as I have seen, is the only plausible reason to use a split
> minor.  Aren't we trying to avoid more cosmetic hacks vs. manageability? 

Okay, so you've just convinced me that you haven't actually understood
more than 5% of what I've written in this thread.

*You* are the one who's arguing for cosmetic purity (in reading device
numbers in a way that people DON'T DO).  I'm arguing for a way to move
to large major and minor numbers in a 100% totally manageable way,
that allows developers to update their ports at whatever pace they
want, that allows us to redefine any minor unit number encoding in the
future without further hacks, that allows old MAKEDEVs to generate
usable device nodes without any hacks at all, *and* that doesn't break
things like the output of ls(1).  Roughly speaking, *the average user
doesn't even have to know that anything has changed*.  To use an
analogy: what you're talking about throws tPoLS out the window -- at
the top of a skyscraper.

Now, who is talking about a `transparent' upgrade here?  Certainly not
you.  What you're talking about is highly user-visible and quite
confusing to someone who doesn't understand the implementation issues.

> : * makes the output of major() and minor() invalid for feeding back to
> : mknod(8), because it would pack them in the wrong format.
> 
> Um, why would you be taking the output of major() and minor() and feeding it
> to mknod(8) and not mknod(2)?  That's broken, period.

Uh, so, if I see:

crw-rw-rw-  1 root  wheel    2,   2 Jan 15 21:11 /dev/null

then it's `broken' for me to type `mknod ~ftp/dev/null c 2 2'?  Excuse
me?!  This is *required* to work -- if not by an `official' standard,
then by *me*.

> The only thing I'd see as a problem is running mknod(8) with an old MAKEDEV
> script, but why would you do that when your /dev is already there?

How about because I added a new disk?  Or a tape drive?  Or I want
more ptys?  This should be obvious.

> I was explaining a point I had to reexplain several times today.

Clue:

YOU'RE EXPLAINING SOMETHING I ALREADY KNOW.  The problem is that
you're *ignoring* me when I *repeatedly* tell you why this breaks.

> Restructuring dev_t as you proposed just adds
> marginal readability at the cost of kernel cruft and additional
> compatibility issues. 

No, there is *no* `additional cruft' and there are *no* `additional
compatibility issues'.  You haven't yet mentioned *any* `problem'
that's not also a `problem' in your proposal.  And in practice the
only one is that an old ls(1) will truncate some bits.  `How horrible.
What will I ever do?'


In case it isn't obvious, I'm rapidly tiring of this `discussion'.
You're clearing not paying attention to what I say, and what you
suggest is clearly broken.  If your next message does not demonstrate
that you've at least *read* what I wrote, I will not discuss the
subject any further with you.