On Sun, Feb 29, 2004 at 09:36:33PM +0100, Bartlomiej Zolnierkiewicz wrote:
> On Sunday 29 of February 2004 20:23, Richard Zidlicky wrote:
> > On Sun, Feb 29, 2004 at 09:52:08AM +0100, Geert Uytterhoeven wrote:
> > > On Sun, 29 Feb 2004, Bartlomiej Zolnierkiewicz wrote:
> > > > On Sunday 29 of February 2004 01:58, Jeff Garzik wrote:
> > > > > > I like Alan's idea to use loopback instead of "bswap".
> > > > >
> > > > > Neat but no more zerocopy that way. I much prefer a
> > > > > swap-as-you-go...
> > > >
> > > > Okay, better solution:
> > > >
> > > > - on Atari/Q40:
> > > > if drive->bswap use insw/outsw instead of swapping variants
> > >
> > > Yep, that sounds the most logical. Richard?
> >
> > looks good.
> >
> > However it appears to fix only part of the problem - we need some
> > logic to ensure only disk data is swapped.
> > Bswapping WIN_DOWNLOAD_MICROCODE data would not be very
> > clever I guess.
>
> Actually drive->bswap should die as I overlooked the fact that we are
> _not_ swapping disk data (byteswapped data is used for FS) on Atari/Q40.
correct, on those machines the IDE bus is wired "reversed" and we take
the data without any correction, except for IDENTIFY and atapi requests.
That means that quite a few ioctls (SMART etc) are most likely broken
right now.
> Therefore the real solution is to use device-mapper instead of drive->bswap
> and on Atari/Q40 use standard insw/outs only if blk_fs_request(drive->rq),
> for everything else insw_swapw/outsw_swapw should be used.
>
> Does it make any sense? :)
that would be the perfect solution. Note that atapi transfers are
already correct the way they are - nothing to fix here.
Richard