On 10/28/2016 10:06 AM, Bart Van Assche wrote:
On Fri, 2016-10-28 at 09:45 -0600, Jens Axboe wrote:
On 10/27/2016 04:37 PM, Bart Van Assche wrote:
On 10/26/2016 10:45 PM, Hannes Reinecke wrote:
On 10/26/2016 10:21 PM, Bart Van Assche wrote:
Some time ago I created the attached state diagrams for myself
to avoid
that I would have to reread the entire block layer core source
code if
it has been a while since I had a look at it. Do you think it
would be
useful to add these diagrams somewhere in the Documentation
directory?
Can you add a step for the mapping between software and
hardware queues?
Also the actual submission to the LLDD (in step 'executing')
could do
with a bit more emphasis.
And maybe the fontsize could be a tad smaller; currently it's
hard to
figure out which label goes where, expecially in the bottom half.
Thanks Hannes for the review. How about the attached second version
of
these diagrams?
I think they are a little confusing. Some of it is specific to non-fs
requests, yet you have the plugging path in there as well. Was the
intent to just show the PC path?
Hello Jens,
As far as I know there is no documentation yet in the kernel tree
(other than the block layer source code) of how the different block
layer functions affect the request state. Several kernel developers
seem not to be aware of when it is allowed to call which block layer
function. See e.g. "Re: [PATCH v2 1/2] scsi: Handle Unit Attention when
issuing SCSI command" (http://www.spinics.net/lists/linux-scsi/msg10073
7.html) for an example. These diagrams make e.g. clear when it is
allowed to call blk_start_request() and when that it is not allowed.
Don't get me wrong, I think it would be great to have some graphic
documentation of the flow. But I think it should be clear about what it
is showing, not just some of it. Otherwise it'll just cause people to
get confused.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
