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. _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
