Subject: Re: 32 bit dev_t, Revision 2
To: Todd Vierling <tv@NetBSD.ORG>
From: Chris G. Demetriou <>
List: tech-kern
Date: 01/11/1998 16:49:27
> : > Well, one bit mask at the very least is a good thing: MI versus MD devices. 
> : 
> : No it's not.  (I was about to say this in another message, too.  8-)
> : 
> : Why is it important?  What does it accomplish?
> Reduces bloat in the devsw tables, if you use separate MI and MD tables.

Piffle!  Two tables == more work for the kernel to do, in lots of
places.  One table == less work for the kernel to do.

So there are a couple entries per ${MACHINE} in a ${MACHINE_ARCH}'s
devsw which don't apply to your particular machine.  "Who cares?"

> : However, between different ${MACHINE_ARCH}s, there are _so_ many other
> : problems that need to be solved that getting an extra copy of the
> : device nodes for the right arch just isn't very hard, if you're trying
> : to do common media.
> Hrm?  So are you suggesting that (1) device numbers between different
> ${MACHINE_ARCH}es should have zero correlation, or that (2) they should
> always match even if they don't exist on a different ${MACHINE_ARCH}?  I
> thought we were trying to move toward having some commonality in MI device
> numbers... that's why I suggested a MI/MD split of two tables.

They should have _no_ correlation between ${MACHINE_ARCH}s whatsoever,
or all ports should share _exactly_ the same device switch.

Some people want a single, global kernel device switch.  I think that
can be argued either way, and I don't particularly care one way or

What's really important, however, is that, for each ${MACHINE_ARCH},
within that signel ${MACHINE_ARCH} all ${MACHINE}s have the same
device switch entries for all devices, so you can e.g. netboot any
${MACHINE} of a single ${MACHINE_ARCH} off the same server root.

It's not particularly important to have 'sd' be the same major number
on different ${MACHINE_ARCH}s, unless you really do want one global

You could do the latter, but it's not important.  I'm willing to pay
no complexity for it.

If the goal is really to do that, then argue for a single,
Machine-independent device swtich table.