On Fri, Jul 29, 2016 at 04:26:41PM +0530, Pranay Srivastava wrote: > On Fri, Jul 29, 2016 at 4:15 PM, François <fser@xxxxxxxxxxxxxx> wrote: > > On Fri, Jul 29, 2016 at 03:58:28PM +0530, Pranay Srivastava wrote: > >> > >> I don't see req->buffer. Which version you are using? > > > > You're absolutely right. Both [1] and [2] seems to be outdated. > > I'm currently compiling and testing most of my code on a 3.19 on a 14.04 LTS ubuntu in a VM, > > rather than the actual kernel. It's simpler for me to work that way. > > > > [1] https://github.com/martinezjavier/ldd3/blob/master/sbull/sbull.c#L119 > > [2] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/block/biodoc.txt > > > > [...] > >> > >> If this is a memory backed block driver, then perhaps you can handle > >> multiple requests[?]. I don't think you need > >> to actually break up the same request into multiple requests. > > > > Actually, it is a shared memory based. Hence, a request might larger than the available room in > > the shared memory. This case has to be handled. > > So basically you hold on to some pages[?] and use that as your disk right? Well those shared pages are used to exchange chunks of data with another party, which will itself get those data, produce bio, submit bio, and put response on the shared region. > I guess setcapacity should take care of this [no?] The set_capacity() value is the one reported by the other party which queries an actual block device. Eventhough request size could be resized, if the other party takes time to respond, very few memory might be available, but large request can be enqueued. So limiting the capacity does not seem to be an option here. > I think if you just take care of the proper mapping of sector(s) to > your driver then > it should be alright. > > Too large request shouldn't reach your driver even when you > have the device opened as raw and not mounted it. > > > > > Thanks for your input! > > > > -- > > François > > > > -- > ---P.K.S -- François _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
