On August 15, 2023 10:42:02 AM UTC, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
Hi William,
On Tue, Aug 15, 2023 at 11:49 AM William R Sowerbutts
<will@xxxxxxxxxxxxxx> 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
