> >>> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
|
|