Subject: Re: 32 bit dev_t, Revision 2
To: Perry E. Metzger <perry@piermont.com>
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
call....
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
bit-and.
: 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 tv@pobox.com) =====
== "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