From: Mike Christie <michaelc@cs.wisc.edu>
To: arjanv@redhat.com
Cc: SCSI Mailing List <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH] sdd scsi-ml event wq
Date: Fri, 28 May 2004 02:07:03 -0700 [thread overview]
Message-ID: <40B70137.70106@cs.wisc.edu> (raw)
In-Reply-To: <1085732140.2782.14.camel@laptop.fenrus.com>
Arjan van de Ven wrote:
> On Fri, 2004-05-28 at 09:59, Mike Christie wrote:
>
>>The attached patch just adds a scsi-ml work queue to handle all
>>events. It also converts the transport_scsi_fc class to use it,
>>so drivers using that class do not have to worry about calling
>>the event functions from a process context.
>
>
> question: it seems you allow only a limited number of outstanding
> events, fair enough.
I am not sure I know what you mean. You are referring to when memory
allocations fail, right?
However, how are users of this API supposed to
> handle failure? I see you pass the error nicely all the way down, yet I
> don't quite understand how a driver (the consumer of the API) is
> supposed to handle failure. Queue the event itself? Sounds ugly/wrong to
> me. I'm just wondering if the cleanup you propose doesn't just mean that
> the uglyness gets pushed to correct users of the API.. which isn't quite
> a nett win (under the assumption that there are more than one users of a
> subsystem function)
I agree with you, and I do not have a good answer. When the system is failing
memory allocations it is difficult to do a lot of things. I was thinking that
in such an extreme situation that it would be acceptable for events to fail.
Would it be better to have the API set a timer and retry at a later time? I was
thinking you could end up with a long backlog of events that may be worthless
by the time the system can allocate memory - which is why I put in the
mempool (I know that they are not magic and will fail too though). I am open
to ideas.
next prev parent reply other threads:[~2004-05-28 9:07 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-28 7:59 [PATCH] sdd scsi-ml event wq Mike Christie
2004-05-28 8:15 ` Arjan van de Ven
2004-05-28 9:07 ` Mike Christie [this message]
2004-05-28 9:18 ` Arjan van de Ven
2004-05-28 10:00 ` Mike Christie
2004-06-07 7:54 ` Douglas Gilbert
-- strict thread matches above, loose matches on Subject: below --
2004-06-03 10:46 Martin Peschke3
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=40B70137.70106@cs.wisc.edu \
--to=michaelc@cs.wisc.edu \
--cc=arjanv@redhat.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.