[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