From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LimYb-0007Bt-OC for mharc-grub-devel@gnu.org; Sun, 15 Mar 2009 05:22:57 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LimYZ-0007Bd-9w for grub-devel@gnu.org; Sun, 15 Mar 2009 05:22:55 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LimYU-0007BB-DR for grub-devel@gnu.org; Sun, 15 Mar 2009 05:22:54 -0400 Received: from [199.232.76.173] (port=33805 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LimYU-0007B8-53 for grub-devel@gnu.org; Sun, 15 Mar 2009 05:22:50 -0400 Received: from mta-out.inet.fi ([195.156.147.13]:46867 helo=kirsi1.inet.fi) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LimYT-000502-IP for grub-devel@gnu.org; Sun, 15 Mar 2009 05:22:49 -0400 Received: from [192.168.1.102] (84.248.105.254) by kirsi1.inet.fi (8.5.014) id 49B910AD00175E67 for grub-devel@gnu.org; Sun, 15 Mar 2009 11:22:44 +0200 Message-ID: <49BCC8CD.7030903@nic.fi> Date: Sun, 15 Mar 2009 11:22:21 +0200 From: =?ISO-8859-1?Q?Vesa_J=E4=E4skel=E4inen?= User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: The development of GRUB 2 References: <20090314.151417.194555320.davem@davemloft.net> In-Reply-To: <20090314.151417.194555320.davem@davemloft.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) 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 09:22:55 -0000 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. Actually related question here is that how do you specify similar device paths in x86? Now that there is pci support and some kinda usb support it could be good idea to specify exact device somehow in some use cases. > 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. > > Then we just have a machine specific path seperator, defined in > some header file and the kernel/disk.c code > and elsewhere use the macro instead of "," > > Any objections? So you propose following: (/pci@1e,600000/pci@0/pci@9/pci@0/scsi@1/disk@0:1) (/pci@1e,600000/pci@0/pci@9/pci@0/scsi@1/disk@0:a,1) ( $FW_DISK_NAME + ':' + $GRUB_PARTITION_SCHEME ) ? If we go that path we should use same delimeter for other archs to make it a bit easier for users to understand how it works. Lets try couple of examples: 1. (hd0) => a-d) device alias 'hd0', no partition 2. (hd0,1) => a-d) device alias 'hd0', partition '1' 3. (hd0:1) => a) device alias 'hd0:1', no partition b) device alias 'hd0:1', no partition c) device alias 'hd0', partition '1' d) device alias 'hd0:1', no partition 4. (/pci@1e,600000/pci@0/pci@9/pci@0/scsi@1/disk@0) a) => device alias '/pci@1e', partition '600000/pci@0/pci@9/pci@0/scsi@1/disk@0' b) => device alias '/pci@1e', partition '600000' c) => device alias '/pci@1e', partition '600000/pci@0/pci@9/pci@0/scsi@1/disk@0' d) => device alias '/pci@1e,600000/pci@0/pci@9/pci@0/scsi@1/disk@0', no partition 5. (/pci@1e,600000/pci@0/pci@9/pci@0/scsi@1/disk@0:1) a) => device alias '/pci@1e', partition '600000/pci@0/pci@9/pci@0/scsi@1/disk@0:1' b) => device alias '/pci@1e', partition '600000' c) => device alias '/pci@1e,600000/pci@0/pci@9/pci@0/scsi@1/disk@0', parition '1'. d) => device alias '/pci@1e,600000/pci@0/pci@9/pci@0/scsi@1/disk@0', parition '1'. 6. (/pci@1e,600000/pci@0/pci@9/pci@0/scsi@1/disk@0:) a) => device alias '/pci@1e', partition '600000/pci@0/pci@9/pci@0/scsi@1/disk@0:1' b) => device alias '/pci@1e', partition '600000' c) => device alias '/pci@1e,600000/pci@0/pci@9/pci@0/scsi@1/disk@0', no partition parition. d) => device alias '/pci@1e,600000/pci@0/pci@9/pci@0/scsi@1/disk@0', no partition parition. Now the algorithms for a-d: a) look for first comma, split there b) look for first comma, split there, filter out results c) look for ':', if found split there, otherwise go to a) d) look for '/' at start, if found look for ':' to differentiate partitions, if not found go to a) Now lets play with phcoder's idea: ("/pci@1e,600000/pci@0/pci@9/pci@0/scsi@1/disk@0") ("/pci@1e,600000/pci@0/pci@9/pci@0/scsi@1/disk@0",1) ("/pci@1e,600000/pci@0/pci@9/pci@0/scsi@1/disk@0",a,1) This could be easier to get right. Thou still needs some learning curve for user. This extension could be used to look out for all firmware names (assuming they map to ascii/utf-8).