[Stgt-devel] vsd -> vdev is bad

Mike Christie michaelc at cs.wisc.edu
Tue Sep 20 21:22:09 CEST 2005


Ming Zhang wrote:
> On Tue, 2005-09-20 at 13:44 -0500, Mike Christie wrote:
> 
>>Ming Zhang wrote:
>>
>>>On Tue, 2005-09-20 at 13:27 -0500, Mike Christie wrote:
>>>
>>>
>>>>Mike Christie wrote:
>>>>
>>>>
>>>>>Ming Zhang wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Hi Mike
>>>>>>
>>>>>>I think change vsd->vdev is a bad idea.
>>>>>
>>>>>
>>>>>I would agree it is a bad name, but all that device does today is the 
>>>>>reads and writes. It should probably be called something-something-IO. 
>>>>>From your experience with iet, do you think a read or write will be 
>>>>>different for tape or disk when using the interface we are using?
>>>>>
>>>>
>>>>Oh yeah, I had looked at scst's dev_handlers for an example. I think 
>>>>mostly only the error hanlding will be a problem.
>>>
>>>
>>>yes, that is quite different.
>>>
>>
>>So I guess we will need something. Originally the vsd and sd names came 
>>about becuase we were only doing SCSI and vsd was a virtual scsi disk 
>>and sd was a scsi disk passthrough type of device. They basically 
>>emulated SCSI's ULDs for tape, cd, disk but they also performed 
>>different types of IO, passthrough vs generic_file_readv/writev. 
>>Eventually we pushed the SCSI stuff to the protocol handlers and the 
>>devices became what they are today. Maybe io_handlers or io_type is a 
>>better name?
>>
>>Then to suport scsi tape, cd, etc we can add that code to the scsi 
>>protocol and have something simialr to the SCSI-ml ULDs.
> 
> 
> iet currently have target type and io type. target_disk is a target type
> and fileio is a io type. so current vsd looks more like a io_handlers as
> u said.
> 
> in fact, i do not think target type is ok since it is quite possible
> that 1 target has several lu while some of them are disk and others are
> cdrom or tape. so LU type is better here. base on scsi spec, it is the
> device server to decide what action it performs.
> 
> so it would be nice that tgt define a clear line between target mode
> common and device specific; each lu has its own device server. device
> server process most of the function in user space, and r/w use certain
> io handler.
> 

So for tgt we will end up having:

- target_type (this is just the low level target driver like IET or 
qla2xxx, emulex, vscsi etc).
- device_type (at the moment this just handles low level IO details but 
will end up handling some device specifics like if the device is a tape, 
disk, etc (some of this code is just stuck in tgt_scsi right now since 
we only support disks, but the scsi specifics will be seperated out 
similar to the SCSI-ml ULDs) and we will move the low level IO details 
to a new struct)
- io_handler (this will handle the lower level destination IO details 
like if it is uses blk_execute_rq_nowait, sendfile or generic_file_*, etc).

And sometihng similar will be needed in userspace.





More information about the stgt mailing list