[stuff about going from 8 to 16 partitions]
>>> But none of these things sounds reasonable in the context of a code
>>> freeze that's three weeks away.  This is a change that should be
>>> made and given a _lot_ of time to settle out, not just three weeks.

>> Heh.  I agree that this should not be in 1.3, though I'm not
>> convinced it needs all that much settling out; [...problems: 16
>> packs instead of 32, and the upgrade problem...upgrade hell is the
>> reason for saying it doesn't belong in 1.3...]

> My thought on dealing with the upgrade interrum was that the kernel
> could just go look at /dev and see what's there.

I am very reluctant to attach any actual semantics to pathnames in the
kernel (like hardwiring "/dev").

> The right time to do it would be when we look to see if /dev/console
> exists.

The reason I made an exception here is that the worst that happens if
the test goes wrong is that a noise message gets printed.  But if you
depend on /dev for disk partition numbering and it goes wrong, you can
find yourself incapable of talking to your disks.

Personally, I'd like to see this in user-land: that a user-land program
would look at /dev and somehow upload to the kernel the mapping from
minor numbers to <unit,partition> pairs.  Perhaps a sysctl?

> Well, that's what I'd supported for quite a while.  But since I've
> heard Jason mention just going to a different device storage on disk,
> I like that idea better. :-)

In general, so do I.  A 32-bit dev_t would be a much better fix.  In
the meantime, I'm using 16-partition 16-pack systems and liking them.
In my Copious Spare Time, one of the things I want to do is work out
patches to push dev_t up to 32 bits.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B