Re: Big Endian fix patch

[Doug Nazar <nazard.michi@gmail.com>]

  On 2010-07-28 11:00 AM, Lennart Sorensen wrote:
>
> OK, no idea how I got by without that.  It is currently working for me.
> Weird.
>
> I only use raid1 of course, so that is all I tested with.
>
It only mattered for multipath. Which is a kind of raid1 setup. Grub 
doesn't handle it too well since the underlying device is the same and 
has the same disk number. Before we'd overwrite the old path with the 
last path found and incorrectly increase nr_devs. With my patch we just 
ignore additional drives. So we'll die if we lose the path while booting 
but otherwise it'll find at least one of the paths.
>> - Fix the ofdisk_hash system. We weren't making a copy of the devpath so
>> never found the cached item again.
> Could this have anything to do with why I can't see disks without
> devaliases assigned?
>
No. This would only affect the disk cache subsystem (since the hash 
struct pointer was used as the disk id) and we'd be comparing the 
devpath with random memory.
>
> QEMU/openbios has many bugs unfortunately.  If I could make any sense
> of the code I would try to fix some of them, but I simply can't follow
> that code.
>
I've got a basic idea how it all hangs together internally and I started 
to fix a few things in OpenBios but discovered the current source 
doesn't work with QEMU 0.12.5. "boot" stopped working and if I used 
"load" it started to work then complained that it was trying to 
overwrite OpenBios. Since I have no idea how the memory is supposed to 
be laid out I kinda backed away. Besides, Forth is not my first choice 
of languages to figure out.

> I will give this patch a try on top of mine then and see how it behaves.
>
Thanks for testing,
Doug