On Thu, 27 Jul 2023, Michael Schmitz wrote:
And yes, I'm painfully aware the m68k low level IO code is becoming a
bit of a maintainance legacy, in no small part due to my hacks around
Atari EtherNEC.
I guess you and I both can share the blame for 44b1fbc0f5f30e66...
Anyway, you make a good point about on-going maintenance. Do you think
that by supporting standard ISA drivers we might actually reduce the
ideosyncracies in m68k IO code?
You and DaveM ought to have a chat about that - abstracting the legacy
drivers from the ISA constraints was his preferred option when I last
attempted to get the Gayle network driver patches merged. When I say
'preferred', I'm probably understating a little.
A discussion with maintainers probably won't get far without working code
to look at. Perhaps William will send an RFC patch to illustrate his
approach.
I had toyed with that using the EtherNEC driver as test case but never
got very far (this would have been splitting the driver into a core
lib8390 module and a platform-specific module that allows to hook a
variety of IO accessors as hooks, not static defines, and I wasn't too
certain about performance impacts of such a change, the performance of
the EtherNEC being so shitty it won't make any impact there),
The only other option (that I can see) would be creating a bus driver
for the ISA bus, with platforms allowed to register their particular IO
accessors for IO and memory accesses - again, performance impacts to
consider and getting test coverage on legacy ISA hardware a nightmare.
This would allow to use legacy driver code more or less unchanged.
Haven't given that much thought at all (the idea pretty much originated
from this present mess, but that's all).
There may be other approaches that can be considered, if none of this is
what you had in mind.
What I had in mind is probably unacceptable because drivers end up having
to do byteswapping as happens in pata_falcon (or falconide and q40ide).
Perhaps your bus driver idea would probabably find more acceptance. OTOH
if the aim of the exercise is to use standard drivers (like pata_legacy)
there would probably be driver changes either way.
It might be helpful to look for some precedent for this kind of thing
among the other big-endian platforms with ISA. MIPS Magnum is dual-endian
but Linux only runs in little-endian mode and the problem doesn't arise.
But there must be other examples. Maybe CHRP?
