> 
> [ Very little disagreement now.  "yay!" 8-]
> 
> > 2. The new major devcice numbers will be specific to a particular
> > architecture, but all machines in a particular ${MACHINE_ARCH} will use the
> > same device switch tables.  The major numbers will start at 1, to reserve 0
> > for an old dev_t flag.
> 
> Nobody's argued against it, so why not make there be One True Device
> Table (for _all_ ports)?

The concern I have about this is idea, which I also have about ${MACHINE_ARCH}
tables, is that we could end up with a lot of unused entries on m68k
ports.

For instance, we'd need 6 serial ports defined, one for the atari,
amiga, M.I. 8530 (mac68k, mvme68k, sun3(x)), x68k, and 2 for hp300. The atari
and x68k ports could use the M.I. driver, but then we'd still need
4 entries, at least half of which would never be used. There'd also
need to be entries for the Apple Desktop Bus, Apple Sound Chip, mice,
keyboards (the latter two of which aren't used on mac68k), whatever
the atari and amigas use for sound, HPIB drivers, and more.

Oh, wait. The atari port has two serial ports, so the above # would be
5 entries minimum.

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.

Then adding a lot of isa devices on top of that (from one common table)
and any other port-specific devices will grow things more. It just strikes
me as wasteful to tie all this space up. Though it might not matter on
a machine with 32 MB as a small amount of RAM and 64 common, a number
of m68k's get by on 8 MB or so.

The one strong argument I've heard in favor of unifying these tables,
at least at the ${MACHINE_ARCH} level, is for an install CD. But I think
we can get the same abilities another way. Isn't a mini-root environment
just a fat kernel to the boot loader? If not, can't it become one?

I mean we have to have a machine-specific kernel. If we shove a mini-root
in there, then we can have machine-specific device nodes & whatever
M.D. parts are needed, all in one package. Then each ${MACHINE_ARCH} can
still share lots of the user-land binaries.

In sumary, I think the idea of sharing as much as possable within an
arch is good, and can help installations (especially from CD). But we
get into a royal mess if we try to make one grand unified device table.

Take care,

Bill