In article <20040826153026.94A2E4167B@mail01.powweb.com>
hockey@dialectronics.com wrote:

> I have not been able to try different arrangements yet.
> I had a hardware failure on the computer I've been using,
> and I could not get sysinst to properly accept an msdos
> partition (this is my error, and not sysinst).
> In the case of OpenBSD, the above is when the disk was
> formatted with fdisk/mbr and the msdos parition is the first one.

What do you mean "not get sysinst to properly accept an msdos partition?"
Do you mean msdos partition is not appeared in output of disklabel(8)?
If so it's not sysinst problem but kernel problem.
(though I don't think sysinst for macppc can handle fdisk parititions..)

> As I indicated in an earlier email, I am concerned that
> this approach could leave me unable to boot if the experimental
> bootloader fails. Wouldn't I have to have a working system
> to run installboot?

Yes. You have to have altanative boot device on testing it.
I used bootable CD-ROM to recover from it.

> >>
> You only can specify filename on OF prompt if the file is
> placed in filesystem which can be recognized by OF,
> so it works on msdosfs.
> >>
>
> I could be wrong, but isn't this true only if the file system
> strategy (libsa/loadfile.c->cread.c->open.c) being used is hfs?
> As I look at 
> 
> http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/sys/arch/macppc/stand/ofwboot/hfs.c?rev=1.2

In this case, bootpath is used only to get device path
(not filename or path in filesystem) used for loaded ofwboot itself.
This code assumes that the device path used to load ofwboot
can be used to load other files with OF routines, I think.

> the open method is just a wrapper for Open Firmware and
> uses bootpath to reference the kernel location because
> the file path has already been stripped. Since bootargs
> contains what is entered on the OF prompt, one can specify
> a full path that is different than where the bootloader is.

For this purpose, you could use the second arg and
I don't see any reason to fix hfs.c because it is not
used to load kernels from ffs (or ustarfs and cd9660).

> In theory, if that path is not readable by OF, shouldn't
> ENOENT be returned and another file system strategy be tried?

Well, I think this strategy for HFS with OpenFirmware is
a just workaround to access files on HFS which we don't have
actual support. If we have real filesystem support for HFS,
we don't have to use OF to access it and the restriction
that kernel should be placed on the same dir with ofwboot.

If you need msdosfs support in ofwboot (or its alternative),
you can simply add struct fs_ops for msdos which is implemented
in sys/lib/libsa/dosfs.c to macppc/stand/ofwboot/ofdev.c.
You can specify that msdosfs is tried before (current) hfs.c
in ofdev.c:devopen().

> That is part of what I referenced when I said that some code
> in libsa would have to be changed to not strip the path to the kernel.

What is "some code in libsa"? macppc/stand/ofwboot/hfs.c?
It seems passed kernel path in bootargs is preserved in boot.c:main().

> This approach could lead to something as simple as having
> the bootloader on a msdos formatted floppy and an FFS formatted
> hard drive for older OF Macs.

You mean that you want to make ofwboot.xcf on msdosfs load
a kernel on ffs (which is in the secondary partition of fdisk)?
I think it should work with current code.
(though I have not checked if current MBR handling in ofdev.c
 works properly)
---
Izumi Tsutsui
tsutsui@ceres.dti.ne.jp