From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1UF7ZI-0003S6-M0 for mharc-grub-devel@gnu.org; Mon, 11 Mar 2013 14:35:28 -0400 Received: from eggs.gnu.org ([208.118.235.92]:38698) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UF7ZD-0003Rg-Rf for grub-devel@gnu.org; Mon, 11 Mar 2013 14:35:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UF7Z9-0001rF-1S for grub-devel@gnu.org; Mon, 11 Mar 2013 14:35:23 -0400 Received: from mail.csclub.uwaterloo.ca ([129.97.134.52]:60160) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UF7Z8-0001qm-SC for grub-devel@gnu.org; Mon, 11 Mar 2013 14:35:18 -0400 Received: from caffeine.csclub.uwaterloo.ca (caffeine.csclub.uwaterloo.ca [129.97.134.17]) by mail.csclub.uwaterloo.ca (Postfix) with SMTP id 002E720603; Mon, 11 Mar 2013 14:35:17 -0400 (EDT) Received: by caffeine.csclub.uwaterloo.ca (sSMTP sendmail emulation); Mon, 11 Mar 2013 14:35:16 -0400 From: "Lennart Sorensen" Date: Mon, 11 Mar 2013 14:35:16 -0400 To: The development of GNU GRUB Subject: Re: Best practice for new linux block driver device naming? Message-ID: <20130311183516.GC11989@csclub.uwaterloo.ca> References: <20130308200718.GK28545@beardog.cce.hp.com> <20130308215632.GA11989@csclub.uwaterloo.ca> <20130308223428.GL28545@beardog.cce.hp.com> <20130308224911.GB11989@csclub.uwaterloo.ca> <20130308230533.GM28545@beardog.cce.hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130308230533.GM28545@beardog.cce.hp.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 129.97.134.52 Cc: dab@hp.com, scameron@beardog.cce.hp.com X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 18:35:28 -0000 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