All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@SteelEye.com>
To: FUJITA Tomonori <tomof@acm.org>
Cc: jens.axboe@oracle.com, fujita.tomonori@lab.ntt.co.jp,
	akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
	linux-scsi@vger.kernel.org
Subject: Re: block/bsg.c
Date: Wed, 18 Jul 2007 08:54:14 -0500	[thread overview]
Message-ID: <1184766854.3464.4.camel@localhost.localdomain> (raw)
In-Reply-To: <20070718092130V.tomof@acm.org>

On Wed, 2007-07-18 at 09:20 +0900, FUJITA Tomonori wrote:
> From: James Bottomley <James.Bottomley@SteelEye.com>
> Subject: Re: block/bsg.c
> Date: Tue, 17 Jul 2007 13:53:54 -0500
> 
> > On Tue, 2007-07-17 at 12:19 +0200, Jens Axboe wrote:
> > > > > Since Linus is happily snoring by now, could you test and see if the
> > > > > tree works for you?
> > > > 
> > > > It works for me. I'll submit some minor patches against your bsg
> > > > branch to scsi-ml. Can you push them together?
> > > 
> > > Certainly, I'll pull them into the bsg branch.
> > 
> > While you're at it, here's a patch to separate BSG and SCSI again (so
> > SCSI can be built modular).  The way I did it was simply to move the
> > SCSI specific logic into SCSI.  When you come up with a generic way to
> > register the bsg requiring drivers, then we can move it out again.
> 
> Thanks, looks nice.

You're welcome ... although there's still a problem for modular builds.
This is what my /sys/class/bsg looks like:

So you see the if (rq->kobj.parent) is causing confusing naming.  The
reason the first one shows up as 0:0:0:0 is because in an initrd
scsi_mod is loaded first (which is when bsg binds) followed by sd_mod
(which is what gives the device the ULD binding and hence the name).  I
don't see any way around this, so I'd advocate simply using the sdev
name rather than the block device name and dumping the if.

