From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LisX1-0001gK-Pz for mharc-grub-devel@gnu.org; Sun, 15 Mar 2009 11:45:43 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LisWz-0001fj-JI for grub-devel@gnu.org; Sun, 15 Mar 2009 11:45:41 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LisWu-0001eg-5l for grub-devel@gnu.org; Sun, 15 Mar 2009 11:45:40 -0400 Received: from [199.232.76.173] (port=50455 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LisWu-0001eX-2M for grub-devel@gnu.org; Sun, 15 Mar 2009 11:45:36 -0400 Received: from aybabtu.com ([69.60.117.155]:37939) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LisWt-00025U-KM for grub-devel@gnu.org; Sun, 15 Mar 2009 11:45:35 -0400 Received: from [192.168.10.10] (helo=thorin) by aybabtu.com with esmtp (Exim 4.69) (envelope-from ) id 1LisOF-00041o-0I for grub-devel@gnu.org; Sun, 15 Mar 2009 16:36:39 +0100 Received: from rmh by thorin with local (Exim 4.69) (envelope-from ) id 1LisWp-0006Qb-N5 for grub-devel@gnu.org; Sun, 15 Mar 2009 16:45:31 +0100 Date: Sun, 15 Mar 2009 16:45:31 +0100 From: Robert Millan To: The development of GRUB 2 Message-ID: <20090315154531.GD24554@thorin> References: <20090314.151417.194555320.davem@davemloft.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090314.151417.194555320.davem@davemloft.net> Organization: free as in freedom X-Message-Flag: Worried about Outlook viruses? Switch to Thunderbird! www.mozilla.com/thunderbird X-Debbugs-No-Ack: true User-Agent: Mutt/1.5.18 (2008-05-17) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Subject: Re: GRUB device names wrt. ieee1275 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2009 15:45:41 -0000 On Sat, Mar 14, 2009 at 03:14:17PM -0700, David Miller wrote: > > One issue I need to resolve before I can send finalized > patches out for sparc is about device naming. > > Currently the PowerPC ieee1275 support allows using both device > aliases and full openfirmware device path names with the usual GRUB > partition specification concatenated at the end. For the most part > this is fine. > > This works for a large group of cases, but in general it will not > work. > > The problem is two fold: > > 1) "," characters can appear anywhere in an openfirmware path > name. For example my workstations disk is: > > /pci@1e,600000/pci@0/pci@9/pci@0/scsi@1/disk@0 > > There are no quick workarounds for this. For example, even if we > can change the partition fetching code in GRUB to use "strrchr()" > instead of "strchr()" in kern/disk.c:grub_disk_open() it will > still think the above path has partition ",600000" or something > silly like that. > > 2) Disks can have multiple comma seperated components especially > on SCSI in OF path names. For example a disk on target 2, > lun 3, would have final path component "disk@2,3" > > And currently that ",3" would look like a parition specification > to GRUB. > > Therefore, I would suggest that we adopt the openfirmware partition > specification of ":" on GRUB for ieee1275 platforms. It's not an absolute must that device names are unique. You can still identify partitions by their filesystem UUID or label, and in fact this is what our default scripts (grub-mkconfig) do anyway. Making GRUB specify partitions differently depending on the platform we're on seems troublesome, specially if we end up with such long an ugly names. If we really need this, can't we just assign names dynamically like hd0, hd1, etc, and keep a memory structure that matches them with the actual OFW device? -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all."