Date:        Sun, 5 Oct 2003 22:40:17 +1000
    From:        Luke Mewburn <lukem@NetBSD.org>
    Message-ID:  <20031005124017.GQ24725@mewburn.net>

I think this is an important argument ...

  |   | and that this would avoid major mapping problems for emulations
  |   | which use 8bit majors.

but this also ...

  | On the other hand, reserving a range of major numbers for "local" use 
  | would be useful; I'm sure I've seen this requested in the past.

is something which ought be done at the same time.

What I don't see any need for is that huge gap between the highest
current MD major number, and the planned lowest number in the new
blocks.

What possible reason would there be for anyone to assign a new MD major
number in the future?

The only rationale for MD numbers now is compatibility with other systems
(original vendor OS distributions).   That's a good reason - but reserving
a block of numbers in the NetBSD number space is not going to help with
that at all (and I'd guess, that 139 major numbers is plenty for just about
any vendor distribution...)

Note: there's no need for a MD driver (no matter how MD) to have a MD
major number - a MI number is the right thing to do, even for such drivers
(the driver might be very MD originally, but after a few years, who knows).

So, unless we have some evidence that vendors are about to start issuing
major numbers in the 140-191 block, that NetBSD wants to be compatible with,
I think I'd do

	144-191		Distribution (NetBSD Vendor) and local use majors
	192...		MI numbers for new NetBSD drivers.

The 144..191 space really needs dividing into two blocks as well, but
that division (my guess is that 8 majors for local use would be plenty)
can be sorted out later.

kre