Mid-layer API?

Mid-layer API?

[Haefliger, Juerg]

Hi All,

First, I'm a newbie to SCSI so please forgive me if any of the following
questions are silly. Having said that, I very much appreciate pointers
to good SCSI references and the Linux implementaion of the SCSI
subsystem...

I have a kernel driver that needs to send SCSI commands and data to a FC
disk attached to a Qlogic FC HBA. I'm hooking into the SCSI mid-layer by
calling scsi_do_req(). It seems to work but I'm not sure if this is the
right way of doing things. Is scsi_do_req the right entry point into the
mid-layer or should I use something else? Or should I hook into
something else than the mid-layer? And finally, is there any
documentation talking about the mid-layer API?

Any help is greatly appreciated.

Thanks
...juerg

Re: Mid-layer API?

[Randy Dunlap]

On Wed, 18 Oct 2006 14:43:09 -0500 Haefliger, Juerg wrote:

> Hi All,
> 
> First, I'm a newbie to SCSI so please forgive me if any of the following
> questions are silly. Having said that, I very much appreciate pointers
> to good SCSI references and the Linux implementaion of the SCSI
> subsystem...
> 
> I have a kernel driver that needs to send SCSI commands and data to a FC
> disk attached to a Qlogic FC HBA. I'm hooking into the SCSI mid-layer by
> calling scsi_do_req(). It seems to work but I'm not sure if this is the
> right way of doing things. Is scsi_do_req the right entry point into the
> mid-layer or should I use something else? Or should I hook into
> something else than the mid-layer? And finally, is there any
> documentation talking about the mid-layer API?
> 
> Any help is greatly appreciated.


