[Xen-devel] Re: netback commit history

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

On Tue, 2011-09-20 at 12:04 +0100, Jan Beulich wrote:
> Hi Ian,
> 
> with the upstream netback introduction consisting of a single big commit
> I wonder whether you could point me to where the full history of it is.

Yeah, that was a bit annoying, luckily I had the foresight to post where
the history was. http://www.gossamer-threads.com/lists/xen/devel/202139
says it is:
        git://xenbits.xen.org/people/ianc/linux-2.6.git 
upstream/dom0/backend/netback-history 

> I'm asking particularly in the context of us being asked to add a safety
> check similar to the vif->netbk != NULL one at the beginning of
> xenvif_start_xmit() (also in xenvif_interrupt(), but there we have a
> similar check in place), which hadn't been in the legacy tree (obviously)
> nor in the original multiple-tasklets patch that I retained a copy of.

Seems to have come from bc05ada1283eb583c9789c27429af36b034c4a74 in that
history tree and was a conversion from a check for group == -1. That
commit changes from storing a group index to a group pointer so I think
it's roughly equivalent from a validity point of view.

The original group == -1 check appears to be in the 2.6.32.x pvops
kernels at least, I expect it is also in the multiple tasklet patch
which you have as well?

>  That
> is, I'd like to understand the reasons for this check as it seems wrong
> to me to have to do it there - I'd rather think that if an interface got
> disabled, execution shouldn't even reach that function anymore.

Yes, I'd think that too but I don't really know. Maybe Dongxiao
remembers why he added it?

> One thing I wonder about in this context is whether the
> netif_stop_queue() call from xenvif_close() shouldn't happen before
> xenvif_down() (not the least for reasons of symmetry with
> xenvif_open()).

I seem to recall looking at that too, it was the same in the old kernels
too and I didn't know why so I avoided touching it (I was doing too much
other cleanup at the time to risk it).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel