* Re: generic_make_request fucntion for scsi_disk
[not found] <e42309110906200746u441b82acvec4e3e513253af0@mail.gmail.com>
@ 2009-06-20 14:56 ` Alan Stern
2009-06-20 15:33 ` Ravish Tayal
0 siblings, 1 reply; 6+ messages in thread
From: Alan Stern @ 2009-06-20 14:56 UTC (permalink / raw)
To: Ravish Tayal
Cc: Kernel development list, linux-fsdevel, SCSI development list,
USB list
You should use Reply-To-All so that other people reading the mailing
list will be able to follow and contribute to the thread.
On Sat, 20 Jun 2009, Ravish Tayal wrote:
> Thanks Alan,
>
> I am actually trying to profile the time taken by each layer to complete the
> disk write opertaion as sys_write to queue_command invokation veries alot.
Of course it varies. The kernel buffers disk writes, shuffles them
around, and then carries them out when it wants to. As James has
pointed out, your write(2) system calls don't directly cause any I/O to
take place.
Alan Stern
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: generic_make_request fucntion for scsi_disk
2009-06-20 14:56 ` generic_make_request fucntion for scsi_disk Alan Stern
@ 2009-06-20 15:33 ` Ravish Tayal
0 siblings, 0 replies; 6+ messages in thread
From: Ravish Tayal @ 2009-06-20 15:33 UTC (permalink / raw)
To: Alan Stern
Cc: Kernel development list, linux-fsdevel, SCSI development list,
USB list
Sorry My mistake.
I will take care of it now onwards
regards
Ravish
On Sat, Jun 20, 2009 at 8:26 PM, Alan Stern<stern@rowland.harvard.edu> wrote:
> You should use Reply-To-All so that other people reading the mailing
> list will be able to follow and contribute to the thread.
>
> On Sat, 20 Jun 2009, Ravish Tayal wrote:
>
>> Thanks Alan,
>>
>> I am actually trying to profile the time taken by each layer to complete the
>> disk write opertaion as sys_write to queue_command invokation veries alot.
>
> Of course it varies. The kernel buffers disk writes, shuffles them
> around, and then carries them out when it wants to. As James has
> pointed out, your write(2) system calls don't directly cause any I/O to
> take place.
>
> Alan Stern
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 6+ messages in thread
* generic_make_request fucntion for scsi_disk
@ 2009-06-20 14:05 Ravish Tayal
2009-06-20 14:20 ` James Bottomley
[not found] ` <e42309110906200705j6a731ecay204969f639af5330-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
0 siblings, 2 replies; 6+ messages in thread
From: Ravish Tayal @ 2009-06-20 14:05 UTC (permalink / raw)
To: linux-kernel, linux-fsdevel, linux-scsi, linux-usb
Hello,
I am debugging Filesystem code for USB mass storage devices. I need
help to figure out after generic_make_request how the request is
placed to scsi disk (sd) requeset queue and than how sd qeueuecommand
to usb_storeage thread. (in which context, is it system call context)
inside generic_make_request
1. q = bdev_get_queue(bio->bi_bdev); [is sd.c register queue this
queue or any other scsi file?]
2. ret = q->make_request_fn(q, bio); [which file contain this
make_request_fn for scsi disk driver (generic)]
As per my unsderanding flow is like
Fat_writepage ->_block_write_full_page --> blkdev_writepage-->
block_write_full_page-->submit_bh-->generic_make_request ??? (sd ??)
----> queuecommand
Please suggest any sorce file, link or document.
with thanks
Ravish
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: generic_make_request fucntion for scsi_disk
2009-06-20 14:05 Ravish Tayal
@ 2009-06-20 14:20 ` James Bottomley
[not found] ` <e42309110906200741x28595685jf56cd505d01cc795@mail.gmail.com>
[not found] ` <e42309110906200705j6a731ecay204969f639af5330-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
1 sibling, 1 reply; 6+ messages in thread
From: James Bottomley @ 2009-06-20 14:20 UTC (permalink / raw)
To: Ravish Tayal; +Cc: linux-kernel, linux-fsdevel, linux-scsi, linux-usb
On Sat, 2009-06-20 at 19:35 +0530, Ravish Tayal wrote:
> I am debugging Filesystem code for USB mass storage devices. I need
> help to figure out after generic_make_request how the request is
> placed to scsi disk (sd) requeset queue and than how sd qeueuecommand
> to usb_storeage thread. (in which context, is it system call context)
requests out of the lower end of block come from the elevators. The
elevators can operate in a variety of contexts: user, kernel thread or
softirq depending on state.
The mechanism for queueing to the USB thread is in
scsiglue.c:queuecommand() it's basically a simple single command
consumer model: fill in slot and wake thread.
James
^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <e42309110906200705j6a731ecay204969f639af5330-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: generic_make_request fucntion for scsi_disk
[not found] ` <e42309110906200705j6a731ecay204969f639af5330-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2009-06-20 14:39 ` Alan Stern
0 siblings, 0 replies; 6+ messages in thread
From: Alan Stern @ 2009-06-20 14:39 UTC (permalink / raw)
To: Ravish Tayal
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
linux-scsi-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
On Sat, 20 Jun 2009, Ravish Tayal wrote:
> Hello,
>
> I am debugging Filesystem code for USB mass storage devices.
What part of the filesystem code are you debugging?
Your questions talk about four separate layers: the filesystem, the
block layer, the SCSI layer, and the usb-storage driver. Normally
people work on only one layer at a time.
Why are you concerned with more than one layer?
> I need
> help to figure out after generic_make_request how the request is
> placed to scsi disk (sd) requeset queue and than how sd qeueuecommand
> to usb_storeage thread. (in which context, is it system call context)
>
>
> inside generic_make_request
>
> 1. q = bdev_get_queue(bio->bi_bdev); [is sd.c register queue this
> queue or any other scsi file?]
See scsi_alloc_sdev() in scsi_scan.c. That's where the queue is
allocated.
> 2. ret = q->make_request_fn(q, bio); [which file contain this
> make_request_fn for scsi disk driver (generic)]
scsi_request_fn() is in scsi_lib.c. You could have found this out by
yourself very easily with grep. sd_prep_fn() is in sd.c.
> As per my unsderanding flow is like
> Fat_writepage ->_block_write_full_page --> blkdev_writepage-->
> block_write_full_page-->submit_bh-->generic_make_request ??? (sd ??)
> ----> queuecommand
>
> Please suggest any sorce file, link or document.
The most relevant source files are scsi_lib.c and scsi.c.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2009-06-20 15:32 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <e42309110906200746u441b82acvec4e3e513253af0@mail.gmail.com>
2009-06-20 14:56 ` generic_make_request fucntion for scsi_disk Alan Stern
2009-06-20 15:33 ` Ravish Tayal
2009-06-20 14:05 Ravish Tayal
2009-06-20 14:20 ` James Bottomley
[not found] ` <e42309110906200741x28595685jf56cd505d01cc795@mail.gmail.com>
2009-06-20 14:53 ` James Bottomley
[not found] ` <e42309110906200705j6a731ecay204969f639af5330-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-06-20 14:39 ` Alan Stern
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).