On Mon, 8 Jan 2001, Eric Youngdale wrote:
>
> > > > 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
further proposals:
- broaden ID and LUN to 64bit to follow SCSI-3 (or associated interfaces,
such as FCP)
- enhance scsi_scan.c to make use of REPORT LUNS (useful for large but
sparsely populated LUN address spaces (i.e. 64bit FCP_LUN)
- remove the LUN < 8 restriction from scsi_scan.c finally
(only valid for parallel SCSI but not i.e. for FCP ;)
max. SCSI LUN should be provided by the HBA
drivers - as it is currently - and respected by scsi_scan.c - as it is not
currently)
If you have concerns regarding items above in comparison to existing code
(mostly following the parallel interface) then we should think about
restructering the code according to physical interfaces instead of (or
additionally to) chip sets, though.
- Is there an "official" interface for devices seen by the HBA
driver becoming available after scan_scsis? (I do not mean
add-single-device done from user land but something triggered by the HBA
driver)
- What is about multiple paths support? (Yes, should be useful for FCP, as
well) There is a project which made such patch for Sun T3 support
(http://open-projects.linuxcare.com/t3/)
Maybe that would be a starting point, even if I do not like their
configuration via sg device nodes (could be changed to proc-fs, I think),
the predefined order of alternate paths, missing load balancing ...
- Fix host enumeration regarding naming of SCSI devices in devfs' name
space to something more reconfiguration proof (scheme following physical
addresses, like subsequent bus, id, lun)
-alternately to previous approach:
enhance scsihosts parameter from
scsihosts=<driver A>,<driver A>,<driver B>,driver<A>
to
scsihosts=<driver A>(<host q>,<host k>),<driver B>,<driver A>(<host m>)
This would allow to specify the order of hosts within the scope of a
single HBA driver. Currently it depends on the order of detection and
registration of HBAs at module or kernel initialization. But, what is
about hosts being unavailable at this time sometimes and becoming
operational later? If HBA drivers would pass an unique identifier for each
detected host (let's assume unique_id) additionally to scsi_register, then
the mid layer could match this against identifiers known from the
scsihosts parameter and put the host into the predefined position.
Regards
Martin Peschke
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
