[GIT PATCH] final SCSI pieces for the merge window

[GIT PATCH] final SCSI pieces for the merge window

[James Bottomley]

This should be the final SCSI updates; it's mainly just a few accessor
completion updates and two driver merges (sym2 and qla2xxx) we also
secured DaveM's agreement to remove fcal/fc4, which explains the high
removal line count.

The patch is available here:

master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git

The short changelog is:

Adrian Bunk (3):
      gdth: __init fixes
      aic7xxx_old: fix accidental logic reversal
      lpfc: lpfc_debugfs.c: fix typo

Alan Cox (1):
      initio: Fix merge fallout

Andrew Morton (1):
      qla2xxx: printk fixes

Andrew Vasquez (8):
      qla2xxx: Update version number to 8.02.00-k5.
      qla2xxx: Correct display of ISP serial-number.
      qla2xxx: Correct residual-count handling discrepancies during UNDERRUN han
      qla2xxx: Make driver (mostly) legacy I/O port free.
      qla2xxx: Fix issue where final flash-segment updates were falling into the
      qla2xxx: Handle unaligned sector writes during NVRAM/VPD updates.
      qla2xxx: Defer explicit interrupt-polling processing to init-time scenario
      qla2xxx: Resync with latest HBA SSID specification -- 2.2u.

Hannes Reinecke (3):
      aic7xxx: Fix firmware build
      aic7xxx: Update Maintainer information
      aic7xxx: Add suspend/resume support

HighPoint Linux Team (1):
      hptiop: avoid buffer overflow when returning sense data

James Bottomley (2):
      make supported_mode default to initiator.
      include linux/scatterlist.h in scsi_eh.h

Johannes Dickgreber (2):
      qla1280: eliminate wasted space in request and response ring
      qla1280: uses wrong failure path after failed pci_set_dma_mask

Kai Makisara (1):
      sym53c8xx: Work around 53c896 erratum

Linas Vepstas (1):
      sym53c8xx: PCI Error Recovery support

Matthew Wilcox (16):
      sym53c8xx: Remove sym_xpt_async_sent_bdr
      sym53c8xx: Remove pci_dev pointer from sym_shcb
      sym53c8xx: Make interrupt handler capable of returning IRQ_NONE
      sym53c8xx: Get rid of IRQ_FMT and IRQ_PRM
      sym53c8xx: Use scmd_printk where appropriate
      sym53c8xx: Simplify DAC DMA handling
      sym53c8xx: Remove tag_ctrl module parameter
      sym53c8xx: Remove io_ws, mmio_ws and ram_ws elements
      sym53c8xx: Remove ->device_id
      sym53c8xx: Use pdev->revision
      sym53c8xx: Stop overriding scsi_done
      sym53c8xx: Don't disable interrupts in the interrupt handler
      sym53c8xx: Remove unnecessary check in queuecommand
      sym53c8xx: Remove data_mapping and data_mapped
      sym53c8xx: Use pci_dev irq number
      fc4: remove this and all associated drivers

