On 15 Oct 2000, Chris G. Demetriou wrote:

: However, allowing multiple device #s to indicate the same device in
: kernel, unless you're doing something else to ameliorate the device
: aliasing issue, will cause you to lose.

This is a compatibility issue.

I'm not quite sure what you mean here by `device aliasing issue'.  From what
I have seen while reading the device open code, the only places that
*really* care about device major numbers is the code finding the appropriate
struct device from a device name.  Whether you get there from major number
10 or major number 257, you still end up at the same struct device.

I don't see much problem with having the same pointer to a struct device in
more than one place in the tables.  One to allow the historic nodes to work
(which can be compiled in conditionally for compat purposes), and one in its
new, standardized location.

: it's not clear to me why you'd even bother.  putting them into one
: table just makes life easier, and if the entries in the tables are
: just pointers to the devsw tables that live in the device object
: files, the cost of even a fair number of extra entries isn't going to
: be significant.

That wasn't really my point; it was more along the lines that we'd need to
make sure that neither the fixed-numbering system nor the dynamic-numbering
system were significantly bounded for adding more new devices (like the
dynamic devices currently are, with the dummy entries).  A switch bit seemed
an easy solution by using different tables for the two; we could also simply
start numbering dynamic devices above the highest-numbered fixed device, but
that seems prone to user error as base kernels are upgraded.

-- 
-- Todd Vierling <tv@wasabisystems.com>  *  http://www.wasabisystems.com/
-- Speed, stability, security, and support.  Wasabi NetBSD:  Run with it.