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

[Lennart Sorensen]

On Fri, Mar 08, 2013 at 05:05:33PM -0600, address@hidden 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