and the diffstat:

 b/Documentation/scsi/sym53c8xx_2.txt              |   21 
 b/MAINTAINERS                                     |    6 
 b/arch/sparc64/Kconfig                            |    2 
 b/drivers/Makefile                                |    1 
 b/drivers/scsi/Makefile                           |    2 
 b/drivers/scsi/aic7xxx/aic7770.c                  |   16 
 b/drivers/scsi/aic7xxx/aic79xx.h                  |   11 
 b/drivers/scsi/aic7xxx/aic79xx_core.c             |    7 
 b/drivers/scsi/aic7xxx/aic79xx_osm.c              |    4 
 b/drivers/scsi/aic7xxx/aic79xx_osm_pci.c          |   50 
 b/drivers/scsi/aic7xxx/aic79xx_pci.c              |   27 
 b/drivers/scsi/aic7xxx/aic7xxx.h                  |   11 
 b/drivers/scsi/aic7xxx/aic7xxx_osm.c              |    4 
 b/drivers/scsi/aic7xxx/aic7xxx_osm_pci.c          |   46 
 b/drivers/scsi/aic7xxx/aic7xxx_pci.c              |   16 
 b/drivers/scsi/aic7xxx/aicasm/aicasm_macro_scan.l |    3 
 b/drivers/scsi/aic7xxx_old.c                      |    2 
 b/drivers/scsi/gdth.c                             |    6 
 b/drivers/scsi/hosts.c                            |    6 
 b/drivers/scsi/hptiop.c                           |    5 
 b/drivers/scsi/initio.c                           |    6 
 b/drivers/scsi/lpfc/lpfc_debugfs.c                |    2 
 b/drivers/scsi/qla1280.c                          |    4 
 b/drivers/scsi/qla1280.h                          |    4 
 b/drivers/scsi/qla2xxx/qla_attr.c                 |    9 
 b/drivers/scsi/qla2xxx/qla_def.h                  |    1 
 b/drivers/scsi/qla2xxx/qla_devtbl.h               |    7 
 b/drivers/scsi/qla2xxx/qla_iocb.c                 |    2 
 b/drivers/scsi/qla2xxx/qla_isr.c                  |    8 
 b/drivers/scsi/qla2xxx/qla_mbx.c                  |    2 
 b/drivers/scsi/qla2xxx/qla_os.c                   |   50 
 b/drivers/scsi/qla2xxx/qla_sup.c                  |   30 
 b/drivers/scsi/qla2xxx/qla_version.h              |    2 
 b/drivers/scsi/scsi_error.c                       |    1 
 b/drivers/scsi/scsi_sysfs.c                       |   10 
 b/drivers/scsi/sym53c8xx_2/sym53c8xx.h            |    1 
 b/drivers/scsi/sym53c8xx_2/sym_fw.c               |   18 
 b/drivers/scsi/sym53c8xx_2/sym_fw.h               |    2 
 b/drivers/scsi/sym53c8xx_2/sym_glue.c             |  581 +++++------
 b/drivers/scsi/sym53c8xx_2/sym_glue.h             |   16 
 b/drivers/scsi/sym53c8xx_2/sym_hipd.c             |  159 +--
 b/drivers/scsi/sym53c8xx_2/sym_hipd.h             |   22 
 b/drivers/scsi/sym53c8xx_2/sym_nvram.c            |    2 
 b/include/scsi/scsi_eh.h                          |    2 
 drivers/fc4/Kconfig                               |   81 -
 drivers/fc4/Makefile                              |    9 
 drivers/fc4/fc-al.h                               |   27 
 drivers/fc4/fc.c                                  | 1146 ----------------------
 drivers/fc4/fc.h                                  |  230 ----
 drivers/fc4/fc_syms.c                             |   30 
 drivers/fc4/fcp.h                                 |   94 -
 drivers/fc4/fcp_impl.h                            |  164 ---
 drivers/fc4/soc.c                                 |  764 --------------
 drivers/fc4/soc.h                                 |  301 -----
 drivers/fc4/socal.c                               |  904 -----------------
 drivers/fc4/socal.h                               |  314 ------
 drivers/scsi/fcal.c                               |  317 ------
 drivers/scsi/fcal.h                               |   27 
 drivers/scsi/pluto.c                              |  349 ------
 drivers/scsi/pluto.h                              |   47 
 60 files changed, 675 insertions(+), 5316 deletions(-)

James

Re: [GIT PATCH] final SCSI pieces for the merge window

[Jeff Garzik]

James Bottomley wrote:
> This should be the final SCSI updates; it's mainly just a few accessor
> completion updates and two driver merges (sym2 and qla2xxx) we also
> secured DaveM's agreement to remove fcal/fc4, which explains the high
> removal line count.
> 
> The patch is available here:
> 
> master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git

I guess I have the go-ahead to merge the end-CDROM-polling async 
notification work you've been repeatedly ignoring?

	Jeff

