All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luben Tuikov <luben_tuikov@adaptec.com>
To: James Bottomley <James.Bottomley@SteelEye.com>
Cc: Jeff Garzik <jgarzik@pobox.com>, linux-scsi@vger.kernel.org
Subject: Re: [patch 0/6] marginalize HCIL a bit
Date: Mon, 24 Oct 2005 11:49:23 -0400	[thread overview]
Message-ID: <435D0283.40505@adaptec.com> (raw)
In-Reply-To: <1130081372.3437.33.camel@mulgrave>

On 10/23/05 11:29, James Bottomley wrote:
> There's an unaddressed lifetime problem in all of this:  Originally the
> target object exists solely internally and has its lifetime managed by
> the mid-layer (it actually exists only as long as there are LUNs on it).

And this has always been wrong and I objected to this back when it
was introduced a few years ago.

> In your code cleanups, you keep the scsi_target_reap() function (which
> is what checks the children and tries to destroy the device if it
> doesn't find any) private (well, unexported).  So, on return from your
> new scsi_scan_target(), the target pointer might be invalid (already
> freed) if you didn't take a reference to starget->dev.  That's counter
> to the way lifetime management of objects usually works.
> 
> I think the choices are
> 
> 1. Make the target an explicit object (like it's peers scsi_device and
> scsi_host), so the layer creating it is responsible for managing it.

Which is exactly what I've been proposing: struct scsi_domain_device { };
similarly to how it is done in the SAS Transport Layer/Stack in the link
of my signature.

The new struct scsi_domain_device { } would be a logial (not imposed)
superclass around the transport's domain device representation.
The Transport Layer _registers_ a struct scsi_domain_device { };
and then SCSI Core scans for LUs and does LU bookkeeping.

LUs -> SCSI Core
SCSI Domain Targets -> Transport Layer around its own domain device
representation:

struct scsi_domain_device {
	void *domain_device;    /* opaque to SCSI Core */
	
	struct list_head LU_list;
	...
};

All of this functionality and infrastructure is present in the
SAS Stack and could be taken almost as is.

> This will get tricky, particularly as we'd need at least lun removal
> notifications so the creating layer can decide on destruction.

LU management is SCSI Core's task -- you'll get notified if
the _domain_ device went away, so that you can clean up your LU
representation.

See for example sas_discover_event(struct sas_port *, enum discover_event ev)
for event DISCE_PORT_GONE handled in the discover thread.
sas_unregister_domain_devices() eventually bubbles up to SCSI Core,
and dynamically allocated are handled by their release method (kobject
infrastructure).

	Luben
-- 
http://linux.adaptec.com/sas/
http://www.adaptec.com/sas/

  reply	other threads:[~2005-10-24 15:49 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-23  1:36 [patch 0/6] marginalize HCIL a bit Jeff Garzik
2005-10-23  1:37 ` [patch 1/6] SCSI HCIL: s/scsi_scan_target/spi_scan_target/ Jeff Garzik
2005-10-23  1:38 ` [patch 2/6] SCSI HCIL: remove unused scsi_scan_single_target() Jeff Garzik
2005-10-23  1:53   ` Matthew Wilcox
2005-10-23  1:38 ` [patch 3/6] SCSI HCIL: add scsi_scan_target() Jeff Garzik
2005-10-23  1:50   ` Matthew Wilcox
2005-10-23  1:54     ` Jeff Garzik
2005-10-23  2:00       ` Matthew Wilcox
2005-10-23  2:42         ` Jeff Garzik
2005-10-23  2:26     ` Randy.Dunlap
2005-10-23  1:40 ` [patch 4/6] SCSI HCIL: kill all uses of spi_scan_target() Jeff Garzik
2005-10-23  1:56   ` Matthew Wilcox
2005-10-23  1:40 ` [patch 5/6] SCSI HCIL: kill spi_scan_target(), __spi_scan_target() Jeff Garzik
2005-10-23  1:41 ` [patch 6/6] SCSI HCIL: misc cleanups Jeff Garzik
2005-10-23  2:03   ` Matthew Wilcox
2005-10-23  1:45 ` [patch 0/6] marginalize HCIL a bit Jeff Garzik
2005-10-23 15:29 ` James Bottomley
2005-10-24 15:49   ` Luben Tuikov [this message]
2005-10-24 16:50     ` James Bottomley
2005-10-24 17:18       ` Luben Tuikov
2005-10-24 20:28         ` James Bottomley
2005-10-24 20:41           ` Luben Tuikov
2005-10-24 21:12             ` James Bottomley
2005-10-24 22:38               ` Luben Tuikov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=435D0283.40505@adaptec.com \
    --to=luben_tuikov@adaptec.com \
    --cc=James.Bottomley@SteelEye.com \
    --cc=jgarzik@pobox.com \
    --cc=linux-scsi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.