Frederick Bruckman wrote:

> The change is noted in the "Changes from 1.5 to 1.6" section of the CHANGES
> file, at least.
> 
> The trick you noticed, was so that the device file "/dev/sd1a" (and others)
> would not suddenly become useless after a kernel upgrade. (That device file
> would point to the actual partion "sd0i".) Nowadays we might train "rc.d" to
> fix it up at first boot, but "rc.d" was new, then. There was much discussion,
> and transparency to users finally won out over elegance.

As I did (mean to) suggest in my first message, I don't see anything wrong
with using such a trick.  But there are two places it needs to be clearly
commented.  One is in disklabel.h, directly above the line

  #define MAXPARTITIONS 16

and the other is in files.i386, directly above the line

  maxpartitions 8

Each one has to refer the reader to the other one, with an explanation that
doesn't need to be any longer than the paragraph you just wrote.  The trouble
is, with that discrepancy as it stands and no comment, a conscientious sysadmin
coming to NetBSD for the first time is going to be very leery of using more
than 8 partitions, and maybe of using NetBSD at all.  (How many other such
apparent discrepancies are going to turn up?)  It makes a crummy first
impression.

> The change is noted in the "Changes from 1.5 to 1.6" section of the CHANGES
> file, at least.

Yeah, but the note's useless.  It says:

  bump maximum partition number to 16 [tron 20010102]

At least the date gives the reader a hint where to look in CVS to see if
maybe the commit message explains things.  There just isn't any entry to
files.i386 for that date, and the entry for disklabel.h says:

  Use highest bit of minor as an extra bit for the partition number to
  bump the maximum partition number on NetBSD-i386 to 16. (Approved by fvdl)

That's almost useful ... at least it gives a sort of tantalizing hint that
the missing update to files.i386 might possibly not be accidental.  What it
doesn't say is "and this means we leave maxpartitions at 8 in files.i386 and
therefore as long as [state conditions] hold, old device nodes will Just Work;
fvdl said this trick was ok."

It's still no substitute for having the trick adequately commented in the
files where a sysadmin is going to stumble on the trick.  Usually the times
when a sysadmin is looking at things like disklabel.h are not the times most
convenient for rummaging through CVS comments on a remote server for clues
whether s/he has just stumbled on a deliberate trick or a bonehead mistake
... though in this case I did before I posted the question.  :)

Thanks for clearing it up.

-Chap