Nigel, > It has taken many months to find & fix the subtle bug in the existing > iscsitgt code. I guess it will be the same with the new Comstar code.
Not necessarily the case. Although the Rick McNeal did a good job of being iSCSI Target technical lead, project lead, individual contributor, and open source iSCSI proponent (among other things), when he left Sun, a lot of knowledge left with him. The iSCSI Target code is a lot more then RFC 3720, and it takes time to acquire a similar understanding of the code behind this RFC. With ComSTar, Sun is bringing to Solaris a target mode framework, developed by a project team, a team that is based on the experience of some of the most senior engineers in SAN Organization. This is a direction, long time in coming, that will bring an extensible, target mode solution to Solaris. > I look forward to being able to test & find the bugs in the new > Comstar > code, but I think some people will just want the option of a stable, > usable, proven iscsi target. > Is there going to be some way to keep the option to > use the existing iscsitgt code, in a sort of parallel install with > the new > Comstar framework, so that the user has the option to enable either > the > old code, or the new Comstar code? This very subject was just discussed within the ComSTar development team, and given my experience with TCP/IP, keeping the iscsitgt code in place and functional, could be as simple as a decision between starting up iSCSI Target under ComSTar, or iSCSI Target as a Solaris process daemon as it is today. > Or will it be the case that if you want to continue with the > existing code, > then you should use Solaris 10_u4, and if you continue to use > Solaris Express, > then you will have to use the experimental Comstar code. Of course these are my somewhat, recently informed opinions, subject to change. :-) I am a firm believer in not burning bridges that one does not have to, but when the time comes, and it will, the current iSCSI Target will be no more, (except of course as a static collection of related files in OpenSolaris). > Thanks > Nigel Smith > > > This message posted from opensolaris.org > _______________________________________________ > storage-discuss mailing list > [email protected] > http://mail.opensolaris.org/mailman/listinfo/storage-discuss Jim Dunham Solaris, Storage Software Group Sun Microsystems, Inc. 1617 Southwood Drive Nashua, NH 03063 Email: [EMAIL PROTECTED] http://blogs.sun.com/avs _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
