On Tue, May 08 2007, FUJITA Tomonori wrote:
> > From: Daniel.E.Messinger@xxxxxxxxxxx
> > Subject: bidi bsg is non-blocking
> > Date: Mon, 7 May 2007 10:21:18 -0500
> >
> > > I'm attempting to use the bidi variant of bsg to talk to an OSD target
> > > device. I've run into an undesirable situation.
> > >
> > > My application has a free-running receive loop (doing a read() on the bsg
> > > device) waiting for responses to commands sent to bsg by another thread.
> > > The problem is that the receive thread is getting ENODATA from the read()
> > > when there are no commands pending. I have NOT set non-blocking.
> > >
> > > Note that the old sg driver was quite willing to block until there was a
> > > response available. I find this scenario greatly preferable.
> > >
> > > Could bsg be fixed so that read() blocks when there is nothing to return?
> >
> > I think that this is a bug.
> >
> > This patch is against the bsg branch in the Jens' git tree.
> >
> > I guess that it would be nice to do more cleanups on these parts.
> >
> >
> > From 52a9fcf0af72f212ddd93918b7f9f0f0e706c215 Mon Sep 17 00:00:00 2001
> > From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
> > Date: Tue, 8 May 2007 15:57:43 +0900
> > Subject: [PATCH] fix read ENODATA bug
> >
> > This patch fixes a bug that read() gives ENODATA even with a blocking
> > file descriptor when there are no commands pending.
> >
> > This also includes some cleanups.
> >
> > Signed-off-by: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
>
> Oops, I sent a wrong patch. This is a right one.
Patch looks good, I agree this is the way that bsg should act for a
blocking read on an "empty" queue.
> + ret = wait_event_interruptible(bd->wq_done, bd->done_cmds);
> + if (ret) {
> + bc = ERR_PTR(-ERESTARTSYS);
> + break;
> + } else
> + continue;
> } while (1);
The else clause is pointless.
Apart from that, it looks sounds. Can you resend?
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
