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

[Douglas Gilbert <dougg@torque.net>]

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.

> 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).

> 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.

Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/