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
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
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
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
From: Jeff Garzik <[email protected]>
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.
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
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
On Tue, 2007-10-23 at 15:36 -0700, David Miller wrote:
> From: Jeff Garzik <[email protected]>
> 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
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."
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
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
On Wed, 24 Oct 2007 09:28:10 -0400 James Bottomley <[email protected]> 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.
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
On Wed, 24 Oct 2007 08:35:21 -0700 (PDT) Linus Torvalds <[email protected]> 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.
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