Subject: Re: 32 bit dev_t, Revision 3
To: Chris G. Demetriou <cgd@pa.dec.com>
From: Todd Vierling <tv@NetBSD.ORG>
List: tech-kern
Date: 01/12/1998 06:07:10
On Sun, 11 Jan 1998, Chris G. Demetriou wrote:

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

That's what discussion is for.  And might I say, it's working well.

: > 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)?

: 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.

Well, that does require some source purification (since many devices don't
check the devtype flag), but that isn't insanely difficult.  I'll make this
`second pass material'. 

: 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.

Then we may need to ensure that the COMPAT options depend on the later
revisions... add it to the projects list <g>

So strike it and say that it matters for COMPAT_13.

: > 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.
  [...]
: 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.

Not really.

All I care about is that the major numbers exist in some form in 16-bit
space, so fstat()-plus-stat() (such as in ttyname()) works, and that there's
no ambiguity as to the major device number when comparing 16-bit dev_t's. 
`some useful values'.  There will be some breakage, because it's too much
work to translate everything two ways; we just care that it works enough
for our _needs_.

: 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-)

Okie, will note that fur shure.

=====
===== 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