> > > The functionality of these funtions doesn't seem obvious after we got
> > > rid of scsi_dev_init & friends. This patch renames/moves them to:
> > >
> > > scsi_register_host | register a low-level driver
> > > scsi_unregister_host | unregister a low-level driver
> > >
> > > scsi_add_host | Add an identified low-level driver
> > > scsi_remove_host | Remove an identified low-level driver
> > >
> > > scsi_register_device | register a device driver
> > > scsi_unregister_device | unregister a device driver
> >
> > This use of "device" for sd, sr, st and sg I find
> > very confusing. In most other situations in the
> > scsi subsystem, "device" is uniquely identified by
> > <scsi_host, bus, target, lun>.
> >
> > I would prefer something like scsi_register_upper().
> >
>
> Yes I agree. Maybe we even should change the whole "devicelist"
> definiton to use "upper" in some way or another.
>
> > > scsi_add_device | Add an identified device to the system.
> >
> > Yes, similar functionality to:
> > echo "scsi add-single-device <h> <b> <t> <l>" > /dev/scsi/scsi
> >
> > so how about a scsi_remove_device() for the complementary
> > "remove-single-device" functionality. Could be useful when
> > hot unplugging.
> >
>
> Sounds reasonable.
> Actually scsi_add_device just adds this Scsi_Device_Template to the
> global scsi_devicelist. It may just as well be part of
> scsi_register_upper. scsi_add_device/scsi_remove_device could then be
> the complementary to using proc for adding devices as you suggests.
>
> >
> > While on the subject of documentation this comment in
> > scsi_module.c is incorrect for lk 2.4 and should be
> > changed. It currently reads:
> >
> > > * To use, the host adapter should first define and initialize the
variable
> > > * driver_template (datatype Scsi_Host_Template), and then include this
file.
> > > * This should also be wrapped in a #ifdef MODULE/#endif.
> >
> > The include of this ".c" (?) file should _not_ be
> > wrapped in #ifdef MODULE/#endif and that
> > Scsi_Host_Template definition should be now
> > be static.
> >
>
> True. I haven't even started to go through the comments yet. This is
> definitely something that should be done in parallel to the
> documentation.
>
> I would really like Eric's approval for this, just to make sure none
> of us does unneeded work. If its ok, I'll start to collect bits and pieces
> from people that is 2.5 stuff. That way we have something to start
> 2.5 on.
> I'll start to implement the above, also converting the host drivers
> (minor changes, purely cosmetical).
Some of these cleanups seem harmless, at least on the surface. As far
as I can tell, there isn't any functional change, it is mainly renaming
functions to be more consistent with current usage.
Splitting up scsi.c is also an ongoing project of mine, and splitting it
by groups of functionality is the approach I have been taking. The changes
to split out the request and command processing seem reasonable.
The one thing that I would caution however is that many low-level driver
maintainers attempt to provide support for a number of different kernel
revisions from the same source tree. Changes to interfaces that might be
described as "gratuitous" could serve to annoy, as this would result in more
spaghetti code with #if directives to select kernel versions. I am
wondering whether we should consider leaving hosts.h for this reason.
Similarily, renaming scsi_register() to scsi_add_host() might be viewed as
sufficiently trivial that it would be more of an annoyance than a help.
Due to the fact that there are far fewer upper level drivers, changes
which do not affect low-level drivers don't bother me as much. I believe
that Doug is the only upper level driver maintainer attempting to maintain
for multiple kernel versions, so as long as he is happy, I don't have a
problem :-).
I have been awfully busy with my new house, and I haven't had a chance
to pull a kernel tree in a while to see what has been going on. Once 2.5
gets started, I hope to start digging into things again and start doing some
major surgery. Things on my agenda include:
1) Elimination of scsi_obsolete.c - this will break compilation for
low-level drivers that have not been converted to new error handling. Tough
noogies. The time has come to bury this corpse.
2) I would like to eliminate the usage of io_request_lock from all
low-level drivers (actually io_request_lock could be eliminated entirely in
favor of finer grained locks). This could imply surgery on all low-level
drivers. This could conceivably also be done with wrapper functions in
scsi_module.c, but this wouldn't be as clean.
3) We need to clean up the block device layer and get rid of those
arrays indexed by major/minor. This would imply major surgery on all block
device drivers, at least at some point. This could be done in two stages -
a set of lightweight API functions could be added to the block device layer
so that everything above it (i.e. filesystems) would no longer directly
reference those silly arrays. The second stage of this process would be to
eliminate the arrays completely - I am thinking that ultimately the
low-level drivers themselves could expose functions that could be called to
determine device size, etc., and these could be called through the API
functions in the block device layer.
4) I would like to eliminate use of scsi_do_cmd() outside of the SCSI
core - I believe the gdth driver is now the only thing left which uses this,
and if I hadn't gotten so busy we could have finished this in time for 2.4.
There are a few related functions which no longer need to be exposed outside
of the SCSI core module at the same time.
5) Consider restructuring the entire SCSI source tree to move core and
upper level drivers out to a new directory (or conversely to move the
low-level drivers to a stratified layer beneath drivers/scsi). One way or
another, mainly to improve organization - there are too many files all
jumbled together right now. My inclination would be to stratify low-level
drivers based upon chipset (bus type and/or CPU type don't make sense, as a
given chipset can be used in a number of different circumstances).
6) A little further out is the possiblity of adding some level of
support for CAM. Just a pipe dream at the moment. This would be major
surgery for just about any definition of major surgery :-). The disposition
of some of the items above would depend upon how serious of a prospect this
turns out to be (i.e. anything that affects low-level drivers
Once I get rolling on some of these, we will need to coordinate so that
we don't step all over each other's feet. I probably won't start any coding
until 2.5 is officially started, however.
-Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
