From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1UE53K-00053H-0E for mharc-grub-devel@gnu.org; Fri, 08 Mar 2013 16:42:10 -0500 Received: from eggs.gnu.org ([208.118.235.92]:49609) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UE3bi-0002co-NC for grub-devel@gnu.org; Fri, 08 Mar 2013 15:10:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UE3bB-0000zA-UW for grub-devel@gnu.org; Fri, 08 Mar 2013 15:09:34 -0500 Received: from g1t0029.austin.hp.com ([15.216.28.36]:6039) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UE3bB-0000o2-KQ for grub-devel@gnu.org; Fri, 08 Mar 2013 15:09:01 -0500 Received: from g1t0038.austin.hp.com (g1t0038.austin.hp.com [16.236.32.44]) by g1t0029.austin.hp.com (Postfix) with ESMTP id B5A6438169 for ; Fri, 8 Mar 2013 20:08:32 +0000 (UTC) Received: from beardog.cce.hp.com (beardog.cce.hp.com [16.84.84.24]) by g1t0038.austin.hp.com (Postfix) with ESMTP id A699930582; Fri, 8 Mar 2013 20:08:32 +0000 (UTC) Received: from beardog.cce.hp.com (beardog.cce.hp.com [127.0.0.1]) by beardog.cce.hp.com (8.13.8/8.13.8) with ESMTP id r28K7ICp000793; Fri, 8 Mar 2013 14:07:18 -0600 Received: (from scameron@localhost) by beardog.cce.hp.com (8.13.8/8.13.8/Submit) id r28K7Ib6000792; Fri, 8 Mar 2013 14:07:18 -0600 Date: Fri, 8 Mar 2013 14:07:18 -0600 From: scameron@beardog.cce.hp.com To: grub-devel@gnu.org Subject: Best practice for new linux block driver device naming? Message-ID: <20130308200718.GK28545@beardog.cce.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x X-Received-From: 15.216.28.36 X-Mailman-Approved-At: Fri, 08 Mar 2013 16:42:08 -0500 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: Fri, 08 Mar 2013 20:10:06 -0000 Hi, I'm just wondering if there are best pratices for new linux block drivers that are adding new devices nodes of which grub is currently not cognizant. E.g. when we added the HP Smart Array cciss driver to the kernel many years ago, it had device nodes like /dev/cciss/c*d*, and there's code in grub to handle this in util/getroot.c, in convert_system_partition_to_system_disk(): /* If this is a CCISS disk. */ if (strncmp ("cciss/c", p, sizeof ("cciss/c") - 1) == 0) { /* /dev/cciss/c[0-9]+d[0-9]+(p[0-9]+)? */ p = strchr (p, 'p'); if (p) { *is_part = 1; *p = '\0'; } return path; } And there is similar code for other weird device names is in there as well. Ideally, I'm hoping there's a way to introduce new devices nodes with a new block driver which does not any require grub modifications. Looking over the code, it's not clear to me whether or not this is possible, and if it is, how to do it, what the constraints may be, etc. Currently I have a new driver which adds devices like /dev/sop0 with partitions like /dev/sop0p1, /dev/sop0p2, etc. If there is some better way to do this to enable grub to work with these devices, it is not yet too late for me to change it. Or on the other hand, if it turns out that it is not possible to add new block devices to linux and have grub support for those devices without also modifying grub, then I wonder if it might be worth looking into to adding some kind of shared device namespace for block devices to linux, so new block drivers could use that and have a common naming system for block devices, and grub could be modified to support this new common naming system, much as scsi hba device drivers share the /dev/sd* namespace for their attached disks, so it is easy to add new scsi hba drivers to linux and automatically have grub support for them. It would be nice if it were similarly easy to add new block device drivers to linux without also requiring modifications to grub. (It also occurs to me that this is such an obvious desire that if it is not already supported, perhaps there's a good reason why not, but if that's the case, I'm don't know what the reason might be.) Thoughts? Thanks, -- steve