From: William R Sowerbutts <will@sowerbutts.com>
To: Michael Schmitz <schmitzmic@gmail.com>
Cc: Richard Z <rz@linux-m68k.org>, Finn Thain <fthain@linux-m68k.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
linux-m68k <linux-m68k@lists.linux-m68k.org>
Subject: Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time
Date: Tue, 15 Aug 2023 10:49:13 +0100 [thread overview]
Message-ID: <ZNtKGaIgs4Dy2/6b@sowerbutts.com> (raw)
In-Reply-To: <e36baf9d-b027-380c-de91-c9ff52857168@gmail.com>
>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.
I'm not clear if pata_falcon on Atari records data on disk in normal or
swapped byte order. Can I take a drive from my Atari Falcon Linux machine
and connect it to a PC without needing to byte swap it?
I want to float some potential solutions for discussion;
* Add a kernel configuration option to choose between legacy and compatible
byte ordering on Q40 at compile time (affecting all disks)
* Add a pata_falcon driver option to choose which of the connected disks
should use legacy or compatible byte ordering at run time
* Extend pata_falcon to examine the connected disk's contents, looking for
some marker that reliably indicates a legacy byte order disk is connected.
Default to compatible byte ordering if this mark is not found. Maybe it
would be cleaner for some optional module atop the driver to do this.
* Assuming pata_legacy can be made to work well: Have pata_falcon retain
legacy byte ordering, while pata_legacy drives the same hardware in
compatible byte ordering mode. User chooses the driver to choose byte
ordering.
* Switch pata_falcon to compatible byte order, document for any legacy disk
users how they can either do a one-time migration of their data to
compatible format, or setup the block layer to do byte swapping
on-the-fly.
Thanks
Will
_________________________________________________________________________
William R Sowerbutts will@sowerbutts.com
"Carpe post meridiem" http://sowerbutts.com
main(){char*s=">#=0> ^#X@#@^7=",c=0,m;for(;c<15;c++)for
(m=-1;m<7;putchar(m++/6&c%3/2?10:s[c]-31&1<<m?42:32));}
next prev parent reply other threads:[~2023-08-15 9:50 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <ZLvZmVfzJNHlPTlJ@sowerbutts.com>
2023-07-23 8:35 ` Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time Geert Uytterhoeven
2023-07-23 9:59 ` Finn Thain
2023-07-23 15:28 ` William R Sowerbutts
2023-07-24 1:43 ` Finn Thain
2023-07-24 11:09 ` William R Sowerbutts
2023-07-26 7:22 ` Finn Thain
2023-07-23 20:26 ` Michael Schmitz
2023-07-24 11:42 ` William R Sowerbutts
2023-07-24 20:26 ` Michael Schmitz
2023-07-26 9:22 ` Finn Thain
2023-07-26 20:13 ` Michael Schmitz
2023-07-27 1:16 ` Finn Thain
2023-07-27 3:17 ` Michael Schmitz
2023-07-27 23:47 ` Finn Thain
2023-07-28 7:21 ` Geert Uytterhoeven
2023-07-28 7:52 ` Michael Schmitz
2023-07-28 8:03 ` Geert Uytterhoeven
2023-07-29 4:56 ` Michael Schmitz
2023-08-13 3:06 ` Michael Schmitz
2023-08-13 7:38 ` Finn Thain
2023-08-13 21:20 ` Michael Schmitz
2023-08-13 22:24 ` William R Sowerbutts
2023-08-13 22:54 ` Michael Schmitz
2023-08-13 23:37 ` Finn Thain
2023-08-14 0:33 ` Michael Schmitz
2023-08-14 1:15 ` Finn Thain
2023-08-14 2:48 ` Michael Schmitz
2023-08-14 11:18 ` William R Sowerbutts
2023-08-14 20:15 ` Michael Schmitz
2023-08-14 20:24 ` Richard Z
2023-08-14 23:31 ` Finn Thain
2023-08-15 3:05 ` Richard Z
2023-08-15 3:30 ` Michael Schmitz
2023-08-15 9:49 ` William R Sowerbutts [this message]
2023-08-15 10:42 ` Geert Uytterhoeven
2023-08-15 20:43 ` Richard Z
2023-08-15 20:13 ` Michael Schmitz
2023-08-15 22:10 ` William R Sowerbutts
2023-08-15 22:38 ` Michael Schmitz
2023-08-14 20:19 ` Richard Z
2023-08-14 21:22 ` Michael Schmitz
2023-08-15 11:04 ` William R Sowerbutts
2023-08-16 17:56 ` William R Sowerbutts
2023-07-27 7:18 ` Geert Uytterhoeven
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZNtKGaIgs4Dy2/6b@sowerbutts.com \
--to=will@sowerbutts.com \
--cc=fthain@linux-m68k.org \
--cc=geert@linux-m68k.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=rz@linux-m68k.org \
--cc=schmitzmic@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox