Re: [linux-iscsi-devel] Re: 5.x branch mainline kernel push in two weeks?

[Dmitry Y. <dmi...@ya...>]

On Wed, 2005-04-20 at 12:10 -0700, Mike Christie wrote:
> Dmitry Yusupov wrote:
> > On Wed, 2005-04-20 at 11:43 -0700, Mike Christie wrote:
> > 
> >>Dmitry Yusupov wrote:
> >>
> >>>On Wed, 2005-04-20 at 01:18 -0700, Mike Christie wrote:
> >>>
> >>>
> >>>>Dmitry Yusupov wrote:
> >>>>
> >>>>
> >>>>>On Mon, 2005-04-18 at 20:13 +0200, Christoph Hellwig wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>>One important thing that needs working out is the proper splitup between
> >>>>>>scsi_transport_iscsi, iscsi_if and iscsi_tcp.  The current split is not
> >>>>>>so nice, we really only want one transport class thing, so iscsi_if
> >>>>>>should merge into scsi_transport_iscsi.
> >>>>>
> >>>>>
> >>>>>Exactly what I was thinking of. I always had a thought that having
> >>>>>iscsi_if and scsi_transport_iscsi separated is not very clean from
> >>>>>mainline kernel perspective.
> >>>>>
> >>>>>iscsi_if should just disappear and be part of scsi_transport_iscsi.
> >>>>>
> >>>>>One potential issue with that is that other initiators relying on it.
> >>>>>So, this merge should be backward compatible at least for a while, so it
> >>>>>will not break much existing initiators. I care only about 4.x branch
> >>>>>frankly.
> >>>>>
> >>>>
> >>>>I do not think backaward compat should be a concern.
> >>>>
> >>>>For 4.x, we are set. People that want new stuff should be testing out 
> >>>>open-iscsi, so there is no worry about upgrading kernels and breaking crap.
> >>>
> >>>
> >>>ok. that is even easier. do you have some immediate plan to work out
> >>>this merge or should I come up with initial merged result?
> >>>
> >>
> >>Just cook up a patch. If you are asking becuase you have no time I can
> >>do this for you though. It does not matter to me.
> > 
> > 
> > Would be nice. Thanks!
> > 
> 
> ok I think I can get access to a qlogic card this weekend (when IBM is 
> not using it for distro testing) so let me try to hack on that at the 
> same time. I had been looking at replacing their ioctl with my sysfs 
> creation stuff in the past so hopefully I can get up to speed pretty 
> quickly on adapting the netling sutff to it instead.

really cool!

meanwhile I'm having discussion about some interface changes for iSER/IB
(voltaire). So far, their iSER/IB stuff fits very well into existing API
with few minor changes in set_param() and get_param().