Re: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux