Re: [patch 0/3] clean gendisk out of scsi ULD structs

[James Bottomley <James.Bottomley@SteelEye.com>]

On Fri, 2007-07-06 at 23:25 -0400, Douglas Gilbert wrote:
> James Bottomley wrote:
> > On Thu, 2007-07-05 at 14:06 -0700, Kristen Carlson Accardi wrote:
> >> Since gendisk will now become part of struct scsi_device, we don't need
> >> to store this value in any private data structs where they already store
> >> scsi_device.  This series cleans up a few drivers which did this.
> > 
> > Actually, as Al pointed out, we do have lifetime rules issues with doing
> > this.  The problem is that gendisk itself always has a shorter lifetime
> > than scsi_device (not much shorter, usually, but if you execute a legal
> > ULD unbind manoeuvre you'll end up with a dangling gendisk pointer).
> 
> What about having short-lived scsi_device objects? For example:
> one that lives long enough for a pass-through to send a
> SCSI command (and receive its response) to one of a target's
> well known logical units.

This is sort of what we already do for REPORT_LUNS (except that we use
lun 0 instead of the REPORT LUN well known lun).  What additions do you
want to see?

> > The other problem with taking gendisk out of the ULD structure and
> > putting it into the scsi_device is that for the sg driver, we have two
> > of them (one for the attached ULD and one for the sg driver).
> 
> Add the bsg driver and that would make three of them. Or; if
> the lu's peripheral device type was not of interest to sd, st,
> sr, and osst; back to two gendisk objects (i.e. one each
> for sg and bsg).

gendisk is actually used to facilitate the SCSI ULD infrastructure; bsg,
being block, doesn't actually use it, so we'd still only have two.

> > The fundamental issue seems to be that the gendisk is the holder of all
> > the other info (queue, ULD etc) not vice versa ... and this patch is
> > trying to reverse that relationship.
> 
> A minor issue is the name gendisk ... unless, of course,
> you go and look at its definition in linux/genhd.h in
> which case the name looks somewhat appropriate. It looks
> like a mess [queue, ULD name, major/minor(s), partitions,
> capacity, disk_stats, kobjects, etc]. That is a considerable
> amount of superfluous information for "just a tag for
> requests coming into (a) given queue" when that queue leads
> to a non-block device.

The benefits outweigh the costs ... in the same way that we have a block
queue above all the character devices so we can treat SCSI queueing in a
uniform fashion regardless of device.

James