- keep new dev numbers strictly in sync (like sparc and sparc64 do)
i think this is the crux of the problem; for a purely cosmetic
reason a different device format was chosen.
mrg.

>- keep new dev numbers strictly in sync (like sparc and sparc64 do)
i think this is the crux of the problem; for a purely cosmetic reason
a different device format was chosen.

Purely cosmetic? I thought it was done to avoid a flag day in /dev
when switching from an 8-partition kernel to a 16-partition kernel.

course, you may consider that "purely cosmetic". Personally, I'm
inclined to agree, but I suspect a lot of relatively U users
would disagree.

/~\ The ASCIIder Mouse
\ / Ribbon Campaign
X Against HTML mouse (AT) rodents (DOT) montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

Tue, Jan 03, 2006 at 04:12:05PM -0500, der Mouse wrote:
Purely cosmetic? I thought it was done to avoid a flag day in /dev
when switching from an 8-partition kernel to a 16-partition kernel.

Heh, I think he is talking about amd64 *not* doing the same dance but
using straight numbers (for purely cosmetic reasons ;-})

Martin

Martin Husemann <martin (AT) duskware (DOT) dequoted me and wrote (Quentin
Garnier also posted something similar):

[about amd64-vs-i386 /dev minor numbers]
>Purely cosmetic? I thought it was done to avoid a flag day in /dev
>when switching from an 8-partition kernel to a 16-partition kernel.
Heh, I think he is talking about amd64 *not* doing the same dance but
using straight numbers (for purely cosmetic reasons ;-})

I would disagree that the reasons are purely cosmetic. Uniformity
across multiple architectures is worth something - if nothing else, it
brings us closer to the day when multiple diskless machines can share
/dev even if they're of different archs.

I still think i386 should have bit the bullet and declared a flag day
when they went to 16 majors per - or if they really wanted to preserve
compatability, leave the old majors at 8 per and use new (and
preferably MI) majors for 16 per. But I suppose it's too late now.

/~\ The ASCIIder Mouse
\ / Ribbon Campaign
X Against HTML mouse (AT) rodents (DOT) montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

Tue, Jan 03, 2006 at 11:51:23PM +0100, Quentin Garnier wrote:
Tue, Jan 03, 2006 at 04:12:05PM -0500, der Mouse wrote:
>- keep new dev numbers strictly in sync (like sparc and sparc64 do)
i think this is the crux of the problem; for a purely cosmetic reason
a different device format was chosen.

Purely cosmetic? I thought it was done to avoid a flag day in /dev
when switching from an 8-partition kernel to a 16-partition kernel.

course, you may consider that "purely cosmetic". Personally, I'm
inclined to agree, but I suspect a lot of relatively Unix-na?ve users
would disagree.

The choice was cosmetic for the amd64 port. And that's what bitting us
now.

I disagree. What was done for the i386 port should have been done
differently; it was a grotesque hack that should not have been propogated.

The amd64 port did the right thing by not carrying it forward.

Take care,

Bill

PGP SIGNATURE
Version: GnuPG v1.2.3 (NetBSD)

jeFmEalalFzw2pYof4pe4vM=
=JSF7
PGP SIGNATURE