On Thu, Dec 28, 2000 at 01:48:16PM -0500, Todd Vierling wrote:
> On Thu, 28 Dec 2000, Chuck Silvers wrote:
> 
> : actually this change is not completely backward compatible.
> : if someone has created device nodes with those upper minor bits set
> : (ie. for /dev/sd385792385a or whatever the number turns out to be),
> : then those device nodes would no longer refer to the same device
> : after this change.  to me, this falls into the same category as
> : the problem that __BROKEN_CONFIG_UNIT_USAGE indicates, that we make
> : assumptions about the usage of device minor numbers.  in this case
> : the assumption is that the upper bits of the minor number have not
> : been used by anyone anywhere.
> 
> : the only completely backward-compatible way to increase the number
> : of partitions is to create a new device major number for each current
> : device major that uses part of its minor as a partition.
> 
> There comes a point where supposition leads into ludicrous situations, and
> this is one of them.  If the extra partition bits are placed sufficiently
> high in the minor number to provide a reasonably large number of units (say,
> 16384 drives?), someone will have had to create nodes with ridiculously
> large unit numbers to conflict with them.
> 
> We don't control third-party, nonintegrated patches that may reuse minor
> bits for some other purpose--and in situations like these, we don't have to
> care.  Such third parties can update to match us, or contribute the changes
> to the mainline.  That's not our concern.

I didn't say anything about this.  I agree that third-party, nonintegrated
patches that may reuse minor bits for some other purpose are not relevant
to this discussion.

however, the use of high minor numbers to represent normal disks is
a currently supported feature of the official NetBSD distribution,
and changing the interpretation of the minor number would break that.


> We have already been down this road of discussion some time ago and came to
> the conclusion that reusing higher bits of the minor number for further
> partitions was perfectly acceptable.

who is the "we" that has had this discussion before?
I don't recall this method of changing the interpretation of
device minor numbers in an incompatible way being proposed
on tech-kern before, but maybe I missed it.  could you point me
to the thread in the mailing list archives?


> : I think we should consider a logical volume manager design
> : rather than continuing to fiddle with fixed-partitioning.
> 
> That's not addressed by this thread, and does not help people who want this
> feature right now.

the feature that people want is not "increase MAXPARTITIONS", it is
"allow me to divide my disks into more logical devices".  a logical volume
manage would provide this feature in a more flexible way than just
increasing MAXPARTITIONS.  for example, increasing MAXPARTITIONS from
8 to 16 does not allow dividing a disk into 17 pieces, whereas a
well-designed logical volume manager would allow that (and much more).

the fact that people want this feature right now does not justify
making incompatible changes that are clearly not the best solution.
back when ISA DMA was still an important issue for many people,
people wanted bounce-buffering "right now".  rather than just hack all
the relevant drivers to provide that, NetBSD designed and implemented
the bus_dma framework, which has been a far superiour solution in the
long run.  why would we start making design decisions based on expediency
now?  and changing the interpretation of device minor numbers has a far more
significant downside than the choice of ISA bounce-buffering schemes,
since the changing the interpretation of device minor numbers is visible
to applications and it breaks existing usage.

-Chuck