|
| |
This is my list of things to do to the linux SCSI subsystem.
Presented with some of the easier things first, but other than this no
particular order. Comments/additions welcome. Help in prioritizing this would
also be welcome (i.e. some of this stuff would be more useful than others. Some
of the simpler things are already in the works...

- Finish converting to use Scsi_Request. There are a few
places (generics) where the Scsi_Cmnd structures are still used, and there
is one driver (gdth) still using the Cmnd. Once this is completed, there is
some dead code to be removed.
- Clean up select queue depths interface - make this
per-device, not per bus. This solves the issue of add-single-device screwing
up other devices.
- Improve support for shared SCSI busses. Some code went into
2.2.nn to better support reservation conflicts, this needs to be reviewed
and brought forward. Someone suggested a "defensive" error
recovery mode to help reduce the possibility of reset wars.
- Clean up the GHOST stuff in the bus scanning code. The
current implementation is a bit of a hack. It could be more cleanly solved
by changing the device to writable, and then fixing sd.c so that it
recognizes TYPE_ROM + writable. Either that or we store the blacklist flags
in the device, and tell sd.c to also recognize GHOST devices.
- Find architecturally satisfactory way to implemenent host
blocking. This needs to work well with single_lun as well, as this is an
architectural cousin of host blocking.
- Fix to allow 16-byte commands. Groundwork is essentially
laid in the mid-level now. The problem is that some low-level drivers aren't
handling this well. Some may have hardcoded assumptions built into the
hardware (i.e. in the mailboxes) as to the maximum command length, and for
these cases the drivers themselves will need to be modified to reject these
commands. If the problems are prevalent enough, we may need to specify a
maximum command length in the host template.
- Add support for smp_safe flag as describe in scsi_eh.html.
This will allow low-level drivers to be weaned from io_request_lock. The
change to the mid-level is relatively safe/trivial, which will enable the
work in low-level drivers.
- Fix single_lun. A timer should be used so that perhaps 0.5
sec after the last access to a device, control is yielded to the next device
with pending commands.
- Look into and correct the issues related to
high-availability.
- Implement target mode. A number of people have good ideas
as to how this should work.
- Fix overallocation problem of Scsi_Cmnd structures. We
probably need one or two SCpnt structures per device, and then a generic
pool associated with the host itself which can be assigned to any device.
Major problem may well be that we have over-allocated DMA pool. That's
actually a lot easier to fix. That's just a thought.
- Add SMP safety to device add/remove. We are not protecting
the linked list insertion/removal with reader-writer locks. This is part of
the high-availability work.
- Clean up architectural issues related to
hot-plug/hot-removal of devices.
- Need to convert all drivers to use new error handling, smp
safety.
- Fix offline condition to make it possible to clear
condition and or unmount media.
- Possibly provide hooks to allow sg driver to issue device
reset. Bus reset - ick. I am not entirely wild about this possiblity. Doug
has asked for this, I am not wild about it.
- Try and eliminate DMA pool - keep a small emergency pool on
hand, but use normal kernel DMA pool with GFP_ATOMIC. Need to verify that
this will not force swapping if the pool is exhausted.
- Rearrange source tree. Move scsi core up a level, sort of
like the way the net tree is set up. Need to divide up low-level drivers in
some logical grouping as well. I am not sure what makes the most sense for
low-level drivers - some of them drive multiple bus types, I am thinking
that chipset manufacturer might be good.
- Get rid of SR_EXTRA, SD_EXTRA. To do this we need to start
by Fix layering violations in ll_rw_blk. Reader-writer locks will work well
for this for protecting the datastructures. Once this is done, it will be
just a little bit harder than it was for SG, ST.
- Add support for raw device access to disks. Probably not
worthwhile for cdrom. Essentially just character device support. Bypass
buffer cache, filesystem, etc.
- Re-examine the lun scan code. It has been suggested that we
do an INQUIRY first, and if this succeds then we scan each and every lun for
the associated device to test for an active LUN. Something along those
lines.

Things fixed as of 2.3.99
- Add method of marking command data flow direction for
commands that need it. Needs to be tri-state (in/out/none). This is going to
affect the generics driver too.
- Get rid of SG_EXTRA, ST_EXTRA - resize on the fly. Use
reader-writer locks for this to protect data structures. The main challenge
is that we probably want to change the datastructures a bit so that instead
of using something like
struct scsi_foo * scsi_foos;
and then referencing it with:
scsi_foos[MINOR(dev)].field;
we would instead use:
struct scsi_foo ** scsi_foos;
and reference it like:
scsi_foos[MINOR(dev)]->field;
Thus if the datastructures are resized as devices are added
or removed, the individual structures wouldn't change address - it is just
the lookup table that would move.

Things fixed as of 2.3.40
- Fix problem where the scsi error handler thread is counted
as active, and thus throws off the load average.
- Get rid of scsi_init_malloc/free. Replace with kmalloc/__get_free_pages,
as appropriate. Trivial replacement, fairly safe.
- Allow EXTRA stuff to be configurable during kernel config.
Trivial change, and a temporary measure until we are able to eliminate them.
- Fix select_queue_depths - add this to the host template.
Tough noogies for people who don't do their host templates the right way.
Things fixed as of 2.3.39
- Phase out some instances of scsi_do_cmd in favor of
scsi_wait_cmd. Get rid of sd_wait_cmd in favor of scsi_wait_cmd (essentially
identical).
- Add generic Scsi_Device that points to the HA itself. Add a
single command block. For the moment, don't attach it to any high level
drivers - generics would be the only thing which would make sense. Initially
this is just a transient device that doesn't appear in the linked lists and
is deleted when the user is done with it.

If you have comments or suggestions, you
can email me by clicking here
All
discussions, bug reports, etc, should either be reported directly to me, or to
linux-scsi.
Last updated: 5/15/00.
|