From: Mike Christie <mikenc@us.ibm.com>
To: James Bottomley <James.Bottomley@SteelEye.com>
Cc: SCSI Mailing List <linux-scsi@vger.kernel.org>
Subject: Re: [RFC] exposing the sdev_target in sysfs
Date: Fri, 03 Sep 2004 21:48:01 -0700 [thread overview]
Message-ID: <41394901.3050804@us.ibm.com> (raw)
In-Reply-To: <1094254851.1712.28.camel@mulgrave>
James Bottomley wrote:
> The aim of this patch is to give us somewhere to hang the per target
> timer that emulex needs.
>
> However, it will break the current sysfs layout. devices will now
> appear something like this:
>
> lrwxrwxrwx 1 root root 0 Sep 3 18:31
> /sys/class/scsi_device/0:0:5:0/device ->
> ../../../devices/parisc8/parisc8:0/pci0000:00/0000:00:13.0/host0/target0:0:5/0:0:5:0
>
> (note the extra target0:0:5 in there).
>
> which may break some of the user land tools (although you're all using
> the scsi class interface to access your devices, aren't you? in which
> case you won't notice any problems).
>
> Comments welcome.
>
> James
Hi James,
One tiny problem below.
> +int scsi_sysfs_target_initialize(struct scsi_device *sdev)
> +{
> + struct scsi_target *starget = NULL;
> + struct scsi_device *sdev_sibling;
> + unsigned long flags;
> +
> + spin_lock_irqsave(sdev->host->host_lock, flags);
> + /*
> + * Search for an existing target for this sdev.
> + */
> + list_for_each_entry(sdev_sibling, &sdev->same_target_siblings,
> + same_target_siblings) {
> + if (sdev_sibling->sdev_gendev.parent != NULL) {
> + starget = scsi_target(sdev_sibling);
> + break;
> + }
> + }
> + if (!starget) {
> + struct device *dev;
> + int error;
> +
> + starget = kmalloc(sizeof(*starget), GFP_ATOMIC);
> + if (!starget) {
> + printk(KERN_ERR "%s: allocation failure\n", __FUNCTION__);
> + spin_unlock_irqrestore(sdev->host->host_lock,
> + flags);
> + return -ENOMEM;
> + }
> + memset(starget, 0, sizeof(*starget));
> + dev = &starget->dev;
> + device_initialize(dev);
> + dev->parent = &sdev->host->shost_gendev;
> + dev->bus = &scsi_bus_type;
> + dev->release = scsi_target_dev_release;
> + sprintf(dev->bus_id, "target%d:%d:%d",
> + sdev->host->host_no, sdev->channel, sdev->id);
> + if ((error = device_add(dev))) {
device_add calls kobject_add which can sleep.
> + spin_unlock_irqrestore(sdev->host->host_lock, flags);
> + printk(KERN_ERR "Target device_add failed\n");
> + return error;
> + }
> + }
> + get_device(&starget->dev);
> + sdev->sdev_gendev.parent = &starget->dev;
> + spin_unlock_irqrestore(sdev->host->host_lock, flags);
> return 0;
> }
>
>
next prev parent reply other threads:[~2004-09-04 4:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-03 23:40 [RFC] exposing the sdev_target in sysfs James Bottomley
2004-09-04 4:48 ` Mike Christie [this message]
2004-09-04 13:54 ` James Bottomley
2004-09-06 1:58 ` Matthew Wilcox
2004-09-06 2:05 ` James Bottomley
2004-09-04 7:24 ` Olaf Hering
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=41394901.3050804@us.ibm.com \
--to=mikenc@us.ibm.com \
--cc=James.Bottomley@SteelEye.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.