Re: [GIT PATCH] final SCSI pieces for the merge window

[James Bottomley]

On Tue, 2007-10-23 at 17:09 -0400, Jeff Garzik wrote:
> James Bottomley wrote:
> > This should be the final SCSI updates; it's mainly just a few accessor
> > completion updates and two driver merges (sym2 and qla2xxx) we also
> > secured DaveM's agreement to remove fcal/fc4, which explains the high
> > removal line count.
> > 
> > The patch is available here:
> > 
> > master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
> 
> I guess I have the go-ahead to merge the end-CDROM-polling async 
> notification work you've been repeatedly ignoring?

I haven't been ignoring it ... it just needs quite a bit of work; the
best way to accelerate it seems to be simply to do it (add the
supported/trigger event bitmasks and expand the infrastructure).  I just
haven't had the time within the merge window.

James

Re: [GIT PATCH] final SCSI pieces for the merge window

[Jeff Garzik]

James Bottomley wrote:
> On Tue, 2007-10-23 at 17:09 -0400, Jeff Garzik wrote:
>> James Bottomley wrote:
>>> This should be the final SCSI updates; it's mainly just a few accessor
>>> completion updates and two driver merges (sym2 and qla2xxx) we also
>>> secured DaveM's agreement to remove fcal/fc4, which explains the high
>>> removal line count.
>>>
>>> The patch is available here:
>>>
>>> master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
>> I guess I have the go-ahead to merge the end-CDROM-polling async 
>> notification work you've been repeatedly ignoring?
> 
> I haven't been ignoring it ... it just needs quite a bit of work; the
> best way to accelerate it seems to be simply to do it (add the
> supported/trigger event bitmasks and expand the infrastructure).  I just
> haven't had the time within the merge window.

James, things cannot get bottlenecked like this.  You have had MONTHS to 
say something like this.  The code was ready BEFORE the merge window.

I really think you have the knowledge to be SCSI maintainer, but not the 
time.

	Jeff

Re: [GIT PATCH] final SCSI pieces for the merge window

[David Miller]

From: Jeff Garzik <jeff@garzik.org>
Date: Tue, 23 Oct 2007 18:06:51 -0400

> James Bottomley wrote:
> > On Tue, 2007-10-23 at 17:09 -0400, Jeff Garzik wrote:
> >> James Bottomley wrote:
> >>> This should be the final SCSI updates; it's mainly just a few accessor
> >>> completion updates and two driver merges (sym2 and qla2xxx) we also
> >>> secured DaveM's agreement to remove fcal/fc4, which explains the high
> >>> removal line count.
> >>>
> >>> The patch is available here:
> >>>
> >>> master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
> >> I guess I have the go-ahead to merge the end-CDROM-polling async 
> >> notification work you've been repeatedly ignoring?
> > 
> > I haven't been ignoring it ... it just needs quite a bit of work; the
> > best way to accelerate it seems to be simply to do it (add the
> > supported/trigger event bitmasks and expand the infrastructure).  I just
> > haven't had the time within the merge window.
> 
> James, things cannot get bottlenecked like this.  You have had MONTHS to 
> say something like this.  The code was ready BEFORE the merge window.
> 
> I really think you have the knowledge to be SCSI maintainer, but not the 
> time.

Unfortunately, I think this is an important point.

Developers depend strongly upon a subsystem maintainer to
"make time" for these things so that work integration does
not get delayed past the merge window if at all possible.

Not being able to "make time" to do these things is a great
way to lose contributers.

James, whilst there is no doubt in my mind that skill-wise
you are probably the most capable scsi maintainer, your "lack
of time" is sounding like a broken record and harming the
development process.

Re: [GIT PATCH] final SCSI pieces for the merge window

[James Bottomley]

