kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
From: xjtuwjp@gmail.com (Jack Wang)
To: kernelnewbies@lists.kernelnewbies.org
Subject: scsi subsystem in linux
Date: Wed, 06 Nov 2013 10:55:38 +0100	[thread overview]
Message-ID: <527A121A.1020300@gmail.com> (raw)
In-Reply-To: <CAL+pkpdpvckeADYaAGYBE+xon2UZfOr95NxeUPJtF64BREu1Xw@mail.gmail.com>

On 11/05/2013 05:19 PM, nidhi mittal hada wrote:
> My doubt is :-
> 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 ?
> 
> 


The links below show how block layer request connect to scsi request,
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
> 
> 
> 
> 
> 
> On Tue, Nov 5, 2013 at 6:34 PM, nidhi mittal hada
> <nidhimittal19 at gmail.com <mailto:nidhimittal19@gmail.com>> wrote:
> 
>     _*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
>     <nidhimittal19 at gmail.com <mailto:nidhimittal19@gmail.com>> 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);
> 
> 
>         *which is scsi_prep_fn not the sd_prep_fn isnt it ??*
> 
> 
>         Then where is sd_prep_fn is used for ??
> 
>         Thanks
>         Nidhi
> 
> 
> 
> 
>         On Tue, Nov 5, 2013 at 5:39 PM, Jack Wang <xjtuwjp@gmail.com
>         <mailto:xjtuwjp@gmail.com>> 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 at kernelnewbies.org
>             <mailto:Kernelnewbies@kernelnewbies.org>
>             > 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/
> 

  reply	other threads:[~2013-11-06  9:55 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-05 11:48 scsi subsystem in linux nidhi mittal hada
2013-11-05 12:09 ` Jack Wang
2013-11-05 12:43   ` nidhi mittal hada
2013-11-05 13:04     ` nidhi mittal hada
2013-11-05 16:19       ` nidhi mittal hada
2013-11-06  9:55         ` Jack Wang [this message]
2013-11-07  8:54           ` piyush moghe
  -- strict thread matches above, loose matches on Subject: below --
2013-11-08  8:53 pmkernel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=527A121A.1020300@gmail.com \
    --to=xjtuwjp@gmail.com \
    --cc=kernelnewbies@lists.kernelnewbies.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).