[openib-general] ISER cleanup

[Christoph Hellwig]

On Tue, Aug 23, 2005 at 07:11:18PM +0300, Dan Bar Dov wrote:
> > iser_api.h
> > 	Should iSCSI be providiing the jump table definitions?
> > 	struct iser_api_t
> > 	struct iser_api_cb_t
> > 
> > iser_ext_api.h
> > 	typedef void * iser_conn_request_t;
> > 	Delete stuff like this - it just obscures what is going on.
> OK
> 
> > 
> > 	I'm not sure what this file is doing.
> > 	I was expecting iSCSI framework to define the data structures
> > 	it needs to talk to a service provider.
> This is an "extended API". The ISER spec defines an ISER API, but it does not consider implementation. 
> We chose to implement the extra api out of the iser_api structute and in the iser_ext_api struct. 
> iSCSI is still not part of the kernel so we had first modified and added the datamover framework to 
> linux-iscsi and now to open-iscsi. Once open-iscsi is in the kernel we'll use it as the framework.

Note that we care very little about specifications for in-kernel APIs.
so the distinction between a standard API and extension make little
sense, in the end we'll probably only have more or less non-standard
APIs.

> > iser_types.h
> > 	delete typdef void * iser_api_handle_t.
> > 	replace usage of iser_api_handle_t with "void *".
> > 	Ditto for all "void *" typedefs in that file.
> OK
> 
> > 
> > 	Kernel already defines scatter-gather lists type.
> The iser_data_buf struct can point to a scatterlist array but can also be used to point at a single buffer. 
> It does not replicate scatterlist but allows us to deal with two types of registrations - single buffer and scatter lists.

We're planning to get rid of non-S/G list data transfer in the scsi
subsystem for 2.6.14+.  See the tree at 

  http://www.kernel.org/git/gitweb.cgi?p=linux/kernel/git/jejb/scsi-block-2.6.git;a=summary

in there everything but the sg,st and osst drivers doesn't submit
non-S/G requests anymore, and these last drivers is beeing worked on
already.

> > > There are many other things to be done, including both coding style 
> > > and substance, we'll proceed addressing all the technical 
> > issues that 
> > > were commented on.
> > 
> > great!
> We are going to simplify the local memory registrations by registering all memory like in the SRP driver.
> We do not understand some of the substance issues - for example, dma related comments - are taken care of by iscsi, 
> not the transport. The io_mmu comment, we completely do not understand - there was some platform specific code, but its all gone now.

Basically all use of virt_to_{phys,bus} / {phys,bus}_to_virt is wrong.
You must use proper dma mapping routines.  See Documentation/DMA-API.txt
in the kernel tree for details.