I am enclosing a patchset that contains all of my accumulated
changes against 2.3.42. Unfortunately this grew to be a lot larger than I
had hoped. Part of this is because Linus is dragging his butt in getting
a previous patchset integrated into the kernel, but a some of it is also
because I am trying to do about a dozen different things all at the same
time. Given that I have the thing under CVS, it gets to be a huge
nuisance for me to generate diffs against the vendor branch and exclude
different things. The main thing I wanted to do was to get a few people
to test it and make sure that I didn't break anything.
Anyways, here is what I am attempting to accomplish:
1) Includes an update to the generics driver to version 3. This
is from Doug with no changes from me. I have it under CVS, and the diffs
will keep turning up until Linus takes the thing. This only affects sg.c
and sg.h.
2) I finished elimination of scsi_init_malloc/scsi_init_free. These
were effectively just wrappers around kmalloc() or get_free_pages(), and
it just obscured things for people.
3) I have cleaned up scan_scsis a little more. In particular, I
believe this fixes the problem with host_active being modified for the wrong
device in some instances. The main idea here is that scan_scsis does less
custom hacking of the datastructures.
4) I cleaned out the remainder of the old host blocking logic, and
replaced it with API calls to stub functions that I will use when I finally
get around to re-implementing this feature.
5) I implemented the "smp_safe" flag that we discussed
earlier. The actual implementation was trivial and safe. The main point
of getting this in now is to enable driver authors to update their drivers
to stop using io_request_lock if they choose to.
6) Updated the verbose sense information from the latest SCSI drafts.
7) Provide initial support for a field in Scsi_Cmnd that indicates
dataflow direction. This can be used by low-level drivers to setup DMA, for
example. There are 4 values it can take:
SCSI_DATA_UNKNOWN Command issuer is too lazy.
SCSI_DATA_WRITE Write to device from memory.
SCSI_DATA_READ Read from device into memory.
SCSI_DATA_NONE No data transfer (i.e. no buffer).
as far as I know there are no commands that do both read and write. The only
place I know of that I have not updated to set the dataflow direction is the
generics and tape drivers. This is going to be a pain to debug, so drivers
that attempt to use this should keep in mind that at least initially the
values are not reliable.
8) I am providing the infrastructure for fixing a design flaw
in the new queueing code. The fundamental problem is that the
datatype Scsi_Cmnd is being used in upper level character device
drivers when they shouldn't. The Scsi_Cmnd datastructure implies a
command that is present and running on the device, whereas the new
Scsi_Request structure represents a sort of placeholder that is used
while a request waits until it has risen to the top of the queue. I
have updated *parts* of the upper level drivers to use this - mainly
just the CDROM support. I haven't touched generics or tapes yet. I
was able to mount a CDROM, so I couldn't have broken it too badly :-).
9) I added support for 3 API functions that Kurt Garloff and I were
talking about:
extern void scsi_unblock_requests(struct Scsi_Host * SHpnt);
extern void scsi_block_requests(struct Scsi_Host * SHpnt);
extern void scsi_report_bus_reset(struct Scsi_Host * SHpnt, int channel);
10) I have a fix in sd.c to inhibit attempts to spin up a device
when the device reports that there is no media. Matt Dharm asked for this
one because the spurious commands slow things down with USB.
11) Fixed the kernel configure so that the parameters for
EXTRA_DEV can be configured when you set up the kernel. Defaults are
same as before. It should have been configurable all along.
12) Fixed a problem whereby the error handler thread would count
against the load average.
13) Added hooks by which low-level drivers can state the maximum
length of SCSI command they can handle. Host adapters that can handle
16-byte commands can set this to 16. Default is 12. I still haven't
changed the array size for commands from 12 to 16, but the point in doing
this now is to enable low-level driver authors to state the maximum
command length they are prepared to handle. It would take me about 5
minutes to finish this.
There are still some todo issues:
1) Need to finish converting character device and ioctl code to
use Scsi_Request instead of Scsi_Cmnd. Clean out redundant code once
this is complete. I want to wait until the updated generics driver is
in the official kernel before starting on this. This shouldn't be
very hard.
2) Finish data direction stuff for generics and tape drivers.
Actually it would probably be better if Kai and Doug took on their
respective drivers, as it is harder for me to tell what the actual data
direction is in some cases.
3) Add code to test and enforce maximum command length, and bump the
#define used for the command array sizes to 16.
-Eric
"The world was a library, and its books were the stones, leaves,
brooks, grass, and the birds of the earth. We learned to do what only
a student of nature ever learns, and that was to feel beauty."
Chief Luther Standing Bear - Teton Sioux
linux42.diff.gz
