--69pVuxX8awAiJ7fD
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 02, 2005 at 09:22:40PM +0100, Christian M?ller wrote:
>=20
> thanks for your answer - filed a bug in the meantime, but found the=20
> error in my thinking quickly afterwards, so requested to close it again=
=20
> which is done.  I'm trying to find out why booting the NetBSD CD on=20
> oldworld macs (OF 2.4) doesn't work by reading the relevant code - I've=
=20
> moved ahead a little, can you please take a look at my "Boot NetBSD CD=20
> on Beige G3 OF 2.4 should be possible (after fix)" article of today on=20
> this list?
> http://mail-index.netbsd.org/port-macppc/2005/11/02/0003.html
>=20
> IMHO I nailed the problem down to libsa/open.c//open code - where it=20
> tries out, in case of a BLOCK device, 4 different filesystems - that are=
=20
> charged to struct fs_ops file_system[4] in ofwboot/ofdev.c//devopen. =20
> The trouble is that ustarfs code is used before cd9660 code and instead=
=20
> of returning an error gets stuck in a loop.
>=20
> If there is no easy way in fixing this behavior in the ustarfs code,
>=20
> ###  might it be possible to detect if it's iso9660 somehow in=20
> ofwboot/ofdev.c//devopen and charge file_system just with iso9660 in=20
> that case? ###

No. The correct way this is supposed to work is that ustarfs will figure=20
out it won't work and will then exit.

I agree with the tail end of your analysis. The problem is that=20
DEV_STRATEGY and real_fs_cylinder_read() aren't working together.

Take care,

Bill

--69pVuxX8awAiJ7fD
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFDaTZLWz+3JHUci9cRAjU/AJ9cDNkpGEeU0y4dtAknRo95PjOvQgCgmOdL
K467mV7747aSCzC9U57Incg=
=t5WM
-----END PGP SIGNATURE-----

--69pVuxX8awAiJ7fD--