> I think that sharing the iSCSI login/logout and session/connection state > machine logic between iSER and traditional iSCSI makes sense, including > the handful of iSER specific keys that you mention for full feature > phase (FFP) before the fabric specific state transition into DDP mode > occurs. yes, sure. one thing, we have to turn all the login/text functions to work on plain char buffers (as i sugested already), and besides, we have to pay attention to some subtleties of iser-specific keys - this path is still looks buggy both in the initiator and target. i don't not have fixes, but i'll send at least the description of the bug one day :) > > The long term goal here is to include this logic into a kernel level > target mode library for both iSCSI and iSER to take advantage of. This > would be represented by a dynamic control plane > $TARGETNAME/$TARGETPORTALGROUPTAG in /sys/kernel/config/target/iser/ > using the new kernel level fabric independent configfs infrastructure in > lio-core-2.6.git/lio-4.0. > > A shorter term goal would be getting the core kernel level target mode > iSER up and running with a LIO-Target v4.x base using existing iSER > initiator code including kernel space items along the lines what you > have observed above with your own efforts. what kind of api is the kernel target based upon? to have a reasonable common library it should be made truly asynchronous- then both tcp (which is synchronous) and iser will use it happily -- To unsubscribe from this list: send the line "unsubscribe stgt" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
