<p dir="ltr"><br>
On 03-Nov-2013 9:10 AM, "neha naik" <<a href="mailto:nehanaik27@gmail.com">nehanaik27@gmail.com</a>> wrote:<br>
><br>
> Hi Pranay,<br>
> Your answers assume that there is always a filesystem above the block device driver which is not necessarily condition.<br>
Yes.<br>
But isn't your case the same one? You are doing i/o directly on device right? Does your case differ?</p>
<p dir="ltr"> ---P.K.S<br>
><br>
> Regards,<br>
> Neha<br>
><br>
> On Nov 2, 2013 8:58 AM, "Pranay Srivastava" <<a href="mailto:pranjas@gmail.com">pranjas@gmail.com</a>> wrote:<br>
>><br>
>><br>
>> On 01-Nov-2013 10:57 PM, "neha naik" <<a href="mailto:nehanaik27@gmail.com">nehanaik27@gmail.com</a>> wrote:<br>
>> ><br>
>> > Hi,<br>
>> > I am writing a block device driver and i am using the<br>
>> > 'blq_queue_make_request' call while registering my block device<br>
>> > driver.<br>
>> > Now as far as i understand this will bypass the linux kernel queue<br>
>> > for each block device driver (bypassing the elevator algorithm etc).<br>
>> > However, i am still not very clear about exactly how i get a request.<br>
>> ><br>
>> > 1. Consider i am doing a dd on the block device directly :<br>
>> > Will it bypass the buffer cache(/page cache) or will it use it.<br>
>><br>
>> Page cache use is for file system. Block driver has got nothing to do with it. So lets keep these separate.<br>
>><br>
>> Bios don't care which page you give them all it needs is a page in bvec. The file system would wait on that page to be uptodate which might be done in bio_end_io if i/o was good.<br>
>><br>
>> In case of buffer heads the same thing. Submit_bh would create a bio for that bh so really same stuff.<br>
>><br>
>> > Example if i register my block device with set_blocksize() as 512. And<br>
>> > i do a dd of 512 bytes will i get a read because it passes through the<br>
>> > buffer cache and since the minimum page size is 4096 it has to read<br>
>> > the page first and then pass it to me.<br>
>><br>
>> If you are writing why it would read the page? Reads would initiate write outs i think. Take a look at generic_file_aio_write.<br>
>><br>
>> > I am still unclear about the 'page' in the bvec. What does that<br>
>> > refer to? Is it a page from the page cache or a user buffer (DMA).<br>
>><br>
>> Whatever filesystem gave it. If it uses the generic functions that should come from page cache but again it depends on how filesystem created bio.<br>
>><br>
>> So for block driver you need to know if the page you are given in bvec is something you can use or you need to check and take measures to successfully do i/o.<br>
>><br>
>> ><br>
>> ><br>
>> > 2. Another thing i am not clear about is a queue. When i register my<br>
>> > driver, the 'make_request' function gets called whenever there is an<br>
>> > io. Now in my device driver, i have some more logic about writing<br>
>> > this io i.e some time may be spent in the device driver for each io.<br>
>> > In such a case, if i get two ios on the same block one after the other<br>
>> > (say one is writing 'a' and the other is writing 'b') then isn't it<br>
>> > possible that i may end up passing 'b' followed by 'a' to the layer<br>
>> > below me (changing the order because thread 'a' took more time than<br>
>> > thread 'b'). <br>
>> Then in that case should i be using a queue in my layer -<br>
>> > put the ios in the queue whenever i get a call to 'make_request'.<br>
>> > Another thread keeps pulling the ios from the queue and processing<br>
>> > them and passing it to the layer below.<br>
>> ><br>
>> You mean layer above right? that is the filesystem correct? But if thats the case then wouldn't your second request be blocked until the page was unlocked by file system which would happen i think after your driver was done with i/o. Thats because you won't mark the request as complete so i guess threads would wait_on_page to be unlocked.<br>
>><br>
>> If however your driver "lies" about completing requests then yeah you need to take appropriate measure.<br>
>><br>
>> ><br>
>> > Regards,<br>
>> > Neha<br>
>> ><br>
>> > _______________________________________________<br>
>> > Kernelnewbies mailing list<br>
>> > <a href="mailto:Kernelnewbies@kernelnewbies.org">Kernelnewbies@kernelnewbies.org</a><br>
>> > <a href="http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies">http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies</a><br>
>><br>
>> --P.K.S</p>