The Linux Kernel's SCSI Subsystem - page 2
Introducing the Linux Kernel's SCSI Subsystem
Some of the Linux SCSI subsystem's bad reputation comes from legacy kernel issues. Way back when, there were a number of features that the SCSI subsystem required that weren't built into the kernel already, and so a lot of supporting structure had to be built within the subsystem rather than being farmed into the core kernel, or additional modules.
More subsystems began to need these features and so the kernel itself adopted many of them. However, the SCSI subsystem went through a series of primary maintainers, who no doubt spent much of their time getting up to speed on where everything stood before they found themselves having to move on due to lack of time or other issues. Not only that, but these maintainers were also busy trying to add new functionality to the subsystem and keeping it working with the current course of kernel development.
Once a longer-term maintainer took over the SCSI subsystem there was finally a chance to start a real strategy of removing the unneeded bulk. This problem has already been partially addressed in the 2.4.x kernel series, and more has been done for the 2.5.x series, but even when 2.6.x comes out there will still be more to do in this area.
There's just too many other issues to deal with as well, and of course if you deal with computers, you know that removing a piece of code that's "just harmlessly duplicating another function somewhere" often doesn't always prove to be harmless.
There is also a lot of redundancy left over in the Linux kernel SCSI subsystem's command structure itself, such as fields in one portion of the command structure that don't exist in others, because items that were phased out never fully got removed.
Another area that the SCSI team hears a lot about is queuing. Many programmers apparently believe that the SCSI subsystem handles its own queuing internally, and that this is an area that requires work, but in fact this is not the case.
Perhaps the biggest myth is that the entire Linux kernel SCSI subsystem needs to be rewritten. This is not entirely true. Rewriting small sections, and incrementally merging and changing parts until all of the problems are finally fixed can deal with most of the issues.
- 1Linux Top 3: Fedora 24, Peppermint 7 and Solus 1.2
- 2Linux Top 3: Alpine Linux 3.4, deepin 15.2 and Linux Lite 3.0
- 3Linux 4.7 Set to Boost Live Patching, Security and Power Management
- 4Linux 4.6 Charred Weasel adds USB 3.1 Support
- 5Linux Top 3: OpenIndiana 2016.04, Ubuntu 16.04 and Debian's New Leader