All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rene Herman <rene.herman@gmail.com>
To: Greg Freemyer <greg.freemyer@gmail.com>
Cc: "Jan Engelhardt" <jengelh@computergmbh.de>,
	"José Luis Patiño Andrés" <jopan@alumni.uv.es>,
	"Lennart Sorensen" <lsorense@csclub.uwaterloo.ca>,
	"Alan Cox" <alan@lxorguk.ukuu.org.uk>,
	linux-kernel@vger.kernel.org, "Jeff Garzik" <jgarzik@pobox.com>,
	linux-ide@vger.kernel.org
Subject: Re: Problems with IDE on linux 2.6.22.X
Date: Thu, 30 Aug 2007 23:34:34 +0200	[thread overview]
Message-ID: <46D737EA.6010707@gmail.com> (raw)
In-Reply-To: <87f94c370708301416j2a7c000bscbaef593af004010@mail.gmail.com>

On 08/30/2007 11:16 PM, Greg Freemyer wrote:

> On 8/30/07, Rene Herman <rene.herman@gmail.com> wrote:

>> Well -- the world where ATA, SCSI, USB, Firewire and what have you are
>> low-level drivers to a unifying storage layer is under non too obscure
>> definitions sort of not non-wonderful...
>>
> 
> USB / Firewire / FC / iSCSI are all SCSI transports and fit within the
> SCSI subsystem by design.
> 
> ie. Just like ethernet, DSL, T-1, etc can all carry IP traffic with no
> conceptual conflict, many media by design carry SCSI traffic.
> 
> The PATA and SATA physical layer typically carry ATA commands and
> having them tied into the SCSI stack is an aberration that I hope will
> be eliminated some day.
> 
> ATAPI is an exception.  Not sure where that would end up in a perfect world.

As said, if you make a bit of an effort to view the former SCSI stack as a 
unified storage midlayer the abberation becomes less abberational (if that's 
a word).

Real SCSI, the other SCSI transports and ATAPI would just use more of the 
common mid-layer than P/SATA would. I'd expect the way forward would be to 
just refactor things until someone notices that drivers/scsi is the wrong 
place for sd.c and sr.c and moves them to drivers/block or whereever.

Practically, the PATA driver gives me (almost) the same throughput as the 
old IDE driver does, and given that I need the former SCSI stack _anyway_ 
for my external USB harddrive, I don't see a pressing need to carry along 
yet another storage stack for my harddrive.

Rene.



      parent reply	other threads:[~2007-08-30 21:40 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-21 19:49 Problems with IDE on linux 2.6.22.X José Luis Patiño Andrés
2007-08-21 22:08 ` Rene Herman
2007-08-21 23:00   ` Alan Cox
2007-08-21 23:07     ` Rene Herman
2007-08-22  1:39   ` José Luis Patiño Andrés
2007-08-22  2:35     ` Rene Herman
2007-08-22  6:15       ` Kiko Piris
2007-08-22 11:23       ` Alan Cox
2007-08-22 15:48         ` Rene Herman
2007-08-22 16:23           ` Lennart Sorensen
2007-08-22 16:54             ` Rene Herman
2007-08-28  0:44               ` José Luis Patiño Andrés
2007-08-28 17:05                 ` Rene Herman
2007-08-30 19:31                   ` Jan Engelhardt
2007-08-30 19:46                     ` Lennart Sorensen
2007-08-30 20:05                     ` Rene Herman
2007-08-30 21:16                       ` Greg Freemyer
2007-08-30 21:32                         ` Lennart Sorensen
2007-08-30 21:34                         ` Rene Herman [this message]

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=46D737EA.6010707@gmail.com \
    --to=rene.herman@gmail.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=greg.freemyer@gmail.com \
    --cc=jengelh@computergmbh.de \
    --cc=jgarzik@pobox.com \
    --cc=jopan@alumni.uv.es \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lsorense@csclub.uwaterloo.ca \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.