We are aware of this issue and it is in discussions within the project team. It will not be possible to develop and maintain both current iscsi target and a iscsi transport in comstar. How to keep existing functionality, have minimum impact on customers, if we were to keep the existing target daemon then how to package it (install, optional install etc.) is something we will evaluate before comstar will be integrated into solaris.
Sumit > 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. > 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? > 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. > Thanks > Nigel Smith This message posted from opensolaris.org _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
