Re: Re: about scsi_hostlist

Re: Re: about scsi_hostlist

[Ming Zhang]

Hi, Doug

For example, like the iSCSI target code, when it start, it should find all SCSI disks or tapes link in order to export to client side. It need the scsi_device pointer in order to send requests to it. That is why I need it. Is there a formal way to find a scsi_device pointer by its lun, host id, ... or by block layer major number and minor number?

thx.



======= At 2002-11-17, 17:30:00 you wrote: =======

>On Sun, Nov 17, 2002 at 05:11:28PM -0500, Ming Zhang wrote:
>> Hi, I meet a problem when port my code to 2.5.47.
>> My goal is to get all scsi disk Scsi_Device pointers.
>
>Why?  A couple people on this list have been trying to put proper object 
>ref counting in place, and doing this sort of thing usually violates those 
>ref counting rules, so unless you have a true valid need to do this, the 
>answer is probably going to be "Don't do that".
>
>> For 2.4.18, I can use scsi_hostlist to travel through the list and get all pointer by comparing type if TYPE_DISK. But in 2.5.47, there is no such pointer. And that scsi_host_list can not be used.
>> 
>> Does anyone know how to get around to this? 
>> 
>> Thanks in advance.
>> 
>> 
>> 
>> Best regards. 
>> 
>> 
>> Ming Zhang
>> ------------------------------
>> Member of IEEE, ACM
>> mingz@ele.uri.edu
>> http://www.ele.uri.edu/~mingz
>> 1(401)874-4859
>> 
>> Department of Electrical and Computer Engineering
>> University of Rhode Island
>> 
>> 4 East Alumni Ave. Kingston, RI, 02881
>> 
>> 
>> 
>> 
>> -
>> 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
>
>-- 
>  Doug Ledford <dledford@redhat.com>     919-754-3700 x44233
>         Red Hat, Inc. 
>         1801 Varsity Dr.
>         Raleigh, NC 27606
>  
>
>.

= = = = = = = = = = = = = = = = = = = =
			

Best regards.				 


Ming Zhang
------------------------------
Member of IEEE, ACM
mingz@ele.uri.edu
http://www.ele.uri.edu/~mingz
1(401)874-4859

Department of Electrical and Computer Engineering
University of Rhode Island

4 East Alumni Ave. Kingston, RI, 02881

Re: about scsi_hostlist

[Christoph Hellwig]

On Sun, Nov 17, 2002 at 05:35:52PM -0500, Ming Zhang wrote:
> Hi, Doug
> 
> For example, like the iSCSI target code, when it start, it should find all SCSI disks or tapes link in order to export to client side.

Why you just do this in userspace?

> It need the scsi_device pointer in order to send requests to it. That is why I need it.

Umm, no.  Nothing but upperlayer drivers is supposed to talk to the scsi
midlayer directly. Implement an upperlayer driver and check for disks in
->attach instead.

Re: Re: about scsi_hostlist

[Doug Ledford]

On Sun, Nov 17, 2002 at 05:35:52PM -0500, Ming Zhang wrote: > Hi, Doug > >
For example, like the iSCSI target code, when it start, it should find all
SCSI disks or tapes link in order to export to client side. It need the
scsi_device pointer in order to send requests to it. That is why I need
it. Is there a formal way to find a scsi_device pointer by its lun, host
id, ... or by block layer major number and minor number?

There is a process by which it can be found, but it's too long to do on 
each command.  That means you need to hold a pointer to the device open 
to make this not be a performance slug.  What are you doing to hold a 
refcount on the devices you grab the pointer for so that they don't get 
freed without you knowing it?

P.S. - Enabling word wrap in your mailer would be most appreciated.

-- 
  Doug Ledford <dledford@redhat.com>     919-754-3700 x44233
         Red Hat, Inc. 
         1801 Varsity Dr.
         Raleigh, NC 27606
  

Re: Re: about scsi_hostlist

[Oliver Xymoron]

On Sun, Nov 17, 2002 at 05:35:52PM -0500, Ming Zhang wrote:
> For example, like the iSCSI target code, when it start, it should
> find all SCSI disks or tapes link in order to export to client side.

No it shouldn't! What if one of them happens to be your boot device?
You'll want to be able to configure from userspace exactly which
devices are available, as well as what authentication they require,
etc.

In fact, I'd recommend running all of the iSCSI target negotiation in
userspace and only push down sockets that have established sessions to the
kernel if you find that you need to for performance. You probably
don't need to.

Further, I'd recommend supporting block devices other than SCSI and
files (similar to the loopback block device) otherwise you're missing
most of the point of using Linux as an iSCSI target. I want to serve
my diskless Beowulf nodes via iSCSI with LVM over RAID5 on IDE disks
and have web manageable storage at a tenth of the cost of SCSI/FC.
Building a cheaper SCSI JBOD is boring.

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.." 

Re: Re: about scsi_hostlist

[Ming Zhang]

>On Sun, Nov 17, 2002 at 05:35:52PM -0500, Ming Zhang wrote:
>> Hi, Doug
>> 
>> For example, like the iSCSI target code, when it start, it should find all SCSI disks or tapes link in order to export to client side.
>
>Why you just do this in userspace?
>
that iscsi target have to be a kernel module.

>> It need the scsi_device pointer in order to send requests to it. That is why I need it.
>
>Umm, no.  Nothing but upperlayer drivers is supposed to talk to the scsi
>midlayer directly. Implement an upperlayer driver and check for disks in
>->attach instead.
~~~would u like to explain this in more detail? which ->attach?

thx

>
>.

Re: Re: about scsi_hostlist

[Ming Zhang]

======= At 2002-11-17, 22:57:00 you wrote: =======

>On Sun, Nov 17, 2002 at 05:43:38PM -0500, Ming Zhang wrote:
>> >Why you just do this in userspace?
>> >
>> that iscsi target have to be a kernel module.
>
>why?
basically, an iscsi target tell clients how many scsi devices it has, then iscsi client login and get a reference from it. might be an id stand for a certain scsi device, for example, the lun. then client send request and target get this request, check which scsi device the request want to operate on, and call routine to finish it. since the main operations is tcp/ip send/recv and scsi read/write. I think write it as a kernel module is more suitable. and currently, all iscsi reference implementation on 2.4.x kernel are kernel modules.
>
>> >Umm, no.  Nothing but upperlayer drivers is supposed to talk to the scsi
>> >midlayer directly. Implement an upperlayer driver and check for disks in
>> >->attach instead.
>> ~~~would u like to explain this in more detail? which ->attach?
>
>The attach routine of the upper layer driver.  See struct
>Scsi_Device_Template in hosts.h or look at one of the existing upper
>layer drivers (like sd or sr)
thx, i will check that.
>
>-
>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: Re: about scsi_hostlist

[Alan Cox]

> basically, an iscsi target tell clients how many scsi devices it has, then 


Thats broken (like the word wrap on your mailer btw)

How many scsi devices it has _when_. Controllers and disks are all hot
pluggable. 

Alan

Re: Re: about scsi_hostlist

[Oliver Xymoron]

On Sun, Nov 17, 2002 at 11:48:22PM +0000, Alan Cox wrote:
> > basically, an iscsi target tell clients how many scsi devices it has, then 
> 
> Thats broken (like the word wrap on your mailer btw)
> 
> How many scsi devices it has _when_. Controllers and disks are all hot
> pluggable. 

iSCSI has notification/discovery events. There's no reason the target
side of iSCSI can't be completely userspace and can interface with
hotplug. It wants per-device configuration anyway for access control
and authentication.

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."