On Sep 30, 2005, at 15:08:15, Luben Tuikov wrote:
On 09/30/05 14:50, Kyle Moffett wrote:
On Sep 30, 2005, at 14:34:42, Luben Tuikov wrote:
This is how we have the SPI-centric EH methods in the scsi host
template right now:
int (* eh_abort_handler)(struct scsi_cmnd *);
int (* eh_device_reset_handler)(struct scsi_cmnd *);
int (* eh_bus_reset_handler)(struct scsi_cmnd *);
int (* eh_host_reset_handler)(struct scsi_cmnd *);
So submit patches to fix it! You clearly understand what is
wrong, so why not help change it?
Because
- I do not want to give heart attack to all existing LLDDs
Significance of change is not an issue, assuming the change is broken
up into a collection of small obvious changes as highlighted in
Documentation/SubmittingPatches
- Some LLDD would never be able to be changed
Why not? It's easy to change APIs, even stuff as invasive as the VM,
the device driver model, etc, and those get changed all the time.
- Some LLDD work on very _scarce_ hardware which we cannot test.
You don't have to worry all that much about testing. If your patches
are small and obviously correct (like they should be), then they will
get enough review during submission that there will only be a very
small number of bugs. The few remaining bugs will probably be ironed
out in -mm. In any case, if nobody uses hardware anymore, eventually
the driver will get sufficiently crufty and out of date that it will
be recognized as such and removed.
- plus such radical changes are neither warranted nor necessary.
Jeff Garzik et. al. seem to think that they are necessary, and I
agree. You don't need to fork SCSI-core; doing so would just double
the maintainer load, and _that_ is neither warranted nor necessary.
It is better to keep legacy around, until all you'll have on your
new serverboard is a SAS/SATA storage chip such as AIC-94xx or say
BCM8603. Then you can compile out most of the legacy stuff.
Precisely. When nobody uses the legacy drivers to the point that
they aren't fixed or maintained anymore because no-one reports bugs,
then said drivers can be removed from the kernel entirely, along with
any support code. The model I describe here works better because it
keeps a _single_ clean core subsystem, and leaves any lack-of-
maintenance crap in the old drivers.
I think not breaking anything (for now at least) would be the
_easiest_ and most painless way to transition.
Until somebody wants to add a new high-level SCSI feature that works
for both the new and the old devices. Then they have to do it _twice_.
The way we do this is we slowly, without disruption to older
drivers introduce, in parallel, emerge a new, simpler, slimmer,
faster SCSI Core, whereby we accommodate new infrastructures,
yet, have 100% backward compatibility, via the current older SCSI
Core. After all, both would be a bunch of functions in a bunch of
files.
Except this introduces bloat and multiplies maintainer load. Fix the
existing one. If it breaks other in-core drivers, fix those to
Well, not necessarily. It would be more painful and more
maintainer load if we did what you suggest. The overhead would be
enormous.
So you're saying fixing the current SCSI subsystem once *now* costs
more than applying all *future* SCSI fixes to _two_ SCSI subsystems,
handling bug reports for _two_ SCSI subsystems, etc.
s/Politics.*//g; I hate politics. Keep it off this list.
Me too, but we are idealists. Politics is an integral part of life.
Politics are not an integral part of productive technical
discussions, though. If you discuss technical topics and provide
realistic technical descriptions, examples, reasons, code, etc, then
politics tends not to matter in the discussion, and we're all happier
people.
Cheers,
Kyle Moffett
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$ L++++(+
++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+ PGP+++ t+(+
++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r !y?(-)
------END GEEK CODE BLOCK------
-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
