On Oct 3,  9:30pm, Greg A. Woods wrote:
} [ On Sat, October 3, 1998 at 12:42:28 (-0700), Bill Studenmund wrote: ]
} >
} > 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.

     I would think that it would be something like "RAWDISK" + 15
partitions.  That way we could still use bitwise operations to
determine which disk a particular minor number is on.  If we lose this
ability, then it greatly slows down the opening of a disk device.  Of
course, given how often a disk device is opened, it may not matter.

} > 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....

     This would be a really radical change.  Right now, a major number
specifies a device driver regardless of what bus it uses.  Now you
want a major number to specify a bus.  This would mean a lot of major
changes to the kernel.  I'm not sure the gain would be worth the pain.
How would you devide up the minor number between devices?  Don't
forget that scsibus'es can have many different types of devices
attached, not just disks.  How would you get from an inode to a device
(i.e. what is the path through the kernel)?  Would you only assign
major numbers to auxillary buses (SCSI, USB, etc.), or would you also
assign them to system buses (PCI, ISA, VME, SBUS, etc.)?  How would
you handle devices that aren't normally on an auxillary bus (NIC
cards, serial ports, video cards, etc.)?

} > 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.

     This problem has already been solved.  Basically, a major number
of less then 255 would instruct the kernel to use the old method, and
to flag the equivalent "wide" device as open as well.  This way there
is no crossover day, and you only need to use the new "wide" devices
if you want the new features.  As for the filesystem, it already has
32 bit wide major/minor numbers.  Currently, we only use 16 bits,
that's all.

}-- End of excerpt from Greg A. Woods