On Tue, 2007-10-23 at 15:36 -0700, David Miller wrote:
> From: Jeff Garzik <jeff@garzik.org>
> Date: Tue, 23 Oct 2007 18:06:51 -0400
> 
> > James Bottomley wrote:
> > > On Tue, 2007-10-23 at 17:09 -0400, Jeff Garzik wrote:
> > >> James Bottomley wrote:
> > >>> This should be the final SCSI updates; it's mainly just a few accessor
> > >>> completion updates and two driver merges (sym2 and qla2xxx) we also
> > >>> secured DaveM's agreement to remove fcal/fc4, which explains the high
> > >>> removal line count.
> > >>>
> > >>> The patch is available here:
> > >>>
> > >>> master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
> > >> I guess I have the go-ahead to merge the end-CDROM-polling async 
> > >> notification work you've been repeatedly ignoring?
> > > 
> > > I haven't been ignoring it ... it just needs quite a bit of work; the
> > > best way to accelerate it seems to be simply to do it (add the
> > > supported/trigger event bitmasks and expand the infrastructure).  I just
> > > haven't had the time within the merge window.
> > 
> > James, things cannot get bottlenecked like this.  You have had MONTHS to 
> > say something like this.  The code was ready BEFORE the merge window.
> > 
> > I really think you have the knowledge to be SCSI maintainer, but not the 
> > time.
> 
> Unfortunately, I think this is an important point.
> 
> Developers depend strongly upon a subsystem maintainer to
> "make time" for these things so that work integration does
> not get delayed past the merge window if at all possible.
> 
> Not being able to "make time" to do these things is a great
> way to lose contributers.
> 
> James, whilst there is no doubt in my mind that skill-wise
> you are probably the most capable scsi maintainer, your "lack
> of time" is sounding like a broken record and harming the
> development process.

OK, so it's no secret that I'm the last of the subsystem maintainers
whose day job isn't working on the linux kernel.  If you want a full
time person, who did you have in mind?

James

Re: [GIT PATCH] final SCSI pieces for the merge window

[Matthew Wilcox]

On Wed, Oct 24, 2007 at 09:28:10AM -0400, James Bottomley wrote:
> OK, so it's no secret that I'm the last of the subsystem maintainers
> whose day job isn't working on the linux kernel.  If you want a full
> time person, who did you have in mind?

I'm willing to take on the role of scsi git-monkey.  Alternatively, we
could split the scsi maintainer role the same way that Dave and Jeff
do for net where Dave handles the core and Jeff handles the drivers.
Or we can negotiate some other arrangement.

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: [GIT PATCH] final SCSI pieces for the merge window

[Denys Vlasenko]

On Wednesday 24 October 2007 15:27, Matthew Wilcox wrote:
> On Wed, Oct 24, 2007 at 09:28:10AM -0400, James Bottomley wrote:
> > OK, so it's no secret that I'm the last of the subsystem maintainers
> > whose day job isn't working on the linux kernel.  If you want a full
> > time person, who did you have in mind?
> 
> I'm willing to take on the role of scsi git-monkey.  Alternatively, we
> could split the scsi maintainer role the same way that Dave and Jeff
> do for net where Dave handles the core and Jeff handles the drivers.
> Or we can negotiate some other arrangement.

That would be great. Maybe my aic7xxx debloating patches
which were submitted four times already (IIRC)
will be looked at at last.
--
vda

Re: [GIT PATCH] final SCSI pieces for the merge window

[Andrew Morton]

On Wed, 24 Oct 2007 09:28:10 -0400 James Bottomley <James.Bottomley@SteelEye.com> wrote:

> OK, so it's no secret that I'm the last of the subsystem maintainers
> whose day job isn't working on the linux kernel.

For the record, lots of subsystem maintainers are privateers.

<goes through the git trees>

I am not aware that these guys:

