mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: ksummit-2008-discuss@lists.linux-foundation.org,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-ide <linux-ide@vger.kernel.org>
Subject: Re: Kernel Summit request for Discussion of future of ATA (libata) and IDE
Date: Sun, 03 Aug 2008 14:21:24 -0500	[thread overview]
Message-ID: <1217791284.4179.34.camel@localhost.localdomain> (raw)
In-Reply-To: <20080803194501.24fa3e51@lxorguk.ukuu.org.uk>

On Sun, 2008-08-03 at 19:45 +0100, Alan Cox wrote:
> > > There is a trend in new hardware to interfaces that simply won't fit old
> > > IDE so that process of libata only drivers is likely to continue.
> > 
> > Yes, that's SATA ... but legacy remains for a long time.
> 
> It isn't that simple. The newer PATA controllers are diverging from the
> old style interfaces as well.
> 
> > Yes, I understand this ... if that means drivers/ata can't possibly be
> > used by embedded until its dependence on SCSI is broken, then so be
> > it ... but I think we should at least investigate what the issues and
> > potential solutions are.
> 
> The simpler embedded wants a pure CF driver - no scsi, no libata, no
> drivers/ide overhead, just about 4K of CF only pio driver.

I'd be a bit surprised if that's anything other than a niche.  PIO is
deadly slow and wasteful of precious CPU cycles ... and embedded devices
seem to be interested in performance as well (which the DMA modes
bring).

> > Well, I did notice from the lists that both drivers/ide and drivers/ata
> > would be represented.  I've also observed that there's been a singular
> > lack of discussion of this on the lists; plus it's the type of emotive
> > issue that in-person discussions help to extract the heat from.
> 
> We've certainly discussed it in the past and I'm not sure its gotten that
> personal - many people contribute to both trees for example, or are
> directly cc'ing stuff between trees to ensure they stay in sync and any
> useful info gets in both.

My observation was merely that I hadn't seen it discussed.

> Anyway with my libata hat on I would say its far too early to worry about
> this. Right now we have platforms that need old IDE and it is still
> proving very useful to be able to ask people to try both. I don't quite
> know why Bart is putting so much effort into polishing up the old IDE but
> if he's enjoying it I don't really care 8)

Hey, I'd be the last person to discourage anyone from maintaining
obsolete systems ... however, the outside world looking in on this is
interested to know where they should be starting if they have some type
of CF/IDE device to support.  What we really want to avoid is someone
spending months on a device driver only to have us turn around and
deprecate the subsystem.

I don't envisage anything in terms of code changes (or removal) coming
out of this.  What I would like is a nice roadmap of where to start for
people contemplating writing IDE drivers.

James



  reply	other threads:[~2008-08-03 19:21 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-03 15:57 James Bottomley
2008-08-03 16:39 ` Alan Cox
2008-08-03 17:10   ` James Bottomley
2008-08-03 18:45     ` Alan Cox
2008-08-03 19:21       ` James Bottomley [this message]
2008-08-03 19:17         ` Alan Cox
2008-08-03 20:19           ` Bartlomiej Zolnierkiewicz
2008-08-03 22:07             ` Alan Cox
2008-08-03 17:32   ` Willy Tarreau
2008-08-03 17:45     ` Rafael J. Wysocki
2008-08-03 17:57       ` Willy Tarreau
2008-08-03 20:22       ` [Ksummit-2008-discuss] " David Woodhouse
2008-08-04  5:35   ` Benjamin Herrenschmidt
2008-08-04 13:16   ` Kumar Gala
2008-08-04 13:07     ` Alan Cox
2008-08-03 20:09 ` Bartlomiej Zolnierkiewicz
2008-08-03 22:01   ` Alan Cox
2008-08-03 23:10 ` Jeff Garzik
     [not found] <fa.OGeO7gZvBG4obEzRbVltjSebgTQ@ifi.uio.no>
     [not found] ` <fa.KtvYE2B2yrJqUleolhtMPN9ljAQ@ifi.uio.no>
     [not found]   ` <fa.AqEKTvguYFAzDFHy/We/8MpOqmo@ifi.uio.no>
2008-08-04 20:07     ` Robert Hancock
2008-08-04 19:55       ` Alan Cox
2008-08-04 21:17         ` Robert Hancock
2008-08-04 21:06           ` Alan Cox
2008-08-04 21:48             ` Robert Hancock
2008-08-06  0:21             ` Robert Hancock
2008-08-06  0:44               ` Tejun Heo
2008-08-06  2:30                 ` Robert Hancock
2008-08-06 11:27                 ` Sergei Shtylyov
2008-08-06  8:51               ` Alan Cox
2008-08-04 21:55         ` Sergei Shtylyov
2008-08-04 21:43           ` Alan Cox
2008-08-04 22:45             ` Sergei Shtylyov
2008-08-04 22:52               ` Sergei Shtylyov
2008-08-06 11:17                 ` Sergei Shtylyov
2008-08-04 22:12         ` Mark Lord
2008-08-04 22:00           ` Alan Cox
2008-08-04 20:37       ` Jeff Garzik

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=1217791284.4179.34.camel@localhost.localdomain \
    --to=james.bottomley@hansenpartnership.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=ksummit-2008-discuss@lists.linux-foundation.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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

Powered by JetHome