some questions about block and scatterlist

[loody]

Dear Jonathan:
2011/11/1 Jonathan Corbet <corbet at lwn.net>:
> On Tue, 1 Nov 2011 19:32:38 +0900
> loody <miloody at gmail.com> wrote:
>
>> My questions are below:
>
> As are some answers :)
That will be great appreciated :)
>
>> 1. Are all struct page 32-bit aligned?
>
> Certainly, I would expect any structures found in the system memory map to
> be so aligned, yes.  If you've created an arbitrary one elsewhere I'm only
> 99% sure it would be.
>
>> If so, where is this part of code for handleing struct page be 32-bits aligned?
>
> Note that the size of struct page is carefully considered, and that they
> are packed as densely as possible, both externally and internally.  No
> lesser alignment would make sense.
I found kernel stealing LSB of page_link to put additional
information, such as sg_is_chain and sg_is_last.

That means the address of all pages have to be at least 4byte alignment.
But I didn't see any additional attribute added at the end of struct
or any precaution to take care this.

>
>> 2. if the page of scatterlist is located at high mem, how does
>> dma_map_sg mapping the virtual address?
>
> That depends on a vast array of things.  What are the addressing
> capabilities of the target device?  Is there an IOMMU involved?
No, my device has no iommu. and I found where kernel handle this part.
>
>> 3. in blk_rq_map_sg, it seems we only copy bvec->bv_page to sg->page_link
>>    why don't we add dma_address in bvec and send the bio directly to
>> the lower level driver?
>
> That would be a bit of a mixing of the layers, if nothing else.
>
>> 4. if I plug a USB HD with 3 partitions, will there be 3 request_queues?
>
> No, there is one request queue for the underlying device.
I study some block devices and it seems we use blk_init_queue for
getting a request_queue, if we want block layer handle requests and
coalesces adjacent requests.
what happen and lower driver need to do if we don't use blk_init_queue
to register a request_queue?

>
> That's an interesting mix of questions.  If you have more in the future,
> you'll likely get more (and more clueful) responses if they're accompanied
> by the code you're working on.
>
> Thanks,
>
> jon

-- 
Regards,