Subject: Re: Questions about 1.3
To: None <current-users@NetBSD.ORG>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 10/06/1997 11:25:00
[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
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.
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B