[ On Sat, October 3, 1998 at 12:42:28 (-0700), Bill Studenmund wrote: ]
> Subject: Re: Another changer, another changer problem
>
> The problem is that to put the "raw" partition out of band, we need
> another major number dedicated to the drive type. So sd's would have two
> devices, and wd's would have two...

Another "major" number?  Huh?  Though I've not done the math yet I see
no problem with dedicating a specific *minor* number to the raw disk and
still having lots left over for 8 or more partitions per disk.

> As it is, we'll have multiple major numbers for disks soon anyway. Why
> double that?

We might need multiple major numbers for multiple scsi buses, but that's
a whole different issue.  A separate major number for each wd controller
might be a good idea too....

All of this is why I suggested an alternate plan of using a consistent
naming scheme such as:

	{driver-name}{driver-unit}t{target-unit}l{LUN}

which would give names such as /dev/esp0t0l0 or /dev/ahc0t0l0 and so on
for each "raw" disk (with either letters or "p{partition}" appended to
identify partitions according to the current disklabel).

> One of the big concerns with moving to 32-bit devices is that major
> numbers made on a 32-bit aware system should work on a 32-bit unaware
> system. The easiest solution was to make the unit/partition split vary w/
> major number. Then you'd have 8-partition wd's, a dn 32- or 64-partition
> wd's. That way, on an i386, major 0 would always be a wd w/ 8 partitions.
> Out of band raw partitions double even that. 

Double HUH?

There's a wee window when you're booting a new kernel on an old
filesystem when you'll need to run MAKEDEV or do something similar to
get the new wide-numbered devices made, but this could have been handled
in any number of ways, including use of a new revision of the filesystem
structure itself (and then even fsck could resize the major/minor
numbers and the kernel would read either 16-bit major/minor number or
32-bit or 64-bit ones depending on what the superblock says to do.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>