Subject: Re: 32 bit dev_t, Revision 3
To: Chris G. Demetriou <cgd@pa.dec.com>
From: Todd Vierling <tv@NetBSD.ORG>
List: tech-kern
Date: 01/13/1998 12:34:29
On Tue, 13 Jan 1998, Chris G. Demetriou wrote:

: > Making all of that fit in one table seems gross to me. If we didn't use
: > the driver-registers-itself-in-table trick (the table being pointers to
: > the b/cdevsw entries), we'd end up with a lot of #if NWHATEVER > 0
: > {something} #else {null entry} #endif blocks, which I find hard to read.
: > Especially if we end up with nearly 100 of them on m68k.
: 
: I think that personally, i'd rather have all of those in one table
: than to have to go through all of the ports' tables each time, when
: adding a new machine-independent device to the kernel.

Problem with this is, I can eventually see us actually _using_up_ a thousand
device entries if we have a Grand Unified Table.  And by that time, every
port's table would be 99% nulls.  What's the point?

If we want fast-and-lean, yet easy to maintain, I'd say we should:
- have one table unique to each ${MACHINE_ARCH}
- use extern ints in each conf.c to define major numbers that for whatever
  reason, Really Really have to be checked outside of devsw
- renumber the Common Devices (console, mem, fd, ...?) to use a couple
  standard numbers at the start of the table to get us going

=====
===== 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