Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver

Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver

[Finn Thain]

On Sat, 13 Jun 2020, Chris Boot wrote:

> I no longer have the time to maintain this subsystem nor the hardware to
> test patches with. 

Then why not patch MAINTAINERS, and orphan it, as per usual practice?

$ git log --oneline MAINTAINERS | grep -i orphan

> It also doesn't appear to have any active users so I doubt anyone will 
> miss it.
> 

It's not unusual that any Linux driver written more than 5 years ago 
"doesn't appear to have any active users".

If a driver has been orphaned and broken in the past, and no-one stepped 
up to fix it within a reasonable period, removal would make sense. But 
that's not the case here.

I haven't used this driver for a long time, but I still own PowerMacs with 
firewire, and I know I'm not the only one.

> Signed-off-by: Chris Boot <bootc@bootc.net>
> ---
>  MAINTAINERS                     |    9 -
>  drivers/target/Kconfig          |    1 -
>  drivers/target/Makefile         |    1 -
>  drivers/target/sbp/Kconfig      |   12 -
>  drivers/target/sbp/Makefile     |    2 -
>  drivers/target/sbp/sbp_target.c | 2350 -------------------------------
>  drivers/target/sbp/sbp_target.h |  243 ----
>  7 files changed, 2618 deletions(-)
>  delete mode 100644 drivers/target/sbp/Kconfig
>  delete mode 100644 drivers/target/sbp/Makefile
>  delete mode 100644 drivers/target/sbp/sbp_target.c
>  delete mode 100644 drivers/target/sbp/sbp_target.h
> 

Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver

[Chris Boot]

On 14/06/2020 01:03, Finn Thain wrote:
> On Sat, 13 Jun 2020, Chris Boot wrote:
> 
>> I no longer have the time to maintain this subsystem nor the hardware to
>> test patches with. 
> 
> Then why not patch MAINTAINERS, and orphan it, as per usual practice?
> 
> $ git log --oneline MAINTAINERS | grep -i orphan

My patch to remove it was in response to:

https://lore.kernel.org/lkml/yq1img99d4k.fsf@ca-mkp.ca.oracle.com/

>> It also doesn't appear to have any active users so I doubt anyone will 
>> miss it.
>>
> 
> It's not unusual that any Linux driver written more than 5 years ago 
> "doesn't appear to have any active users".
> 
> If a driver has been orphaned and broken in the past, and no-one stepped 
> up to fix it within a reasonable period, removal would make sense. But 
> that's not the case here.
> 
> I haven't used this driver for a long time, but I still own PowerMacs with 
> firewire, and I know I'm not the only one.

