Hi Pranay, Basically user can do io directly on device without involving the filesystem. Regards, Neha On Sat, Nov 2, 2013 at 11:18 PM, Pranay Srivastava <pranjas@xxxxxxxxx> wrote: > > On 03-Nov-2013 9:10 AM, "neha naik" <nehanaik27@xxxxxxxxx> wrote: >> >> Hi Pranay, >> Your answers assume that there is always a filesystem above the block >> device driver which is not necessarily condition. > Yes. > But isn't your case the same one? You are doing i/o directly on device > right? Does your case differ? > > ---P.K.S > > >> >> Regards, >> Neha >> >> On Nov 2, 2013 8:58 AM, "Pranay Srivastava" <pranjas@xxxxxxxxx> wrote: >>> >>> >>> On 01-Nov-2013 10:57 PM, "neha naik" <nehanaik27@xxxxxxxxx> wrote: >>> > >>> > Hi, >>> > I am writing a block device driver and i am using the >>> > 'blq_queue_make_request' call while registering my block device >>> > driver. >>> > Now as far as i understand this will bypass the linux kernel queue >>> > for each block device driver (bypassing the elevator algorithm etc). >>> > However, i am still not very clear about exactly how i get a request. >>> > >>> > 1. Consider i am doing a dd on the block device directly : >>> > Will it bypass the buffer cache(/page cache) or will it use it. >>> >>> Page cache use is for file system. Block driver has got nothing to do >>> with it. So lets keep these separate. >>> >>> 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. >>> >>> In case of buffer heads the same thing. Submit_bh would create a bio for >>> that bh so really same stuff. >>> >>> > Example if i register my block device with set_blocksize() as 512. And >>> > i do a dd of 512 bytes will i get a read because it passes through the >>> > buffer cache and since the minimum page size is 4096 it has to read >>> > the page first and then pass it to me. >>> >>> 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. >>> >>> > I am still unclear about the 'page' in the bvec. What does that >>> > refer to? Is it a page from the page cache or a user buffer (DMA). >>> >>> 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. >>> >>> 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. >>> >>> > >>> > >>> > 2. Another thing i am not clear about is a queue. When i register my >>> > driver, the 'make_request' function gets called whenever there is an >>> > io. Now in my device driver, i have some more logic about writing >>> > this io i.e some time may be spent in the device driver for each io. >>> > In such a case, if i get two ios on the same block one after the other >>> > (say one is writing 'a' and the other is writing 'b') then isn't it >>> > possible that i may end up passing 'b' followed by 'a' to the layer >>> > below me (changing the order because thread 'a' took more time than >>> > thread 'b'). >>> Then in that case should i be using a queue in my layer - >>> > put the ios in the queue whenever i get a call to 'make_request'. >>> > Another thread keeps pulling the ios from the queue and processing >>> > them and passing it to the layer below. >>> > >>> 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. >>> >>> If however your driver "lies" about completing requests then yeah you >>> need to take appropriate measure. >>> >>> > >>> > Regards, >>> > Neha >>> > >>> > _______________________________________________ >>> > Kernelnewbies mailing list >>> > Kernelnewbies@xxxxxxxxxxxxxxxxx >>> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >>> >>> --P.K.S _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
