From: Jeff Garzik <jeff@garzik.org>
To: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Cc: Jonathan Corbet <corbet@lwn.net>,
Boaz Harrosh <bharrosh@panasas.com>,
James Bottomley <James.Bottomley@hansenpartnership.com>,
Zach Brown <zach.brown@oracle.com>,
Chris Mason <chris.mason@oracle.com>, Tejun Heo <tj@kernel.org>,
linux-scsi <linux-scsi@vger.kernel.org>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Linux IDE mailing list <linux-ide@vger.kernel.org>
Subject: Re: LSF Papers online?
Date: Tue, 14 Apr 2009 06:14:00 -0400 [thread overview]
Message-ID: <49E461E8.10106@garzik.org> (raw)
In-Reply-To: <200904140324.59657.bzolnier@gmail.com>
Bartlomiej Zolnierkiewicz wrote:
> On Tuesday 14 April 2009 00:24:57 Jeff Garzik wrote:
>> Bartlomiej Zolnierkiewicz wrote:
>>> I've started reading it and immediately noticed a thing which made by day. :-)
>>>
>>> Sorry if it will sound off-topic or undiplomatic but it is the best occasion
>>> to straighten up some facts:
>>>
>>> "Discussion then moved on to the current status of getting libata out of
>>> SCSI: we have had several successes, notably timer handling and pieces of
>>> error handling have moved up to block. Unfortunately, the current progress
>>> has reached the point where it's being impeded by the legacy IDE subsystem
>>>
>>> Heh, you can also blame the lack of world peace on the legacy IDE subsystem.
>>>
>>> I wonder who came up with this ridiculous excuse (I'm sure it wasn't James!).
>
> It was you!? :)
>
>>> The thing is that during last _five_ years almost nothing was done in this
>>> direction. Despite the fact that it was #1 condition under which the whole
>>> code has been merged. Sorry to say it but it seems like the whole merge
>>> strategy was to over-promise things now and worry about delivery later.
>> Yet, shockingly, users have been happily using libata despite all these
>> horrors.
>
> That was not the issue raised:
>
> If you think that you can take a "I will deliver later" credit from the
> developers community and later cover it up by "this is still my goal, I
> just need to find some suckers to do it for me" and think that you won by
> fooling people you're sadly mistaken and will most likely have a reality
> check one day (not from me, I really don't care that much to waste my
> precious time on proving you wrong).
The project you refer to -- move libata out of SCSI -- is far less
important than another project: keep libata going amidst new SAS and
SATA hardware.
Choosing to use the SCSI driver infrastructure was a solid technical
decision in the beginning, and time has proven that true: since we were
inside SCSI, ATAPI and SAT support came naturally. Support for SAS+SATA
controllers came naturally.
So it was absolutely the right thing to do for Linux users, to
de-prioritize the libata-out-of-SCSI project.
The users were not, and are not, asking for it. It will even introduce
some breakage if you're not careful.
The only people who even mention it are a few key IDE and block layer
developers - me, you, Tejun, Jens, sometimes James B. Linus has
probably forgotten, but for I occasionally mention it at kernel summits.
I think Linux users are happy that they were delivered a working ATA
driver of a much more clean design. That is the delivery that matters.
Even with the benefit of hindsight, I don't see that libata development
should have happened any other way.
Moving libata out of SCSI is now a long term, far off goal. A goal that
implies many intermediate steps, cleanups to block, libata, IDE, SCSI
and other block drivers.
I am highly confident we will reach this goal eventually, but there is
no rush. If it takes ten years, fine. THIS IS THE PROCESS. The end
result will be that all storage drivers in the kernel are improved.
We steer this ship by having a general idea of where we want to go, not
a specific roadmap. Interesting, unexpected things happen during the
journey, perhaps taking you down a different course. Open source...
it's all very zen. :)
Jeff
next parent reply other threads:[~2009-04-14 10:14 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <49E335BA.3020103@panasas.com>
[not found] ` <200904132340.21525.bzolnier@gmail.com>
[not found] ` <49E3BBB9.4040100@garzik.org>
[not found] ` <200904140324.59657.bzolnier@gmail.com>
2009-04-14 10:14 ` Jeff Garzik [this message]
2009-04-14 14:54 ` LSF Papers online? Bartlomiej Zolnierkiewicz
2009-04-14 15:40 ` Jeff Garzik
2009-04-14 16:54 ` Alan Cox
2009-04-14 22:09 ` Bartlomiej Zolnierkiewicz
2009-04-14 22:49 ` James Bottomley
2009-04-15 1:39 ` Robert Hancock
2009-04-15 3:58 ` James Bottomley
2009-04-15 8:30 ` Alan Cox
2009-04-16 6:31 ` Grant Grundler
2009-04-16 16:37 ` James Bottomley
2009-04-16 17:45 ` Matthew Wilcox
2009-04-14 23:14 ` Jeff Garzik
2009-04-15 9:28 ` Alan Cox
2009-04-15 13:38 ` Bartlomiej Zolnierkiewicz
2009-04-15 14:56 ` Alan Cox
2009-04-16 16:01 ` Bartlomiej Zolnierkiewicz
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=49E461E8.10106@garzik.org \
--to=jeff@garzik.org \
--cc=James.Bottomley@hansenpartnership.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=bharrosh@panasas.com \
--cc=bzolnier@gmail.com \
--cc=chris.mason@oracle.com \
--cc=corbet@lwn.net \
--cc=linux-ide@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=tj@kernel.org \
--cc=zach.brown@oracle.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).