On Mar 20, 2016, at 2:25 PM, Ruben Safir [off-list ref] wrote:

On Sun, Mar 20, 2016 at 01:58:47PM +0800, ?? wrote:

quoted

Thanks!
I have another question if it is possible to rewrite the data transfer function avoiding the bio complexity? 

what is the bio complexity that you are refering to?

I don?t think request?s bio is much complex.
I want to rewrite the data transfer function as simple as possible 
for getting my driver working even without the knowledges of bio, like the sbull_request.

quoted

Yun Zhang(??)

quoted

On Mar 20, 2016, at 8:13 AM, Dongli Zhang [off-list ref] wrote:

Please refer to https://github.com/21cnbao/training/tree/50506cf04bc5616e0c3f3285dbb006c54deb1c53/kernel/drivers/vmem_disk

Dongli Zhang (???)
http://finallyjustice.github.io


________________________________

quoted

From: zyunone at 163.com 
Subject: How to rewrite sbull_request in ldd3 for current kernel? 
Date: Sat, 19 Mar 2016 21:22:19 +0800 
To: kernelnewbies at kernelnewbies.org 

Hi, 
I am reading the book, Linux Driver Development 3. 
In the chapter on block driver of this book, I need some help to 
rewriting the sbull_request since the kernel?s block API was changed. 

The sbull_request code: 
/* 
* The simple form of the request function. 
*/ 
static void sbull_request(request_queue_t *q) 
{ 
struct request *req; 

while ((req = elv_next_request(q)) != NULL) { 
struct sbull_dev *dev = req->rq_disk->private_data; 
if (! blk_fs_request(req)) { 
printk (KERN_NOTICE "Skip non-fs request\n"); 
end_request(req, 0); 
continue; 
} 
sbull_transfer(dev, req->sector, req->current_nr_sectors, 
req->buffer, rq_data_dir(req)); 
end_request(req, 1); 
} 
} 

I have rewritten the code above into: 

/* 
* The simple form of the request function. 
*/ 
void blkplay_request(struct request_queue *q) 
{ 
struct request *req; 

while (!blk_queue_stopped(q) && 
(req = blk_peek_request(q)) != NULL) { 
struct blkplay_dev *dev = req->rq_disk->private_data; 
blk_start_request(req); 
if (req->cmd_type != REQ_TYPE_FS) { 
printk (KERN_NOTICE "Skip non-fs request\n"); 
blk_end_request(req, -EIO, 0); 
continue; 
} 

/* I don?t know how to write the statement below */ 
blkplay_transfer(dev, req->sector, req->current_nr_sectors, 
req->buffer, rq_data_dir(req)); 

blk_end_request_cur(req, 0); 
} 
} 


Is the rewrite proper? 



The compiler can?t compile it because the request struct no longer has 

the field of ?sector? and ?current_nr_sectors?. I have read the kernel code 

about the request struct, the kernel code said the __data_len and 
__sector field of 
request struct is internal so that we shouldn?t access them directly. 

How could I rewrite it ? Thanks. 

_______________________________________________ Kernelnewbies mailing 
list Kernelnewbies at kernelnewbies.org 
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies 

		 	   		  
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies at kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies at kernelnewbies.org <mailto:Kernelnewbies@kernelnewbies.org>
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies <http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies>

-- 
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com <http://www.mrbrklyn.com/> 

DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com <http://www.nylxs.com/> - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources <http://www2.mrbrklyn.com/resources> - Unpublished Archive 
http://www.coinhangout.com <http://www.coinhangout.com/> - coins!
http://www.brooklyn-living.com <http://www.brooklyn-living.com/> 

Being so tracked is for FARM ANIMALS and and extermination camps, 
but incompatible with living as a free human being. -RI Safir 2013

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160320/50e9bf36/attachment-0001.html