I began on a scsi-mid-layer-api.txt file a few years ago.  :(
Sadly I haven't touched it since then.  You can see if it may help
you any:  http://www.xenotime.net/linux/doc/scsi-interfaces.txt

It's just text from scsi .h and .c files.

You can also see if this other *also outdated* SCSI driver doc
helps you any:  (get pdf or OpenOffice files from
http://developer.osdl.org/dev/opendrivers/wiki/index.php/Storage )


Feel free to update/correct either of them.  :)

---
~Randy

RE: Mid-layer API?

[Haefliger, Juerg]

> I began on a scsi-mid-layer-api.txt file a few years ago.  :( 
> Sadly I haven't touched it since then.  You can see if it may 
> help you any:  http://www.xenotime.net/linux/doc/scsi-interfaces.txt
> 
> It's just text from scsi .h and .c files.
> 
> You can also see if this other *also outdated* SCSI driver 
> doc helps you any:  (get pdf or OpenOffice files from 
> http://developer.osdl.org/dev/opendrivers/wiki/index.php/Storage )
> 

Thanks Randy. Those are good pointers.


...juerg

Re: Mid-layer API?

[Luben Tuikov]

--- "Haefliger, Juerg" <Juerg.Haefliger@hp.com> wrote:
> I have a kernel driver that needs to send SCSI commands and data to a FC
> disk attached to a Qlogic FC HBA. I'm hooking into the SCSI mid-layer by
> calling scsi_do_req(). It seems to work but I'm not sure if this is the
> right way of doing things. Is scsi_do_req the right entry point into the
> mid-layer or should I use something else? Or should I hook into
> something else than the mid-layer?

Juerg,

The answer to your question depends on the answer to this
question: Who is generating the commands and data,
or loosely where are the commands and data coming from?

Once you've answered this, then you can take a look at who (or what)
is the midlayer servicing.  Sketch that on paper.

Then chart on another sheet of paper the complete path of the
commands and data,  from the origin to the point you want to "send"
them to the FC disk and compare that the above chart.

This will give you the answer of where you're supposed to
"hook into" and why.

Good luck!
    Luben


> And finally, is there any
> documentation talking about the mid-layer API?
> 
> Any help is greatly appreciated.
> 
> Thanks
> ...juerg
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

RE: Mid-layer API?

[Haefliger, Juerg]

Hi Luben,

> The answer to your question depends on the answer to this
> question: Who is generating the commands and data, or loosely 
> where are the commands and data coming from?

I'm using the Linux box as a 'dumb' SCSI adapter. The SCSI commands are
received by a driver that manages a proprietary interface through which
the commands are coming in from a remote host. The driver then needs to
forward the commands to the FC disk (by means I'm trying to figure out
here :-) and pass the results back up to the host. 
 
> Once you've answered this, then you can take a look at who 
> (or what) is the midlayer servicing.  Sketch that on paper.
> 
> Then chart on another sheet of paper the complete path of the 
> commands and data,  from the origin to the point you want to "send"
> them to the FC disk and compare that the above chart.

I guess my biggest problem is that I don't fully understand the flow of
command and data through the different layers. I could instrument a
kernel to dump some tracing information but that sounds like a lot of
work. Might be worth though to gain a better understanding.

> This will give you the answer of where you're supposed to 
> "hook into" and why.

Not quiet there yet :-) 

Thanks for your help
...juerg


> Good luck!
>     Luben
> 
> 
> > And finally, is there any
> > documentation talking about the mid-layer API?
> > 
> > Any help is greatly appreciated.
> > 
> > Thanks
> > ...juerg
> > 
> > -
> > To unsubscribe from this list: send the line "unsubscribe 
> linux-scsi" 
> > in the body of a message to majordomo@vger.kernel.org More 
> majordomo 
> > info at  http://vger.kernel.org/majordomo-info.html
> > 
> 
> 

RE: Mid-layer API?

[Luben Tuikov]

Juerg,

--- "Haefliger, Juerg" <Juerg.Haefliger@hp.com> wrote:
> > The answer to your question depends on the answer to this
> > question: Who is generating the commands and data, or loosely 
> > where are the commands and data coming from?
> 
> I'm using the Linux box as a 'dumb' SCSI adapter.

You just answered your question!

> The SCSI commands are
> received by a driver that manages a proprietary interface through which
> the commands are coming in from a remote host. The driver then needs to
> forward the commands to the FC disk (by means I'm trying to figure out
> here :-) and pass the results back up to the host.

You again answered your own question.
 
> I guess my biggest problem is that I don't fully understand the flow of
> command and data through the different layers.

Take a look at the scsi_host template, and the document Randy mentioned.

    Luben


> Not quiet there yet :-) 
> 
> Thanks for your help
> ...juerg
> 
> 
> > Good luck!
> >     Luben
> > 
> > 
> > > And finally, is there any
> > > documentation talking about the mid-layer API?
> > > 
> > > Any help is greatly appreciated.
> > > 
> > > Thanks
> > > ...juerg
> > > 
> > > -
> > > To unsubscribe from this list: send the line "unsubscribe 
> > linux-scsi" 
> > > in the body of a message to majordomo@vger.kernel.org More 
> > majordomo 
> > > info at  http://vger.kernel.org/majordomo-info.html
> > > 
> > 
> > 
> 

question scsi_register verses register_blkdev

[Thayne Harmon]

Hi,

If this is the wrong list, please direct me to the appropriate one, thank you.

I am trying to write a linux driver (I'm new at this) for a standard SCSI host bus adapter.
I have read the Linux Device Drivers book 3rd ed., searched the web and read this list.
I do not understand when one should use 'scsi_register' or 'register_blkdev', or does one use both?
In searching the kernel source, it seems that most of the drivers use scsi_register,
while the device modules sr, sd, etc. use register_blkdev.

The book however never mentions scsi_register as part of a driver.

Could someone give me a clue on this?

Best regards,

Thayne Harmon

Re: question scsi_register verses register_blkdev

[Stefan Richter]

Thayne Harmon wrote:
> I am trying to write a linux driver (I'm new at this) for a
> standard SCSI host bus adapter.
...

Seems you want to write a SCSI low-level provider. The low-level API is
documented in linux/Documentation/scsi_mid_low_api.txt.
-- 
Stefan Richter
-=====-=-==- =-=- =-=--
http://arcgraph.de/sr/

RE: Mid-layer API?

[Haefliger, Juerg]

Hi Luben,

> > I'm using the Linux box as a 'dumb' SCSI adapter.
> 
> You just answered your question!

Hmm... OK...
 
> > The SCSI commands are
> > received by a driver that manages a proprietary interface through 
> > which the commands are coming in from a remote host. The 
> driver then 
> > needs to forward the commands to the FC disk (by means I'm 
> trying to 
> > figure out here :-) and pass the results back up to the host.
> 
> You again answered your own question.

Hmmmmmm....
  
> > I guess my biggest problem is that I don't fully understand 
> the flow 
> > of command and data through the different layers.
> 
> Take a look at the scsi_host template, and the document Randy 
> mentioned.

I did but I still don't get it :-) In fact I'm more confused now. Why
host_template? Isn't that function used to register an LLD with the
mid-layer? I'm trying to tap into the other side of the mid-layer.

Thanks
...juerg


>     Luben

Re: Mid-layer API?

[Steven Hayter]

Haefliger, Juerg wrote:
 > Hi Luben,
 >
 > I did but I still don't get it :-) In fact I'm more confused now. Why
 > host_template? Isn't that function used to register an LLD with the
 > mid-layer? I'm trying to tap into the other side of the mid-layer.

On the driver side (HBA) you've got the host template, and queue_command().

On the other side (the interface used by sg/sd/st) used to live 
scsi_do_req() (gone in 2.6.18) which is now scsi_execute_async() and 
friends.

The header files/function templates should be fairly self-explanatory 
apart from the confusing use of old-style names, the 'void *buffer' is 
the scatter gather list, the 'unsigned buflen' is the total amount of 
data you want to transfer, and use_sg is the number of scatter-gather 
elements.

Hope that gives you some place to start with, if you just want to send 
SCSI commands into the kernel.

Regards,
Steve