On Tue, 2005-09-20 at 14:22 -0500, Mike Christie wrote: > 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. > > fully agree. ;) Ming |