Re: Best practice for new linux block driver device naming?

["Lennart Sorensen" <lsorense@csclub.uwaterloo.ca>]

On Fri, Mar 08, 2013 at 05:05:33PM -0600, scameron@beardog.cce.hp.com wrote:
> We are not expecting to be able to boot from the device in the first iteration,
> so it's not as if we would need support instantly (not that I imagine we could
> get it instantly anyway), and it's not clear that it makes sense for such a high
> IOPS device to be used as a boot device in most imaginable use cases anyway, but
> OTOH, we would prefer not to rule out booting from it.
> 
> So, that being said, are there any best practices for naming new block device nodes?
> Or is any scheme like /dev/sop[0-9a-z] about as good/bad as any other?
> 
> And, is it a worthwhile idea to pursue adding some sort of shared device namespace
> for block devices to the kernel (maintaining backwards compatibility of device node
> names would of course be required) so that block devices could have some shared
> namespace as scsi devices do?
> 
> Typically the block devices themselves don't care what the device nodes are named, 
> only the userland apps do, though it falls to the block drivers to specify a device
> name via struct gendisk's ->disk_name member being set prior to calling add_disk().
> 
> If there were some kernel interface the block driver could use to get a disk name
> assigned from a shared name space, something like blk_get_new_disk_name(disk->disk_name);
> that could hand out device names like b%s, so you'd get all the block devices which use
> this interface having device names like /dev/bda, /dev/bdb, /dev/bdc, analogous to
> /dev/sda, /dev/sdb, etc. -- the specifics here don't matter to me, the above is just
> an idea off the top of my head -- then, we teach grub about this new block device
> namespace *once*, and force all new block drivers to use it.  Thereafter, adding a
> block driver to the kernel causes no more grub related pain to grub and distro
> developers and users than adding a new scsi hba driver -- i.e. none. 
> 
> Would such a thing be worth pursuing?  Or is there some good reason such a thing
> doesn't already exist?  (Maybe this is more a question for lkml.)

Oh it certainly sounds like a topic for lkml.

-- 
Len Sorensen