On Mon, Jan 08 2001, Eric Youngdale wrote:
[deleted me talking]
> > 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.
>
Yes you are right. I hadn't thought about the low-level driver maintainers
supporting different kernel revisions. This is going to be a real pain
for a long time. This will basicly force us to support the 2.2
interface in one way or another. I know the funtion renaming is just
cosmetic, and probaly should be left out, but leaving hosts.h in the tree just
because the low-level drivers can't handle another LINUX_VERSION_CODE
check seems wrong. Most of low-level drivers are filled with them
anyway, so the spaghetti effect is already there. If we keep hosts.h
around, we'll just end up the the same situation as with the old error
handling code.
> 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 :-).
>
Doug seems very keen on removing the relationship between "device" and
the upper layers, so this should be ok.
> 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:
>
Sounds good!
> 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.
This will probaly also break the low-level drivers that support 2.2,
adding even more "if LINUX_VERSION....". No matter what, I don't think
we can change much without breaking something. Seems why it got
scheduled for 2.5 8).
> 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.
I might be wrong, but this seems to be something Jens Axboe is working
on.
> 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).
>
This is badly needed. And this change _will_ break most 2.2 compatible
drivers anyway. Organizing stuff into chipsets seems a bit too much,
but maybe into upper-layers, low-level and core?
> 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.
>
Ok. I'll continue the patch I posted yesterday; then we can use
whatever parts of it seems fit.
Have a nice day,
--
Torben Mathiasen <[EMAIL PROTECTED]>
Linux ThunderLAN maintainer
http://opensource.compaq.com
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