Mauro Chehab, Dmitry Torokhov, Sam Ravnborg, Pierre Ossman, Mark Hoffman,
Thomas Gleixner, David Airlie, Richard Purdie, Peter Anvin, Kyle McMartin,
Francois Romieu, Artem Bityutskiy, Erez Zadok, Josef Sipek, Anton
Altaparmakov, Eric Van Hensbergen, Latchesar Ionkov, Wim Van Sebroeck,
Antonino Daplas.

do it with any compensation.

Re: [GIT PATCH] final SCSI pieces for the merge window

[Linus Torvalds]

On Wed, 24 Oct 2007, James Bottomley wrote:
> 
> OK, so it's no secret that I'm the last of the subsystem maintainers
> whose day job isn't working on the linux kernel.  If you want a full
> time person, who did you have in mind?

Quite frankly, at least for me personally, what I would rather have (in 
general: this is really not at all SCSI-specific in any way, shape, or 
form, and not directed at James!) is a less rigid maintainership 
structure.

Let's face it, we are *all* likely to be overworked at different times, 
and even when not overworked, it's just the fact that people need to take 
a breather etc. And there is seldom - if ever - a very strong argument for 
having one person per subsystem.

I think git is excellent for trying to spreading the "joy" of 
maintainership, but even without something like that, I think it's much 
better to try to find people you can trust, rather than strict 
maintainership boundaries. For example, Andrew certainly seems to be very 
productive as a kernel maintainer, and it has nothing to do with git, and 
everything to do with trust.

So I'd rather have less recriminations about "xyz is holding up abc", and 
have people more open to just trying to help out even across strict 
borders. And I don't mean that in a "two fighting people" kind of way 
where there are two or more people who maintain things _despite_ each 
other, but more in a 

  "Hey we know each other, and we trust each other, and no, we won't 
   guarantee that we always agree, but we can work on things, and if it 
   turns out that one person merged somethign that the other person 
   _really_ doesn't like, we'll revert it and/or work it out some other 
   way".

I've personally always been against _strict_ maintainer lines, so I've 
always taken stuff "past" the maintainer anyway (and sometimes maintainers 
have complained, because they feel like they "own" their subsystem, and I 
either tell them to stuff it, or say "my bad", depending on whether they 
had a valid _technical_ complaint or not).

So rather than getting into a pissing match of "ok, who would be the best 
maintainer", I'd much *much* prefer to take this as another "we really 
don't need or even _want_ to have strict maintainer rules" opportunity.

Now, the most important part here is the trust part. I need to be able to 
trust maintainers, but when you have multiple people in the same "box", 
those people need to trust each other even more than usual, because you 
*are* going to get disagreements. And the only way it can work is if you 
acknowledge that disagreements will happen, and that any situation is  not 
a "my way or the highway" kind of thing - the trust also implies a certain 
give and take.

And this really *is* an issue that cuts across subsystem boundaries. 
Anybody who thinks that SCSI is "unique" in this kind of issues is sadly 
mistaken. We've had the exact same thing come up in every single subsystem 
over time, and at every single level of maintainership (from individual 
drivers all the way right up to me) over time.

So I *really* don't want to throw any stones in a glass house here. Quite 
the reverse. I'd like to get rid of some of the glass, and replace it with 
padding. Because you all know we'd all fit better in a padded room than a 
glass house..

Are there any such people that think there s a sufficient mutual trust 
with James that you think a blurring of maintainership lines could work 
out? Or in any other subsystem, for that matter? Hmm?

			Linus

Re: [GIT PATCH] final SCSI pieces for the merge window

[Andrew Morton]

On Wed, 24 Oct 2007 08:35:21 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Wed, 24 Oct 2007, James Bottomley wrote:
> > 
> > OK, so it's no secret that I'm the last of the subsystem maintainers
> > whose day job isn't working on the linux kernel.  If you want a full
> > time person, who did you have in mind?
> 
> Quite frankly, at least for me personally, what I would rather have (in 
> general: this is really not at all SCSI-specific in any way, shape, or 
> form, and not directed at James!) is a less rigid maintainership 
> structure.
> 
> Let's face it, we are *all* likely to be overworked at different times, 
> and even when not overworked, it's just the fact that people need to take 
> a breather etc. And there is seldom - if ever - a very strong argument for 
> having one person per subsystem.

