> >>> 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. > Luben has more than once called for adding a small number of additional calls to the existing SCSI core. These calls would implement the new (reduced) functionallity. The old calls would continue to support the full SPI functionallity. No existing LLDD would need modification. Then, over time, more radical restructuring could be done that pulls SPI out of SCSI core. I believe this proposal is what he was talking about, not the brand new simplified SCSI core that has been discussed recently in this thread. Greg -- Greg Freemyer The Norcross Group Forensics for the 21st Century - : 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
