linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Richard Zidlicky <rz@linux-m68k.org>
Cc: John Bradford <john@grabjohn.com>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Linus Torvalds <torvalds@transmeta.com>,
	Paul Mackerras <paulus@samba.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] M68k IDE updates
Date: Thu, 24 Apr 2003 13:26:12 +0200 (MEST)	[thread overview]
Message-ID: <Pine.GSO.4.21.0304241309200.19942-100000@vervain.sonytel.be> (raw)
In-Reply-To: <20030424094732.GA925@linux-m68k.org>

On Thu, 24 Apr 2003, Richard Zidlicky wrote:
> On Wed, Apr 23, 2003 at 09:19:07PM +0100, John Bradford wrote:
> > Moving byte swapping out of the IDE layer also means that dumping the
> > whole disk to a file will then give you non-byte swapped data, which
> > could then be written back to a disk on another machine without a
> > byte-swapped IDE interface.
> > 
> > It will also allow you to exchange tar archives on raw hard disk
> > devices, and have them readable on non-byte swapped IDE interfaces
> > :-).
> 
> Linux is much better and will do all of that work perfectly since 
> ages, just use hdX=swapdata on one of the machines. Trivially it 
> is also possible to mount the partitions on either architecture.

Note that the swapping works for PIO only, IIRC. For DMA mode, you're limited
to the loop solution.

> The issue is the distinction between drive control data (like SMART
> and ident) and on disk data - currently the ide layer makes no clear
> distinction between those varieties and thus in some cases the 
> byteswapping must be done (or undone) in userspace.
> 
> There are some reasons why I am hesitant to move it out of IDE:
> 
> - IDE knows best what is control or on disk data and
>   having separate ide-iops for them would be trivial
> - partitioning loop devices smells like plenty of fun
> - performance, for compatibility with current kernels
>   we would byteswap in IDE and undo it in the loop layer
> - donŽt like to rely on utterly complicated boot ramdisks

After some more thinking, Alan's suggestion (always doing the swapping) isn't
that bad. Except for the loop layer on old slow machines, which I'd like to
avoid.

If we always swap, we only have to un-swap when reading/writing platter data
from native disks. No more swapping has to be done in ide_fix_driveid(), apart
from the obvious conversion from little to big endian of the driveid structure
itself, which we cannot avoid.

Since both Atari and Q40/Q60 use PIO only, this affects ata_{in,out}put_data()
only. It's quite easy to add a swap flag to ide_drive_t (configurable through
hdX=swapdata), that is checked in ata_{in,out}put_data().  To improve
performance, we wouldn't swap twice, but just call the new routines
hwif->{IN,OUT}S[WL]_NOSWAP.

Note that this would be the inverse logic of the current scheme, which swaps
conditionally in atapi_{in,out}put_bytes().

All of this can be protected by #ifdef CONFIG_IDE_BYTESWAPPED_HWIF. Influence
on generic code is limited to ata_{in,out}put_data() and the new routines
hwif->{IN,OUT}S[WL]_NOSWAP.

Is this OK?

For reference, I think this is the list of machines with a byteswapped IDE
interface:
  - Atari Falcon
  - Q40/Q60
  - Tivo

Any others?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


  reply	other threads:[~2003-04-24 11:14 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.GSO.4.21.0304221802570.16017-100000@vervain.sonytel.be>
2003-04-23 11:27 ` [PATCH] M68k IDE updates Richard Zidlicky
2003-04-23 11:04   ` Alan Cox
2003-04-23 20:19     ` John Bradford
2003-04-24  9:47       ` Richard Zidlicky
2003-04-24 11:26         ` Geert Uytterhoeven [this message]
2003-04-24 13:14           ` Richard Zidlicky
2003-04-24 14:11             ` Geert Uytterhoeven
2003-04-22 13:55 Mudama, Eric
  -- strict thread matches above, loose matches on Subject: below --
2003-04-13 13:06 Geert Uytterhoeven
2003-04-13 14:10 ` Alan Cox
2003-04-13 23:43   ` Paul Mackerras
2003-04-14  8:39     ` Geert Uytterhoeven
2003-04-14  9:19       ` Benjamin Herrenschmidt
2003-04-14  9:24         ` Geert Uytterhoeven
2003-04-14 12:19           ` Alan Cox
2003-04-14 12:21       ` Alan Cox
2003-04-14 13:44         ` Geert Uytterhoeven
2003-04-14 16:03           ` Alan Cox
2003-04-15  4:45       ` Jamie Lokier
2003-04-15  8:11         ` Geert Uytterhoeven
2003-04-15  9:23           ` Jörn Engel
2003-04-15  9:52             ` Geert Uytterhoeven
2003-04-14 12:48     ` Alan Cox
2003-04-14 12:48     ` Alan Cox
2003-04-14 17:44     ` Linus Torvalds
2003-04-14 19:54       ` Geert Uytterhoeven
2003-04-14 22:31         ` Paul Mackerras
2003-04-15  8:14           ` Geert Uytterhoeven
2003-04-21 16:55       ` Geert Uytterhoeven
2003-04-22 14:49         ` Alan Cox

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=Pine.GSO.4.21.0304241309200.19942-100000@vervain.sonytel.be \
    --to=geert@linux-m68k.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=john@grabjohn.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulus@samba.org \
    --cc=rz@linux-m68k.org \
    --cc=torvalds@transmeta.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;
as well as URLs for NNTP newsgroup(s).