Subject: Re: 32 bit dev_t, Revision 2
To: Perry E. Metzger <>
From: Todd Vierling <tv@NetBSD.ORG>
List: tech-kern
Date: 01/11/1998 19:54:39
On Sun, 11 Jan 1998, Perry E. Metzger wrote:

: > : to dividing it that way. Any arbitrary split will be fine, and
: > : allocating the first 2k to dynamic devices when no real machine has
: > : more than 20 or 30 devices at most is not reasonable.
: > 
: > Perhaps:
: > 
: > 2048 MI statically allocated (and X number of LKM dynamic, for now),
: > 1024 MD statically allocated,
: > 1024 future expansion (not defined yet).
: > 
: > The split makes checking for them easier (via bit-tests).
: I don't like this, because it forces a devswitch table of over 2000
: entries even though we really don't need one. We can allocate these
: things better than that, in small ranges.

The idea is _two_tables_.  One that sits in the MI part of the source tree,
and one in the MD part of the tree.  I'm sensing a lot of ambiguity and
miscommunication here.  My idea, in detail, was: 

- we have two tables, one with MI devices in src/sys/conf, and one in the MD
  part, divided by ${MACHINE_ARCH}.
- a bit-test, followed by bit-and, can provide a quick lookup in either
  table (once the table is determined, a bit-and strips the extraneous ID bits).

This arrangement allows for coordination of MI devices, and has zero table
bloat (and no "extra blank entries") from devices not in a ${MACHINE_ARCH}. 
If we don't care about the major numbers of MI devices matching up, we can
just make one table per ${MACHINE_ARCH} and be done with it.  It's not my

A similar alternative was the suggestion that we count up from the bottom
for MI and down from the top for MD; it would still need two tables but the
operation to look through the second table would be a subtract instead of

: Anyway, 99% of the design doesn't involve this part. Why not put this
: off until we've had a chance to tally all the ports devices and see
: how many slots we need right now for what?

Well, if we decide now to have two tables, tally can be done later.  This
point is a little pivotal to doing the first implementation, and I'd like to
get the specifics straight.  Is it one table in each ${MACHINE_ARCH} and one
in MI, or one (merged, but not number-coordinated with other archs) table
per arch? 

===== Todd Vierling (Personal =====
== "There's a myth that there is a scarcity of justice to go around, so
== that if we extend justice to 'those people,' it will somehow erode the
== quality of justice everyone else receives."  -- Maria Price