---------- Forwarded message ---------- From: Rohit Sharma <imreckless@xxxxxxxxx> Date: Wed, Sep 10, 2008 at 10:57 PM Subject: Re: Request queues and bio structures To: Peter Teoh <htmldeveloper@xxxxxxxxx> What i figured out is when a request for reading blocks is made then two possibilities are there 1. Requested block is available in the buffer. 2.The requested block has to be read from memory. we are concerned with the second case. So block to be read is identified from device mapper and then generic block layer starts I/O operation This request is given to the I/O scheduler Now our block device driver will actually transfer data by giving appropriate commands to the device. So , how does the kernel figure out from device mapper the requested block ? What are the entries in mapping layer for this ? On Wed, Sep 10, 2008 at 7:05 AM, Peter Teoh <htmldeveloper@xxxxxxxxx> wrote: > Further information here: > > http://www.kernel-labs.org/?q=blockdriver > http://www.kernel-labs.org/?q=blockiolayer > > and kernel source drivers/block subdirectory, looking for all the > register_blkdev() caller, all these can be your potential block > devices examples. whether they used BIO or not it depends. > > For example: > > ./brd.c: > if (register_blkdev(RAMDISK_MAJOR, "ramdisk")) > unregister_blkdev(RAMDISK_MAJOR, "ramdisk"); > > > And inside brd.c look at how the API blk_queue_make_request() is used > for customization of special request structure, so bio is manipulated > in this brd.c. > > But others like DAC960.c, virtio_blk.c etc does not touch the bio > internals, but deals at the request and request_queue level instead. > It leave the internals at the block/*.c implementation. For > example, for virtio_blk.c, it uses blk_rq_map_sg(): > > /* > * map a request to scatterlist, return number of sg entries setup. Caller > * must make sure sg can hold rq->nr_phys_segments entries > */ > int blk_rq_map_sg(struct request_queue *q, struct request *rq, > struct scatterlist *sglist) > { > struct bio_vec *bvec, *bvprv; > struct req_iterator iter; > struct scatterlist *sg; > > for BIO mapping. > > but then my generalization may be wrong? > > On Wed, Sep 10, 2008 at 7:37 AM, Peter Teoh <htmldeveloper@xxxxxxxxx> wrote: >> On Wed, Sep 10, 2008 at 12:51 AM, Rohit Sharma <imreckless@xxxxxxxxx> wrote: >>> I was going through block drivers, >>> i am not able to associate request queues and bio structures. >>> How are the requests processed using bio structures. >>> Can anyone provide me with block driver example or tutorial. >>> >> >> looking at block/scsi_ioctl.c:sg_io() function - does line 207 and 241 >> answer your question? >> >> 207 rq = blk_get_request(q, writing ? WRITE : READ, GFP_KERNEL); >> 208 if (!rq) >> 209 return -ENOMEM; >> 210 >> 211 if (blk_fill_sghdr_rq(q, rq, hdr, file)) { >> 212 blk_put_request(rq); >> 213 return -EFAULT; >> 214 } >> 215 >> 216 if (hdr->iovec_count) { >> 217 const int size = sizeof(struct sg_iovec) * hdr->iovec_count; >> 218 struct sg_iovec *iov; >> 219 >> 220 iov = kmalloc(size, GFP_KERNEL); >> 221 if (!iov) { >> 222 ret = -ENOMEM; >> 223 goto out; >> 224 } >> 225 >> 226 if (copy_from_user(iov, hdr->dxferp, size)) { >> 227 kfree(iov); >> 228 ret = -EFAULT; >> 229 goto out; >> 230 } >> 231 >> 232 ret = blk_rq_map_user_iov(q, rq, iov, hdr->iovec_count, >> 233 hdr->dxfer_len); >> 234 kfree(iov); >> 235 } else if (hdr->dxfer_len) >> 236 ret = blk_rq_map_user(q, rq, hdr->dxferp, hdr->dxfer_len); >> 237 >> 238 if (ret) >> 239 goto out; >> 240 >> 241 bio = rq->bio; >> 242 memset(sense, 0, sizeof(sense)); >> 243 rq->sense = sense; >> 244 rq->sense_len = 0; >> 245 rq->retries = 0; >> 246 >> 247 start_time = jiffies; >> 248 >> 249 /* ignore return value. All information is passed back to caller >> 250 * (if he doesn't check that is his problem). >> 251 * N.B. a non-zero SCSI status is _not_ necessarily an error. >> 252 */ >> 253 blk_execute_rq(q, bd_disk, rq, 0); >> 254 >> 255 hdr->duration = jiffies_to_msecs(jiffies - start_time); >> 256 >> 257 return blk_complete_sghdr_rq(rq, hdr, bio); >> >> >> >> -- >> Regards, >> Peter Teoh >> > > > > -- > Regards, > Peter Teoh > -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
