Subject: Re: Bug in ofdev.c of the ofwboot package?
To: Bill Studenmund <wrstuden@netbsd.org>
From: =?ISO-8859-15?Q?Christian_M=FCller?= <cmue81@gmx.de>
List: port-macppc
Date: 11/02/2005 21:22:40
Bill Studenmund schrieb:

>On Tue, Nov 01, 2005 at 03:45:58AM +0100, Christian M?ller wrote:
>  
>
>>Please forgive me if I'm wrong (and please tell me in that case why it 
>>does work the way it works).
>>
>>Full listing: 
>>http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/macppc/stand/ofwboot/ofdev.c?rev=1.15&content-type=text/x-cvsweb-markup
>>
>>static char *
>>filename(char *str, char *ppart)
>>{
>>[...]
>>	for (cp = str; *cp; lp = cp) {
>>		/* For each component of the path name... */
>>		while (*++cp && *cp != '/')
>>			;
>>		savec = *cp;
>>		*cp = 0;
>>		/* ...look whether there is a device with this name */
>>
>>[NEXT LINE: SHOULD IT NOT BE cp INSTEAD OF str?  Why else would you save cp 
>>in savec?]
>>    
>>
>
>No. cp is a pointer to a character. We save the character that cp points 
>to.
>
>What we're doing is taking a path and figuring out what bits of it are a 
>device and what bits are arguements. We do this by selectively turning '/' 
>characters into NULs and seeing if OF agrees that's a device.
>
>So given the boot device /pci/pci-bridge@D/ADPT,2930@3/@5:9,\ofwboot.xcf 
>we try:
>
>/pci
>/pci/pci-bridge@D
>/pci/pci-bridge@D/ADPT,2930@3
>/pci/pci-bridge@D/ADPT,2930@3/@5:9,\ofwboot.xcf
>
>The last one isn't a device, so we hit the dhandle == -1 path.
>
>  
>
>>		dhandle = OF_finddevice(str);
>>		*cp = savec;
>>[...]
>>	}
>>	return 0;
>>}
>>    
>>
>
>Take care,
>
>Bill
>  
>
Hello,


thanks for your answer - filed a bug in the meantime, but found the 
error in my thinking quickly afterwards, so requested to close it again 
which is done.  I'm trying to find out why booting the NetBSD CD on 
oldworld macs (OF 2.4) doesn't work by reading the relevant code - I've 
moved ahead a little, can you please take a look at my "Boot NetBSD CD 
on Beige G3 OF 2.4 should be possible (after fix)" article of today on 
this list?
http://mail-index.netbsd.org/port-macppc/2005/11/02/0003.html

IMHO I nailed the problem down to libsa/open.c//open code - where it 
tries out, in case of a BLOCK device, 4 different filesystems - that are 
charged to struct fs_ops file_system[4] in ofwboot/ofdev.c//devopen.  
The trouble is that ustarfs code is used before cd9660 code and instead 
of returning an error gets stuck in a loop.

If there is no easy way in fixing this behavior in the ustarfs code,

###  might it be possible to detect if it's iso9660 somehow in 
ofwboot/ofdev.c//devopen and charge file_system just with iso9660 in 
that case? ###


Help & thoughts appreciated
Christian

ps: how can i compile macppc code with i386 version of netbsd 
(hints/pointers/resources)?