----- Original Message -----
From: "Torben Mathiasen" <[EMAIL PROTECTED]>
To: "Eric Youngdale" <[EMAIL PROTECTED]>
Cc: "Douglas Gilbert" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, January 08, 2001 6:58 PM
Subject: Re: [PATCH, RFC] SCSI cleanups for 2.5
> On Mon, Jan 08 2001, Eric Youngdale wrote:
> > 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).
Exactly.
> > 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.
He is.
> > 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?
Some changes cannot be avoided. I think the point is that we need to
keep in mind that we should avoid making gratuitous changes that would force
modifications to low-level drivers. If there is a good reason for the
change, then by all means we can go ahead.
Stratification by chipset could clean things up quite a bit, especially
for common chipsets. Consider the NCR5380, which is evidently used by about
8 or so low-level drivers, and there are common sources and include files
which are used by all of these. All related files could be moved to a
single subdirectory. There are instances where other drivers use a
proprietary chipset which would only be used for a single manufacturer - for
these I am not so sure if a single directory per manufacturer is really
needed. This isn't a change that needs to be done all at once, of course.
For example, a starting point would be to create the directory tree, and get
the makefile and configuration stuff set up. Then the upper level stuff
could be moved in one patchset. The NCR5380 stuff could be moved in
another. Etc, etc.
-Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
