I think sd_prep_fn is a generic function for any SCSI device while scsi_prep_fn specifically SCSI Disks or LUN's, so if you have a filesystem created on top of SCSI Disk scsi_prep_fn function will be called. In case you have any other SCSI device then you will have sd_prep_fn will be called.
The comment on top of sd_probe mentions this:
/**
* sd_probe - called during driver initialization and whenever a
* new scsi device is attached to the system. It is called once
* for each scsi device (not just disks) present.
* @dev: pointer to device object
Similarly argument to scsi_alloc_sdev ( while internally calls scsi_alloc_queue ---> blk_queue_prep_rq(q, scsi_prep_fn) ) accepts lun id which I think is specific to SCSI LUN.
For understanding linux SCSI Subsystem you can also refer to kernel SCSI documentation and also the below mentioned link:
Regards,
Piyush Moghe
On Wed, Nov 6, 2013 at 3:25 PM, Jack Wang <xjtuwjp@xxxxxxxxx> wrote:
On 11/05/2013 05:19 PM, nidhi mittal hada wrote:
> My doubt is :-The links below show how block layer request connect to scsi request,
> When we know block device driver , request structure, request queue
> operation .. as per LDD.
> How and where the request structure we are getting in scsi layer
> fits/relates to thi sblock layer request structure....
>
> is the sequence ..block device layer request function -> calls scsi
> layer request function ?
>
>
but In Chinese, sorry, but you may find clue in the code section.
http://blog.csdn.net/fudan_abc/article/details/1966510
http://blog.csdn.net/fudan_abc/article/details/1966538
http://blog.csdn.net/fudan_abc/article/details/1967045
http://blog.csdn.net/fudan_abc/article/details/1967050
BTW: Why not use dm-crypt?
Jack
>> <nidhimittal19@xxxxxxxxx <mailto:nidhimittal19@xxxxxxxxx>> wrote:
>
>
>
>
> On Tue, Nov 5, 2013 at 6:34 PM, nidhi mittal hada
>
> _*Setting of sd_prep_fn()*_
> sd_probe is called*/whenever a/* */new scsi device is attached to
> the system. /*
>
> sd_probe calls -> sd_probe_async->
> inside sd_probe_async, request prep fn is set to *sd_prep_fn*
> >>>>like this blk_queue_prep_rq(sdp->request_queue, sd_prep_fn);> _*Calling of sd_prep_fn*_
>
>
> ?????
>
> Is this request queue sdp->request_queue, different from the request
> queue,
> for which scsi_prep_fn is used??
>
> Are they on different layers ?
>
> Is there some relation between them ?
>
>
>
> Thanks
> Nidhi
>
>
> On Tue, Nov 5, 2013 at 6:13 PM, nidhi mittal hada
> *which is scsi_prep_fn not the sd_prep_fn isnt it ??*> <nidhimittal19@xxxxxxxxx <mailto:nidhimittal19@xxxxxxxxx>> wrote:
>
> scsi_alloc_sdev(must be called once for each scsi device) -->calls
> scsi_alloc_queue (that sets up sdev->request_queue
> sets up scsi_request_fn and
> sets up req prep function as
> scsi_prep_fn)
>
> 1738 struct request_queue *scsi_alloc_queue(struct scsi_device
> *sdev)
> 1739 {
> 1740 struct request_queue *q;
> 1742 q = __scsi_alloc_queue(sdev->host,
> scsi_request_fn);>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> 1743 if (!q)
> 1744 return NULL;
> 1746 blk_queue_prep_rq(q,
> scsi_prep_fn);>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> 1747 blk_queue_softirq_done(q, scsi_softirq_done);
> 1748 blk_queue_rq_timed_out(q, scsi_times_out);
> 1749 blk_queue_lld_busy(q, scsi_lld_busy);
> 1750 return q;
> 1751 }
> And after this call sdev_request_queue is allocated................
>
> Now, scsi_request_fn should be called while processing each
> request in this sdev->request_queue...
> Please correct me if i m wrong.
> Now, inside scsi_request_fn, we get next queueable request by
> calling
> blk_peek_request - to fetch request from request queue ..
>
> blk_peek_request -> calls __elv_next_request to fetch next request-
> and calls prep_rq_fn(q, rq);
>
>
>
>
> Then where is sd_prep_fn is used for ??
>
> Thanks
> Nidhi
>
>
>
>
> On Tue, Nov 5, 2013 at 5:39 PM, Jack Wang <xjtuwjp@xxxxxxxxx
> <mailto:Kernelnewbies@xxxxxxxxxxxxxxxxx>> <mailto:xjtuwjp@xxxxxxxxx>> wrote:
>
> Hi Nidhi,
>
> About the function call trace you can use ftrace to find
> out, another
> useful tool is scsi_logging_level to set more verbose
> logging output for
> scsi core.
>
> Regards
> Jack
> On 11/05/2013 12:48 PM, nidhi mittal hada wrote:
> >
> > Hi All
> >
> > i have got a requirement where I need to encrypt/decrypt
> data that goes
> > from scsi layer to a particular block device.
> > As per my understanding till now on scsi subsystem in
> linux, i think i
> > need to
> > use crypto api and call appropriate encrypt/decrypt
> function from sd
> > driver for block device.
> >
> > I need to locate that specific function where this change
> needs to be
> > made ...
> > I know basic block device driver writing in linux .. But
> not able to fit
> > scsi in this picture.
> >
> > I have few basic doubts.. kindly help in resolving ...
> >
> > 1) Now, as example block device driver sbull, as given
> LDD, works on
> > request queue, fetches req from this queue, using function
> req =
> > elv_next_request(q)),
> > in request function.
> > what is corresponding function in sd layer ?
> > That is the function where i have req->buffer in hand with
> me..
> >
> >
> > 2) For a write operation from initiator to disk
> > is the hierarchy like this
> > *sd_prep_fn*
> > generic block device request structure -> converted into
> scsi specific
> > request structure
> > OR
> > what is scsi_prep_fn for??
> >
> > 3)How is Scpnt pointer that is req-> special is used in
> sd_prep_func..
> > is processed? i mean which layer picks Scpnt up and
> processes ??
> >
> > 4)Any document any URL any kind of instruction will be
> extremely helpful.
> >
> > 5)Whenever a *new scsi device is attached *sd_probe is called
> > sd_async_probe() is the async part of sd_probe() So when
> this is called
> > the prep_fn is set to sd_prep_fn and hence this will be
> called.
> >
> > *But i thought sd_prep_fn should be called for each and
> every request
> > .....??*
> > Kindly help me to clear the confusion ..
> >
> >
> > Thanks
> > Nidhi
> >
> >
> >
> >
> > _______________________________________________
> > Kernelnewbies mailing list
> > Kernelnewbies@xxxxxxxxxxxxxxxxx
> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> >
>
>
>
>
>
>
>
>
> --
> Thanks & Regards
> Nidhi Mittal Hada
>
> http://nidhi-searchingmyself.blogspot.com/
>
>
>
>
> --
> Thanks & Regards
> Nidhi Mittal Hada
>
> http://nidhi-searchingmyself.blogspot.com/
>
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
