--3XA6nns4nE4KvaS/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Oct 05, 2003 at 07:55:57PM +0700, Robert Elz wrote:
>     Date:        Sun, 5 Oct 2003 22:40:17 +1000
>     From:        Luke Mewburn <lukem@NetBSD.org>
>     Message-ID:  <20031005124017.GQ24725@mewburn.net>
>=20
> I think this is an important argument ...
>=20
>   |   | and that this would avoid major mapping problems for emulations
>   |   | which use 8bit majors.

Is it? Mapping is a table lookup each way (to/from emulation) isn't it?=20
All this does is make emul -> NetBSD entries grow ot 16 bits, and add=20
slots to the NetBSD -> emul table.

I'm not sure what happens when we have more than 256 majors we want the=20
enulation to see. :-)

> but this also ...
>=20
>   | On the other hand, reserving a range of major numbers for "local" use=
=20
>   | would be useful; I'm sure I've seen this requested in the past.
>=20
> is something which ought be done at the same time.
>=20
> 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.
>=20
> What possible reason would there be for anyone to assign a new MD major
> number in the future?

Hmmm... I've thought about this, and think you're right. There is no=20
reason.

> 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 abo=
ut
> any vendor distribution...)
>=20
> 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=
).

Yeah, the way hardware goes these days there is a lot of mix&match, so=20
this is probably the safest thing to do.

It may make for sparse tables, but I think it's the best.

Take care,

Bill

--3XA6nns4nE4KvaS/
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQE/ggEFWz+3JHUci9cRAhYoAJwOlUTSI9GaLp3KQjnHsuzP8GI46gCfdYai
4M6PG3GQFpXbtWmoJU56At0=
=MlEg
-----END PGP SIGNATURE-----

--3XA6nns4nE4KvaS/--