> > 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?
> 
> maybe.  i'd be interested to see what the numbers look like right now.
> You can generalize how things will get as you add ports.
> 
> Even if we use 1000 device entries -- which i doubt -- your 99% number
> is nonsical unless we had 100 ports, and still wouldn't work out
> because of shared devices.

If we went with a table of pointers, I think a unified table might
be not-too-unwieldy. It could even be cool.

Especially if we break it up into chunks, so that #'s could be re-used
across ports.

Something like 192->207 are M.I. frame buffers (whatever the wscons stuff
becomes), 208->223 are M.D. frame buffers (M.D. interface), 224->231
are serial ports (with 224 being the internal, or "first choice"
serial driver)...

Also, we could allocate say 96 major #'s for whatever that port wanted.
These would be for things which don't overlap with other ports (like
the AppleSound Chip driver for mac68k). For security, we could say that
half the range should be owned by root only, and the other's ownable
by users (or not as secure).

> It's not clear to me that that's 'fat', and it certainly wouldn't be
> 'slow'.  (You said that if we wanted "fast-and-lean.")
> 
> Rather than fast and lean, i'd like fast, lean, and easy to maintain.
> 8-)

With a table of pointers, I think I now agree with you. :-)

Take care,

Bill