> -----Original Message----- > From: Christoph Hellwig [mailto:[EMAIL PROTECTED] > > 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. OK, the extended API deals with the connection establishement. If we'll be using the "socket" semantics the extended API will be the socket. If its something else, then whatever it is. We still don't have any sensible solution to that since it is not possible to start the QP in user space and then use it in kernel. In any case, we can combine the two 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
This is fine for the data, however, we also need to register PDU memory which is not in sg lists. This is most visible with unsolicited data, where part or all of the data is sent along with the PDU in a single send-control. We considered packing the PDU in a single element sg list, but it seems ridiculous. > > > http://www.kernel.org/git/gitweb.cgi?p=linux/kernel/git/jejb/s > csi-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. >> 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. NP. _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