Am OK with all of that, but with a rider.  It would make my life even more
miserable if there was a (say) git-scsi-tweedledee and a
git-scsi-tweedledum.  We already have too much out-of-scope code turning up
in the git trees and having two trees explicitly modifying the same
subsystem would hurt.  It's also bad from an engineering POV: there's a
decent chance that when combined, they just won't work.

So Tweedledee and Tweedledum should both commit to the same tree, please.

Re: [GIT PATCH] final SCSI pieces for the merge window

[Douglas Gilbert]

Jeff Garzik wrote:
> James Bottomley wrote:
>> On Tue, 2007-10-23 at 17:09 -0400, Jeff Garzik wrote:
>>> James Bottomley wrote:
>>>> This should be the final SCSI updates; it's mainly just a few accessor
>>>> completion updates and two driver merges (sym2 and qla2xxx) we also
>>>> secured DaveM's agreement to remove fcal/fc4, which explains the high
>>>> removal line count.
>>>>
>>>> The patch is available here:
>>>>
>>>> master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
>>> I guess I have the go-ahead to merge the end-CDROM-polling async
>>> notification work you've been repeatedly ignoring?
>>
>> I haven't been ignoring it ... it just needs quite a bit of work; the
>> best way to accelerate it seems to be simply to do it (add the
>> supported/trigger event bitmasks and expand the infrastructure).  I just
>> haven't had the time within the merge window.
> 
> James, things cannot get bottlenecked like this.  You have had MONTHS to
> say something like this.  The code was ready BEFORE the merge window.
> 
> I really think you have the knowledge to be SCSI maintainer, but not the
> time.

Jeff,
If only I had a dollar (Canadian unit please) for
each day some of my libata patches were queued
up to you before you accepted them.

Remember MODE SELECT ...


On a more serious note, it looks like the job of the SCSI
maintainer is getting larger and more onerous. Perhaps
some folks should check if James has been provided with
the appropriate resources.

Doug Gilbert

Re: [GIT PATCH] final SCSI pieces for the merge window

[Jeff Garzik]

Douglas Gilbert wrote:
> Jeff Garzik wrote:
>> James Bottomley wrote:
>>> On Tue, 2007-10-23 at 17:09 -0400, Jeff Garzik wrote:
>>>> James Bottomley wrote:
>>>>> This should be the final SCSI updates; it's mainly just a few accessor
>>>>> completion updates and two driver merges (sym2 and qla2xxx) we also
>>>>> secured DaveM's agreement to remove fcal/fc4, which explains the high
>>>>> removal line count.
>>>>>
>>>>> The patch is available here:
>>>>>
>>>>> master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
>>>> I guess I have the go-ahead to merge the end-CDROM-polling async
>>>> notification work you've been repeatedly ignoring?
>>> I haven't been ignoring it ... it just needs quite a bit of work; the
>>> best way to accelerate it seems to be simply to do it (add the
>>> supported/trigger event bitmasks and expand the infrastructure).  I just
>>> haven't had the time within the merge window.
>> James, things cannot get bottlenecked like this.  You have had MONTHS to
>> say something like this.  The code was ready BEFORE the merge window.
>>
>> I really think you have the knowledge to be SCSI maintainer, but not the
>> time.
> 
> Jeff,
> If only I had a dollar (Canadian unit please) for
> each day some of my libata patches were queued
> up to you before you accepted them.
> 
> Remember MODE SELECT ...

You're darned right, I've screwed up in the past.  Sat on stuff "until I 
get time to rewrite it" and that sort of thing.  My colleagues give me 
lumps for it too :)

We talked about this issue at the Kernel Summit -- collectively we need 
to stop holding on to useful, working stuff for months on end.  It 
serves nobody.

We have to rediscover our roots:  "release early, release often"

	Jeff

