Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

Richard Z
2023-08-15T20:44:44Z

On August 15, 2023 10:42:02 AM UTC, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>Hi William,
>
>On Tue, Aug 15, 2023 at 11:49 AM William R Sowerbutts
><will@sowerbutts.com> wrote:
>> >We need to fix pata_falcon for Q40, and with data on William's disk in
>> >little endian order, but data on other users' disks in big endian order, we
>> >need to come up with a way to support both for now.
>>
>> I don't mind if you break my disk -- I can always byte-swap it if required,
>> or patch my kernel to use my preferred byte ordering.
>>
>> Valid points have been made about needing to keep existing disks working.
>>
>> For the kernel driver to switch byte order after some specific version seems
>> unexpected.
>>
>> On the other hand, having disks compatible with other systems is important,
>> and as a naive new user the byte-swapped disk format was quite unexpected to
>> me.
>>
>> It seems there are reasonable arguments for both sides.
>>
>> I had a cursory look through other drivers and could not find any that make
>> byte ordering a user-selectable option. Is there any precedent for this? It
>> would be interesting to learn how they exposed the option to the user.
>
>IIRC, the consensus was to not add any more byteswapping _options_
>to IDE drivers. Just make sure the driver returns all data in host order.
>The IDE core will take care of converting the drive identification from
>little to native endian when needed (see swap_buf_le16()).
>

The more important consensus says don't break things so whoever removed the hdX=bswap option should have implemented it in some other way. However there was very little to zero practical use for this at the time that happened so I can understand why it didn't happen.

>Now, if your native (non-Linux) OS byte-swapped only the drive
>identification block, but not the user data, you have an incompatibility.
>Solving that is meant to be handled through a byte-swapping md layer
>(although I can't seem to find that anymore?).
>

There was some talk about it but iirc it was never implemented.

Richard