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: G...
[ message continues ]

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

	Jeff



-

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


-

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



-

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

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


-

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 -- 

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

	Jeff


-

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
-

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



-

From: Jeff Garzik <jeff@garzik.org>

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


-

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 ...
[ message continues ]

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.
-

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.
-

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."
-

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