[ Very little disagreement now.  "yay!" 8-]

> 2. The new major devcice numbers will be specific to a particular
> architecture, but all machines in a particular ${MACHINE_ARCH} will use the
> same device switch tables.  The major numbers will start at 1, to reserve 0
> for an old dev_t flag.

Nobody's argued against it, so why not make there be One True Device
Table (for _all_ ports)?


> 3. Character and block device major numbers for a given device must match.
> If a character device or a block device does not have a corresponding
> counterpart, the counterpart will be unconfigured.  After transitioning the
> character/block device API to distinguish character and block devices in
> the function call arguments, the device switches will be merged.

As noted in other mail, I'm not sure that's entirely necessary...

Of the routines with the same 'name' (open, close, etc.) for both
block and character devices, only ioctl isn't passed a 'devtype' flag
as-is.  Given that ioctl isn't passed a devtype flag, and the same
ioctl routine is used for both block and char right now, it's not
clear how marging the tables would cause a problem.


> 4. When COMPAT_[09-13] is defined in the kernel, the macros major() and
> minor() will include inlined support for an old-to-new device number
> conversion table (one for block, and one for character).  Major numbers will
> be converted by integers in the table, and minor numbers by functions
> pointed to by the table. 

Historically, if N is the last release, COMPAT_<N> is required to run
binaries for that release _or before_, i.e. COMPAT_13 is required to
run 1.3 binaries or 1.2 binaries, or ..., COMPAT_12 is required to 
run 1.2 binaries, or ..., etc.

That's not necessarily good, but it's the way that things are.

Therefore, unless that's going to be changed, you should just
conditionalize that stuff with COMPAT_13 (and, for the code in
user-visible headers, _KERNEL).


> 5. The old (pre-1.3 and some COMPAT_<os>) stat interfaces, if included by a
> COMPAT_[09-13] option, will do direct searchs of the old-to-new table above
> to demote new dev_t's to 16 bit dev_t's.  This can cause no-matches, which
> should be listed as major number 255.  Programs _needing_ use of the major
> and minor numbers of a dev_t should conceivably be recompiled, but this
> gives _some_ useful values in the case where compatibility is required, such
> as finding a process's tty device based on device number.  Compat routines
> for other OS's may also require this inverse mapping, or may use a
> "truncated" major device number. 

I'm still not sure that this is particularly important.

If it's going to be done, you need to allow reverse-mapping of minor
numbers, too.


Assuming that the prototypes of the minor-conversion functions are
going to be:
	dev_t foo(dev_t);
(or int foo(dev_t), or something similar, i.e. no pointers passed),
they should also be marked 'const' so gcc can perform common
subexpression elimination on their results.  8-)


chris