From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1UE5HT-0001D5-9u for mharc-grub-devel@gnu.org; Fri, 08 Mar 2013 16:56:47 -0500 Received: from eggs.gnu.org ([208.118.235.92]:45274) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UE5HM-0001Cu-DL for grub-devel@gnu.org; Fri, 08 Mar 2013 16:56:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UE5HH-0004Jp-1O for grub-devel@gnu.org; Fri, 08 Mar 2013 16:56:40 -0500 Received: from mail.csclub.uwaterloo.ca ([129.97.134.52]:34637) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UE5HG-0004Jf-RC for grub-devel@gnu.org; Fri, 08 Mar 2013 16:56:34 -0500 Received: from caffeine.csclub.uwaterloo.ca (caffeine.csclub.uwaterloo.ca [129.97.134.17]) by mail.csclub.uwaterloo.ca (Postfix) with SMTP id C1E7821060; Fri, 8 Mar 2013 16:56:32 -0500 (EST) Received: by caffeine.csclub.uwaterloo.ca (sSMTP sendmail emulation); Fri, 08 Mar 2013 16:56:32 -0500 From: "Lennart Sorensen" Date: Fri, 8 Mar 2013 16:56:32 -0500 To: The development of GNU GRUB Subject: Re: Best practice for new linux block driver device naming? Message-ID: <20130308215632.GA11989@csclub.uwaterloo.ca> References: <20130308200718.GK28545@beardog.cce.hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130308200718.GK28545@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: Fri, 08 Mar 2013 21:56:46 -0000 On Fri, Mar 08, 2013 at 02:07:18PM -0600, scameron@beardog.cce.hp.com wrote: > 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? Well currently, SCSI, SATA, IDE, most well behaved raid controllers, USB storage, and many others all show up simple as /dev/sd*. You better have a really good reason to not do so if you make a new controller. Certainly the IBM serveraid cards I have worked with just present sd* devices (as well as some sg* devices for the controller and hotswap backplane and such). I think the CCISS is a sample of a horrible design as far as the device names in linux are concerned. By creating a new type of block device you force everyone else to do work to support it (or choose to ignore your device because no one cares). By emulating a plain old scsi device interface, everything else just works, and all the work is done by you in your device driver to pretend to my just a scsi disk. If you want your device taken seriously, I don't think you have a choice. Sysadmin's hate things that are different for no good reason. -- Len Sorensen