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

[Kyle Moffett <mrmacman_g4@mac.com>]

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


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/