Re: [GIT PATCH] final SCSI pieces for the merge window

[James Bottomley]

On Tue, 2007-10-23 at 18:06 -0400, Jeff Garzik wrote:
> James Bottomley wrote:
> > On Tue, 2007-10-23 at 17:09 -0400, Jeff Garzik wrote:
> >> James Bottomley wrote:
> >>> This should be the final SCSI updates; it's mainly just a few accessor
> >>> completion updates and two driver merges (sym2 and qla2xxx) we also
> >>> secured DaveM's agreement to remove fcal/fc4, which explains the high
> >>> removal line count.
> >>>
> >>> The patch is available here:
> >>>
> >>> master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
> >> I guess I have the go-ahead to merge the end-CDROM-polling async 
> >> notification work you've been repeatedly ignoring?
> > 
> > I haven't been ignoring it ... it just needs quite a bit of work; the
> > best way to accelerate it seems to be simply to do it (add the
> > supported/trigger event bitmasks and expand the infrastructure).  I just
> > haven't had the time within the merge window.
> 
> James, things cannot get bottlenecked like this.  You have had MONTHS to 
> say something like this.  The code was ready BEFORE the merge window.

The patch in question is an interface to user space.  The problem with
those is that you can't put them in and refine them because the user
visible interface changes when you do that.

> I really think you have the knowledge to be SCSI maintainer, but not the 
> time.

The pot is calling the kettle black here, since libata was supposed to
have moved out of SCSI about three years ago by helping us move the
shared elements up to block.  As far as I can tell, the only progress
we've made in this area is me adding the odd API shift.

James

Re: [GIT PATCH] final SCSI pieces for the merge window

[Jeff Garzik]

James Bottomley wrote:
> On Tue, 2007-10-23 at 18:06 -0400, Jeff Garzik wrote:
>> James Bottomley wrote:
>>> On Tue, 2007-10-23 at 17:09 -0400, Jeff Garzik wrote:
>>>> James Bottomley wrote:
>>>>> This should be the final SCSI updates; it's mainly just a few accessor
>>>>> completion updates and two driver merges (sym2 and qla2xxx) we also
>>>>> secured DaveM's agreement to remove fcal/fc4, which explains the high
>>>>> removal line count.
>>>>>
>>>>> The patch is available here:
>>>>>
>>>>> master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
>>>> I guess I have the go-ahead to merge the end-CDROM-polling async 
>>>> notification work you've been repeatedly ignoring?
>>> I haven't been ignoring it ... it just needs quite a bit of work; the
>>> best way to accelerate it seems to be simply to do it (add the
>>> supported/trigger event bitmasks and expand the infrastructure).  I just
>>> haven't had the time within the merge window.
>> James, things cannot get bottlenecked like this.  You have had MONTHS to 
>> say something like this.  The code was ready BEFORE the merge window.
> 
> The patch in question is an interface to user space.  The problem with
> those is that you can't put them in and refine them because the user
> visible interface changes when you do that.

Post August, this user space interface patch has received (a) silence or 
(b) this vague general worry about changing user space interfaces.  All 
the while it is working and was revised according to comment at the time.

At some point you gotta stop waiting for perfection or that mythical 
"when I get a round tuit" and actually DO something.

When I see the new patch to end CD-ROM polling grow moldy for two months 
while rewrites to ancient SCSI drivers go in, I throw up my hands in 
wonderment.  Poor Andrew is constantly resending -mm patches to you -- 
some stick, some vanish into the ether without comment.  For months.


>> I really think you have the knowledge to be SCSI maintainer, but not the 
>> time.
> 
> The pot is calling the kettle black here, since libata was supposed to
> have moved out of SCSI about three years ago by helping us move the
> shared elements up to block.  As far as I can tell, the only progress
> we've made in this area is me adding the odd API shift.

You're talking about long term directions, I'm talking about actually 
getting day-to-day work accomplished.

	Jeff