On 14 Jan 1998, Charles M. Hannum wrote:

: Honestly, I think you weren't paying attention.  My proposal includes
: all old device numbers within the same encoding scheme as any new
: device numbers.  The proposal for renumbering is essentially to
: deprecate the old 256 major numbers, and shift the major numbers up by
: 256.  [In reality, you could just deprecate the major numbers formerly
: used by disk drivers, since none of the other minor number encodings
: will change. [*]] There's no need to do these at the same time; the
: move to the new encoding can be done at any time, because it doesn't
: change the actual encoding or the meaning of any existing device
: numbers.

The problem with the minor-split proposal you had was that it would require
devices, once renumbered, to handle two different kinds of minor numbers. 
That, on top of the extra work to shuffle the bits, is more than is really
needed.  I took the best of both worlds in my test implementation and did
the following: 

- 12/20 split on new dev_t's
- 16 bit dev_t's converted to 32 bit only when:
  - storing in specinfo struct
  - comparing in vfs_subr.c
  - looking up hash values in SPECHASH()
- 32 bit `major 0' indicates 16 bit device
- minor number conversion only occurs when an entry in the 16->32 conversion
  table has a non-NULL minor number conversion function

The 16->32 conversion table is an architecture-specific array of the
following:

struct devto32 {
	u_int		newmaj;
	const u_int	(*newmin) __P((dev_t));
};

The newmin function is only called when non-NULL, and allows each device to
specify conversion routines on a one-by-one basis.  This way, people can use
16 bit devices without any change, and the major number renumbering can
happen immediately.  Then, once we're confident on what the minor number
renumberings "should" be, and each respective device gets an appropriate
minor renumbering function, those device nodes can be upgraded to 32 bits.

The minor numbers might even change _again_ before 1.4 if there's
disagreement on some of the renumberings, but the 16 bit nodes will still
work, so as long as you haven't upgraded any nodes, you should be set.
People upgrading 1.3->1.4 will be completely transparent.

: As for unit/subunit splitting, I think 6 bits of subunit is a
: reasonable compromise.  64 partitions seems more than enough, and I
: can envision wanting to have more than 12 bits of unit (disk) number
: in the not-so-distant future.

Though, if there's need for splitting it because there are two types of
layers (say, MBR and disklabel), 6 may not be enough.  I favor 12/8 because
of its hexadecimal readability and its ability to make 16 bit nodes show up
in a very simple way as `0,maj,min' in a listing.

=====
===== Todd Vierling (Personal tv@pobox.com) =====
== "There's a myth that there is a scarcity of justice to go around, so
== that if we extend justice to 'those people,' it will somehow erode the
== quality of justice everyone else receives."  -- Maria Price