> > --- a/drivers/scsi/scsi_sysfs.c
> > +++ b/drivers/scsi/scsi_sysfs.c
> > @@ -714,6 +714,7 @@ static int attr_add(struct device *dev, struct device_attribute *attr)
> >  int scsi_sysfs_add_sdev(struct scsi_device *sdev)
> >  {
> >  	int error, i;
> > +	struct request_queue *rq = sdev->request_queue;
> >  
> >  	if ((error = scsi_device_set_state(sdev, SDEV_RUNNING)) != 0)
> >  		return error;
> > @@ -733,6 +734,16 @@ int scsi_sysfs_add_sdev(struct scsi_device *sdev)
> >  	/* take a reference for the sdev_classdev; this is
> >  	 * released by the sdev_class .release */
> >  	get_device(&sdev->sdev_gendev);
> > +
> > +	if (rq->kobj.parent)
> > +		error = bsg_register_queue(rq, kobject_name(rq->kobj.parent));
> > +	else
> > +		error = bsg_register_queue(rq, kobject_name(&sdev->sdev_gendev.kobj));
> > +	if (error) {
> > +		sdev_printk(KERN_INFO, sdev, "Failed to register bsg queue\n");
> > +		goto out;
> 
> Needs more cleanup here?

No ... this bit's magic and clever.  Once you've set up the devices and
done a get_device, cleanup is simply doing a put_device because it's all
done in the release routine.

> We might just ignore the error here since it's not fatal not to create
> a bsg device, I guess.
> 
> I updated the patch against the latest code (which has just be merged
> to Linus's tree).

Thanks,

James



  reply	other threads:[~2007-07-18 13:54 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-16 23:57 block/bsg.c Andrew Morton
2007-07-17  0:47 ` block/bsg.c Jeff Garzik
2007-07-17  0:53   ` block/bsg.c Andrew Morton
2007-07-17  0:58     ` block/bsg.c Jeff Garzik
2007-07-17  1:09       ` block/bsg.c Andrew Morton
2007-07-17  1:12         ` block/bsg.c Jeff Garzik
2007-07-17  1:47         ` block/bsg.c Jeff Garzik
2007-07-17  1:47           ` block/bsg.c Jeff Garzik
2007-07-17  3:00           ` block/bsg.c Jeremy Fitzhardinge
2007-07-17  3:00             ` block/bsg.c Jeremy Fitzhardinge
2007-07-17  3:03           ` block/bsg.c Andrew Morton
2007-07-17  3:03             ` block/bsg.c Andrew Morton
2007-07-17  0:52 ` block/bsg.c Satyam Sharma
2007-07-17  0:57   ` block/bsg.c FUJITA Tomonori
2007-07-17  1:01   ` block/bsg.c Gabriel C
2007-07-17  4:57 ` block/bsg.c Joseph Fannin
2007-07-17  6:38 ` block/bsg.c Jens Axboe
2007-07-17  6:43   ` block/bsg.c FUJITA Tomonori
2007-07-17  6:59     ` block/bsg.c Jens Axboe
2007-07-17  7:08       ` block/bsg.c FUJITA Tomonori
2007-07-17  7:10         ` block/bsg.c Jens Axboe
2007-07-17  7:17           ` block/bsg.c FUJITA Tomonori
2007-07-17  7:19             ` block/bsg.c Jens Axboe
2007-07-17 10:07           ` block/bsg.c FUJITA Tomonori
2007-07-17 10:19             ` block/bsg.c Jens Axboe
2007-07-17 18:53               ` block/bsg.c James Bottomley
2007-07-17 19:48                 ` block/bsg.c Andrew Morton
2007-07-17 19:52                   ` block/bsg.c James Bottomley
2007-07-18  0:20                 ` block/bsg.c FUJITA Tomonori
2007-07-18 13:54                   ` James Bottomley [this message]
2007-07-18 14:23                     ` block/bsg.c James Bottomley
2007-07-18 23:18                       ` block/bsg.c FUJITA Tomonori
2007-07-17 20:52               ` block/bsg.c Bartlomiej Zolnierkiewicz
2007-07-17 21:34                 ` block/bsg.c Andrew Morton
2007-07-17 23:19                   ` block/bsg.c Bartlomiej Zolnierkiewicz
2007-07-17 22:26                 ` block/bsg.c FUJITA Tomonori
2007-07-17 22:26                   ` block/bsg.c FUJITA Tomonori
2007-07-18 20:39                   ` block/bsg.c Bartlomiej Zolnierkiewicz
2007-07-18 23:44                     ` block/bsg.c FUJITA Tomonori
2007-07-17  7:24   ` block/bsg.c FUJITA Tomonori
2007-07-17 19:18   ` block/bsg.c Andrew Morton
2007-07-17 20:22     ` block/bsg.c Andrew Morton
2007-07-17 22:19       ` block/bsg.c James Bottomley
2007-07-17 22:54         ` block/bsg.c Andrew Morton
2007-07-17 22:57           ` block/bsg.c James Bottomley
2007-07-17 23:37         ` block/bsg.c Jeff Garzik
2007-07-18  0:43           ` block/bsg.c Bartlomiej Zolnierkiewicz
2007-07-18 14:11             ` block/bsg.c James Bottomley
2007-07-18 20:32               ` block/bsg.c Bartlomiej Zolnierkiewicz
2007-07-18 21:32                 ` block/bsg.c James Bottomley
2007-07-17  7:48 ` block/bsg.c Jan Engelhardt
2007-07-17 12:04 ` [PATCH] Don't define empty struct bsg_class_device if !CONFIG_BLK_DEV_BSG (was: Re: block/bsg.c) Geert Uytterhoeven
2007-07-17 12:10   ` Jens Axboe

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=1184766854.3464.4.camel@localhost.localdomain \
    --to=james.bottomley@steeleye.com \
    --cc=akpm@linux-foundation.org \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=jens.axboe@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=tomof@acm.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.