scsi subsystem in linux

[xjtuwjp@gmail.com (Jack Wang)]

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
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>