I expect that if someone finds this useful it can stick around (but
that's not my call). I just don't have the time or inclination or
hardware to be able to maintain it anymore, so someone else would have
to pick it up.

Cheers,
Chris

-- 
Chris Boot
bootc@boo.tc

Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver

[Finn Thain]

On Sun, 14 Jun 2020, Chris Boot wrote:

> I expect that if someone finds this useful it can stick around (but 
> that's not my call).

Who's call is that? If the patch had said "From: Martin K. Petersen" and 
"This driver is being removed because it has the following defects..." 
that would be some indication of a good-faith willingness to accept users 
as developers in the spirit of the GPL, which is what you seem to be 
alluding to (?).

> I just don't have the time or inclination or hardware to be able to 
> maintain it anymore, so someone else would have to pick it up.
> 

Which is why most drivers get orphaned, right?

Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver

[Chris Boot]

On 15/06/2020 00:28, Finn Thain wrote:
> On Sun, 14 Jun 2020, Chris Boot wrote:
> 
>> I expect that if someone finds this useful it can stick around (but 
>> that's not my call).
> 
> Who's call is that? If the patch had said "From: Martin K. Petersen" and 
> "This driver is being removed because it has the following defects..." 
> that would be some indication of a good-faith willingness to accept users 
> as developers in the spirit of the GPL, which is what you seem to be 
> alluding to (?).

If you're asking me, I'd say it was martin's call:

> SCSI TARGET SUBSYSTEM                                                          
> M:      "Martin K. Petersen" <martin.petersen@oracle.com>                      
[...]
> F:      drivers/target/                                                        
> F:      include/target/                                                        

>> I just don't have the time or inclination or hardware to be able to 
>> maintain it anymore, so someone else would have to pick it up.
>>
> 
> Which is why most drivers get orphaned, right?

Sure, but that's not what Martin asked me to do, hence this patch.

-- 
Chris Boot
bootc@boo.tc

Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver

[Finn Thain]

On Mon, 15 Jun 2020, Chris Boot wrote:

> On 15/06/2020 00:28, Finn Thain wrote:
> > On Sun, 14 Jun 2020, Chris Boot wrote:
> > 
> >> I expect that if someone finds this useful it can stick around (but 
> >> that's not my call).
> > 
> > Who's call is that? If the patch had said "From: Martin K. Petersen" 
> > and "This driver is being removed because it has the following 
> > defects..." that would be some indication of a good-faith willingness 
> > to accept users as developers in the spirit of the GPL, which is what 
> > you seem to be alluding to (?).
> 
> If you're asking me, I'd say it was martin's call:
> 
> > SCSI TARGET SUBSYSTEM                                                          
> > M:      "Martin K. Petersen" <martin.petersen@oracle.com>                      
> [...]
> > F:      drivers/target/                                                        
> > F:      include/target/                                                        
> 

The question I asked you was intended to make you think. I wasn't asking 
you to search MAINTAINERS for "drivers/target" (I had already done so).

Chris, you can find my name in that file too. That's because I see my role 
as custodian of that particular code. That code lives in the kernel.org 
tree because others put it there and because users find it useful -- not 
merely because it happens to please the official glorious MAINTAINER of 
said code.

If you would ask, "who's call is it to delete drivers/nubus? or 
drivers/scsi/NCR5380.c?" my answer is, I have no idea.

> >> I just don't have the time or inclination or hardware to be able to 
> >> maintain it anymore, so someone else would have to pick it up.
> >>
> > 
> > Which is why most drivers get orphaned, right?
> 
> Sure, but that's not what Martin asked me to do, hence this patch.
> 

Martin said, "I'd appreciate a patch to remove it"

And Bart said, "do you want to keep this driver in the kernel tree?"

AFAICT both comments are quite ambiguous. I don't see an actionable 
request, just an expression of interest from people doing their jobs.

Note well: there is no pay check associated with having a MAINTAINERS file 
entry.

Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver

[Bart Van Assche]

On 2020-06-16 02:42, Finn Thain wrote:
> Martin said, "I'd appreciate a patch to remove it"
> 
> And Bart said, "do you want to keep this driver in the kernel tree?"
> 
> AFAICT both comments are quite ambiguous. I don't see an actionable 
> request, just an expression of interest from people doing their jobs.
> 
> Note well: there is no pay check associated with having a MAINTAINERS file 
> entry.

Hi Finn,

As far as I know the sbp driver only has had one user ever and that user
is no longer user the sbp driver. So why to keep it in the kernel tree?
Restoring a kernel driver can be easy - the first step is a "git revert".

Thanks,

Bart.

Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver

[Johannes Thumshirn]

On 16/06/2020 16:09, Bart Van Assche wrote:
> On 2020-06-16 02:42, Finn Thain wrote:
>> Martin said, "I'd appreciate a patch to remove it"
>>
>> And Bart said, "do you want to keep this driver in the kernel tree?"
>>
>> AFAICT both comments are quite ambiguous. I don't see an actionable 
>> request, just an expression of interest from people doing their jobs.
>>
>> Note well: there is no pay check associated with having a MAINTAINERS file 
>> entry.
> 
> Hi Finn,
> 
> As far as I know the sbp driver only has had one user ever and that user
> is no longer user the sbp driver. So why to keep it in the kernel tree?
> Restoring a kernel driver can be easy - the first step is a "git revert".

Why not move the driver to drivers/staging for 2 or 3 kernel releases and if
noone steps up, delete it?

Just my 2 Cents,
	Johannes

Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver

[James Bottomley]

On Tue, 2020-06-16 at 14:13 +0000, Johannes Thumshirn wrote:
> On 16/06/2020 16:09, Bart Van Assche wrote:
> > On 2020-06-16 02:42, Finn Thain wrote:
> > > Martin said, "I'd appreciate a patch to remove it"
> > > 
> > > And Bart said, "do you want to keep this driver in the kernel
> > > tree?"
> > > 
> > > AFAICT both comments are quite ambiguous. I don't see an
> > > actionable request, just an expression of interest from people
> > > doing their jobs.
> > > 
> > > Note well: there is no pay check associated with having a
> > > MAINTAINERS file 
> > > entry.
> > 
> > Hi Finn,
> > 
> > As far as I know the sbp driver only has had one user ever and that
> > user is no longer user the sbp driver. So why to keep it in the
> > kernel tree? Restoring a kernel driver can be easy - the first step
> > is a "git revert".
> 
> Why not move the driver to drivers/staging for 2 or 3 kernel releases
> and if noone steps up, delete it?

Because that's pretty much the worst of all worlds: If the driver is
simply going orphaned it can stay where it is to avoid confusion.  If
it's being removed, it's better to remove it from where it is because
that makes the patch to restore it easy to find.

Chris, the thing is this: if this driver has just one user on a stable
distro who complains about its removal six months to two years from
now, Linus will descend on us from a great height (which won't matter
to you, since you'll be long gone).  This makes everyone very wary of
outright removal.  If you're really, really sure it has no users, it
can be deleted, but if there's the slightest chance it has just one, it
should get orphaned.

James

Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver

[Chris Boot]

On 16/06/2020 16:34, James Bottomley wrote:
> On Tue, 2020-06-16 at 14:13 +0000, Johannes Thumshirn wrote:
>> On 16/06/2020 16:09, Bart Van Assche wrote:
>>> On 2020-06-16 02:42, Finn Thain wrote:
>>>> Martin said, "I'd appreciate a patch to remove it"
>>>>
>>>> And Bart said, "do you want to keep this driver in the kernel
>>>> tree?"
>>>>
>>>> AFAICT both comments are quite ambiguous. I don't see an
>>>> actionable request, just an expression of interest from people
>>>> doing their jobs.
>>>>
>>>> Note well: there is no pay check associated with having a
>>>> MAINTAINERS file 
>>>> entry.
>>>
>>> Hi Finn,
>>>
>>> As far as I know the sbp driver only has had one user ever and that
>>> user is no longer user the sbp driver. So why to keep it in the
>>> kernel tree? Restoring a kernel driver can be easy - the first step
>>> is a "git revert".
>>
>> Why not move the driver to drivers/staging for 2 or 3 kernel releases
>> and if noone steps up, delete it?
> 
> Because that's pretty much the worst of all worlds: If the driver is
> simply going orphaned it can stay where it is to avoid confusion.  If
> it's being removed, it's better to remove it from where it is because
> that makes the patch to restore it easy to find.
> 
> Chris, the thing is this: if this driver has just one user on a stable
> distro who complains about its removal six months to two years from
> now, Linus will descend on us from a great height (which won't matter
> to you, since you'll be long gone).  This makes everyone very wary of
> outright removal.  If you're really, really sure it has no users, it
> can be deleted, but if there's the slightest chance it has just one, it
> should get orphaned.

My patch to delete the driver was based on Martin's original request:
https://lore.kernel.org/lkml/yq1img99d4k.fsf@ca-mkp.ca.oracle.com/

I don't especially want it to be gone, nor can I be sure there are no
users of what is as far as I can tell a working piece of code. I can
tell you that I never hear about it (other than the odd patch), whereas
I do get emails out of the blue for some of my other (much smaller)
stuff which clearly has users. I'd be just as happy for this to be
orphaned or for nothing to happen to it.

Honestly, I am totally ambivalent as to what happens to this code.
Martin, however, clearly cares enough to have asked me to supply a patch
to remove it.

Cheers,
Chris

-- 
Chris Boot
bootc@boo.tc

Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver

[Martin K. Petersen]

Chris,

> I don't especially want it to be gone, nor can I be sure there are no
> users of what is as far as I can tell a working piece of code. I can
> tell you that I never hear about it (other than the odd patch),
> whereas I do get emails out of the blue for some of my other (much
> smaller) stuff which clearly has users. I'd be just as happy for this
> to be orphaned or for nothing to happen to it.
>
> Honestly, I am totally ambivalent as to what happens to this code.
> Martin, however, clearly cares enough to have asked me to supply a
> patch to remove it.

I love it when people take ownership of old drivers. I think it's
wonderful that Finn and others are on the ball when it comes to the 5380
family. I don't care how old things are as long as they are being
actively used.

I am also very happy to keep things in the tree as long as there is a
healthy community around them. However, keeping code around is not
free. Core interfaces change frequently. Nobody enjoys having to tweak
host templates for 50 devices they have never even heard about. Also, we
now live in a reality where there is a constant barrage of build bots
and code analyzers sending mail. So the effective cost of keeping code
around in the tree is going up. I get a substantial amount of code
analysis mail about drivers nobody have touched in a decade or more.

Consequently, I am much more inclined to remove drivers than I have been
in the past. But I am also very happy to bring them back if somebody
uses them or - even better - are willing to step up and maintain them.

I don't particularly like the notion of a driver being orphaned because
all that really means is that the driver transitions from being (at
least partially) somebody else's problem to being mine and mine alone.

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver

[Finn Thain]

On Tue, 16 Jun 2020, Martin K. Petersen wrote:

> 
> However, keeping code around is not free.

Right. And removing code isn't free either, if it forces people to find 
workarounds.

> Core interfaces change frequently.  Nobody enjoys having to tweak host 
> templates for 50 devices they have never even heard about.

And yet some people seem to enjoy writing patches that are as trivial as 
they are invasive...

You seem to be making an argument for more automation here, not an 
argument for less code. Or is there some upper bound to the size of the 
kernel, that might be lifted by adding maintainers? (Can you deliver a 
better product by adding more developers to your project?)

> Also, we now live in a reality where there is a constant barrage of 
> build bots and code analyzers sending mail. So the effective cost of 
> keeping code around in the tree is going up.

But if maintenance cost rises due to good analysis, the value of the code 
should rise too. So what's the problem? It seems to me that the real 
problem is too many analyses that generate pedantic noise and no tangible 
improvement in code quality or value.

> I get a substantial amount of code analysis mail about drivers nobody 
> have touched in a decade or more.
> 

When stable, mature code fails analysis, the analysis is also questionable 
(in the absence of real examples).

> Consequently, I am much more inclined to remove drivers than I have been 
> in the past. But I am also very happy to bring them back if somebody 
> uses them or - even better - are willing to step up and maintain them.
> 

You seem to be saying that 1) a driver should be removed when it no longer 
meets the present threshold for code quality and 2) that a low quality 
driver is eligible for re-addition because someone wants to use it.
I don't think you can have it both ways.

> I don't particularly like the notion of a driver being orphaned because 
> all that really means is that the driver transitions from being (at 
> least partially) somebody else's problem to being mine and mine alone.
> 

Yes it's your problem but only on a best-effort basis.

Many issues detected by automatic analyzers can be fixed with automatic 
code transformation tools. This kind of solution works tree-wide, so even 
if some defect in your driver is "yours and yours alone", the solution 
will probably come from others.

This email, like yours, is just hand-waving. So feel free to ignore it or 
(preferably) provide evidence of real defects.

Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver

[Finn Thain]

On Tue, 16 Jun 2020, Bart Van Assche wrote:

> 
> As far as I know the sbp driver only has had one user ever and that user 
> is no longer user the sbp driver.

So, you estimate the userbase at zero. Can you give a confidence level? 
Actual measurement is hard because when end users encounter breakage, they 
look for quick workarounds before they undertake post mortem, log 
collection, bug reporting, mailing list discussions, analysis etc.

> So why to keep it in the kernel tree?

Answer: for the same reason it was added to the tree.

Here's a different question: "Why remove it from the kernel tree?"

If maintaining this code is a burden, is it not the kind of tax that all 
developers/users pay to all developers/users? Does this driver impose an 
unreasonably high burden for some reason?

The growth of a maintenance burden in general has lead to the invention of 
design patterns and tooling to minize it. So a good argument for removal 
would describe the nature of the problem, because some driver deficiencies 
can be fixed automatically, and some tooling deficiencies can compound an 
otherwise insignificant or common driver deficiency.

There are spin-off benefits from legacy code besides process improvements. 
Building and testing this sort of code has regularly revealed erroneous 
corner cases in commits elsewhere like API changes and refactoring.

Also, legacy code is used by new developers get experience in code 
modernization. And it provides more training material for neural networks 
that need to be taught to recognize patches that raise quality.

Ten or twenty years ago, I doubt that anyone predicted these (and other) 
spin-off benefits. If we can't predict the benefit, how will we project 
the cost, and use that to justify deletion?

Please see also,
http://www.mac.linux-m68k.org/docs/obsolete.php

Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver

[Bart Van Assche]

On 6/16/20 7:07 PM, Finn Thain wrote:
> On Tue, 16 Jun 2020, Bart Van Assche wrote:
>> As far as I know the sbp driver only has had one user ever and that user 
>> is no longer user the sbp driver.
> 
> So, you estimate the userbase at zero. Can you give a confidence level? 
> Actual measurement is hard because when end users encounter breakage, they 
> look for quick workarounds before they undertake post mortem, log 
> collection, bug reporting, mailing list discussions, analysis etc.

(replying to an e-mail from six months ago)

Hi Finn,

I am confident that my estimate is an accurate estimate since I have not
seen any sbp support requests, sbp bug reports nor any sbp bug fixes since
the sbp target driver has been accepted upstream.

> Here's a different question: "Why remove it from the kernel tree?"
> 
> If maintaining this code is a burden, is it not the kind of tax that all 
> developers/users pay to all developers/users? Does this driver impose an 
> unreasonably high burden for some reason?

Yes. If anyone wants to change the interface between SCSI target core and
SCSI target drivers, all target drivers, including the sbp and FCoE target
driver have to be retested. In other words, keeping unused target drivers
inside the kernel tree involves a significant maintenance burden for anyone
who wants to modify the interface between the SCSI target core and SCSI
target drivers.

Additionally, there is a good alternative available for the sbp driver.
Every system I know of that is equipped with a Firewire port also has an
Ethernet port. So users who want to provide SCSI target functionality on
such systems can use any SCSI transport protocol that is compatible with
Ethernet (iSCSI, iSER over soft-RoCE, SRP over soft-RoCE, ...).

Thanks,

Bart.

Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver

[Finn Thain]

On Mon, 4 Jan 2021, Bart Van Assche wrote:

> On 6/16/20 7:07 PM, Finn Thain wrote:
> > On Tue, 16 Jun 2020, Bart Van Assche wrote:
> >> As far as I know the sbp driver only has had one user ever and that 
> >> user is no longer user the sbp driver.
> > 
> > So, you estimate the userbase at zero. Can you give a confidence 
> > level? Actual measurement is hard because when end users encounter 
> > breakage, they look for quick workarounds before they undertake post 
> > mortem, log collection, bug reporting, mailing list discussions, 
> > analysis etc.
> 
> (replying to an e-mail from six months ago)
> 
> Hi Finn,
> 
> I am confident that my estimate is an accurate estimate since I have not 
> seen any sbp support requests, sbp bug reports nor any sbp bug fixes 
> since the sbp target driver has been accepted upstream.
> 

That suggests to me that the code that you're hoping to remove 1) has no 
bugs, or 2) has no reported bugs, or 3) has no users at present.

I am confident that your evidence does not support your conclusion (i.e. 
the code will never be used again).

Sometimes, users only appear after the unreported bugs get fixed. I've 
seen it happen.

> > Here's a different question: "Why remove it from the kernel tree?"
> > 
> > If maintaining this code is a burden, is it not the kind of tax that 
> > all developers/users pay to all developers/users? Does this driver 
> > impose an unreasonably high burden for some reason?
> 
> Yes. If anyone wants to change the interface between SCSI target core 
> and SCSI target drivers, all target drivers, including the sbp and FCoE 
> target driver have to be retested.

I'm unaware of such an obligation. API changes happen often. When they do, 
we see good test coverage of commercially viable hardware, some 
best-effort testing of common hardware, and some perfunctory build 
testing.

But that is missing the point, which was about a particular driver, not 
about development process. You have not shown how the target API is 
special, to support your claim that this driver imposes an unreasonable 
burden.

In the interests of making forward progress in this discussion, shall we 
discuss the kind of SCSI Target API changes that you anticipate?

> In other words, keeping unused target drivers inside the kernel tree 
> involves a significant maintenance burden for anyone who wants to modify 
> the interface between the SCSI target core and SCSI target drivers.
> 

Keeping _any_ driver in the kernel involves a maintenance burden. There 
are two good ways to address that.

Firstly, by improving the development process. For example, an API change 
is mostly mechanical work that lends itself to automated refactoring.
Secondly, by involving all interested parties, so that the burden is 
shared.

Of course, there are other ways. E.g. "don't ship code when doing so won't 
turn a profit". That, by the way, was the policy that gave us 10 billion 
Android devices (or more) that don't function with a mainline kernel.

> Additionally, there is a good alternative available for the sbp driver. 
> Every system I know of that is equipped with a Firewire port also has an 
> Ethernet port. So users who want to provide SCSI target functionality on 
> such systems can use any SCSI transport protocol that is compatible with 
> Ethernet (iSCSI, iSER over soft-RoCE, SRP over soft-RoCE, ...).
> 

Ethernet is not always an alternative. That was already discussed in this 
thread. But let's assume for a moment that you can migrate any and all 
users of this driver over to an ethernet driver.

Why would the maintainers of that ethernet driver and its API accept that 
plan, if adding users would extend their maintenance and testing 
obligations? Do you think those maintainers should pay the "kind of tax 
that all developers/users pay to all developers/users?"

> Thanks,
> 
> Bart.
> 

Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver

[Bart Van Assche]

On 1/4/21 2:50 PM, Finn Thain wrote:
> On Mon, 4 Jan 2021, Bart Van Assche wrote:
>> Additionally, there is a good alternative available for the sbp driver. 
>> Every system I know of that is equipped with a Firewire port also has an 
>> Ethernet port. So users who want to provide SCSI target functionality on 
>> such systems can use any SCSI transport protocol that is compatible with 
>> Ethernet (iSCSI, iSER over soft-RoCE, SRP over soft-RoCE, ...).
> 
> Ethernet is not always an alternative. That was already discussed in this 
> thread. But let's assume for a moment that you can migrate any and all 
> users of this driver over to an ethernet driver.
> 
> Why would the maintainers of that Ethernet driver and its API accept that 
> plan, if adding users would extend their maintenance and testing 
> obligations? Do you think those maintainers should pay the "kind of tax 
> that all developers/users pay to all developers/users?"

Hi Finn,

I cannot speak in the name of the iSCSI over TCP/IP or iSER driver
maintainers. But since I maintain the SRP initiator and target kernel
drivers myself, I can state that I would be happy to help SBP target users
(if that driver has any users today) to switch from SCSI over Firewire to
SCSI over SRP over RoCE or even NVMEoF over TCP.

Thanks,

Bart.

Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver

[Martin K. Petersen]

Finn,

> I haven't used this driver for a long time, but I still own PowerMacs
> with firewire, and I know I'm not the only one.

I also have old 1394 hardware kicking around in the basement. But having
worked with FireWire shared storage targets in the past, I have zero
desire to ever touch any of that again.

I could understand an objection if we were to entertain removing
sbp2. But really, how many people are setting up FireWire targets?

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver

[Finn Thain]

On Tue, 16 Jun 2020, Martin K. Petersen wrote:

> > I haven't used this driver for a long time, but I still own PowerMacs 
> > with firewire, and I know I'm not the only one.
> 

I need to correct what I wrote above. I recall that years ago, when I 
needed to share storage from my Linux box to my PowerBook pismo, I used 
ethernet and the globalSAN iSCSI initiator for Mac OS X (which is no 
longer freely available AFAICS). When I said that I had used the SBP 
target driver before, I misremembered that iSCSI target setup. I've 
actually never used the SBP target driver.

> I also have old 1394 hardware kicking around in the basement. But having 
> worked with FireWire shared storage targets in the past, I have zero 
> desire to ever touch any of that again.
> 
> I could understand an objection if we were to entertain removing sbp2. 
> But really, how many people are setting up FireWire targets?
> 

It's a good question. I don't know the answer.

I have successfully used the Linux sbp2 host driver in the past, and will 
probably need to use it again. Likewise, I can see myself using the sbp 
target driver in the future because that might interoperate with MacOS 9, 
and might provide a bootable device to the PowerMac ROM. iSCSI cannot do 
those things.