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. Thanks, Bart.��.n��������+%������w��{.n�����{����n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
