Hi Martin,

On Thu, Sep 11, 2014 at 11:12:09AM +0100, Martin Townsend wrote:
> Hi Alex,
> 
> On 11/09/14 10:53, Alexander Aring wrote:
> > On Thu, Sep 11, 2014 at 10:33:33AM +0100, Martin Townsend wrote:
> >> Hi Alex,
> >>
> >> On 11/09/14 10:01, Alexander Aring wrote:
> >>> Hi Martin,
> >>>
> >>> On Thu, Sep 11, 2014 at 09:25:56AM +0100, Martin Townsend wrote:
> >>>> Hi Alex,
> >>>>
> >>>> On 11/09/14 09:18, Alexander Aring wrote:
> >>>>> On Wed, Sep 10, 2014 at 03:06:07PM +0100, Martin Townsend wrote:
> >>>>>> Passing the skb from 6lowpan up to the higher layers is not a
> >>>>>> function of IPHC.  By moving it out of IPHC we also remove the
> >>>>>> need to support error code returns with NET_RX codes.
> >>>>>> It also makes the lowpan_rcv function more extendable as we
> >>>>>> can support more compression schemes.
> >>>>>>
> >>>>> I will ack this. But please sperate this patch in two. First renaming
> >>>>> the function namens and then removing deliver callback.
> >>>> ok, but should this not be the other way around
> >>>> moving delivery into receive and then by doing this processs_data 
> >>>> naturally becomes IPHC decompress so it can be renamed.
> >>>>> btw. The correct tag is bluetooth not linux-bluetooth, or 
> >>>>> bluetooth-next.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Also this doesn't fix anything? Then this is for bluetooth-next. I know
> >>>>> this depends on the Patch 1/3. Marcel, do you have any a nice solution
> >>>>> about this, that we can deal with huge fixes in bluetooth and new 
> >>>>> features
> >>>>> for bluetooth-next. Or simple wait when it's merged?
> >>>> I disagree, this with the previous patch fixes error handling in 
> >>>> lowpan_rcv.  By moving the skb delivery out of IPHC you automatically 
> >>>> fix the nightmare which is returning a mixture of NET_RX codes with 
> >>>> error codes.  IPHC now only returns error codes or success.  Delivery is 
> >>>> done where is should be in the receive function and can deal with NET_RX 
> >>>> codes.
> >>> ok. When this is a part of the fix and 1/3 "prepare" the fix, then put
> >>> this handling into patch "1/3" to really fix the issue from patch 1/3.
> >> I'm sorry I don't quite understand.  Are you saying that I should combine 
> >> patches 1 and 2 into a single patch?
> >>
> > So far I understand this is also part of the fix from patch 1. So it's
> > necessary to have this in one patch, means between patch 1 and 2 it's
> > still broken. Or?
> I can merge into 1 patch, makes sense to me.
> >

ok.

> > and remove the renaming. You can do that as cleanup into bluetooth-next.
> I would argue that the name must be changed as we are changing what the 
> function does and so the name doesn't match what the function now does.

yea, but code runs fine without that. It's only a very ugly name for it.
This is a cleanup.

> > - Alex
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> So my plan is to merge patches 1 and 2 into a single fix lowpan_rcv, 
> incorporate your suggestions and send to bluetooth.   Separate patch 3 into a 
> new patch for linux-wpan-next.  I think patch 3 should be to linux-wpan as it 
> is fixing the fact that we don't correctly follow RFC 4944 and support 
> fragmented IPv6 packets that have an uncompressed IPv6 header.  What are 
> you're thoughts on this.
> 

If you like to have it for the current linux kernel and it's of course a
bug fix which we should support, because we support not compressed headers
without fragmentation. Then I can't/will not say make it for -next. So
goahead to make it for wpan. I am fine with that.

> I would also be grateful for any testing by bluetooth developers as I can't 
> physically test the code changes I have made to the bluetooth 6lowpan code.
> 

I know what you mean...

I cc Jukka Rissanen, he implemented the 6lowpan stuff for bluetooth. I also
wanted that he becomes maintainer for 6LOWPAN_GENETIC too to review
the bluetooth side. Jukka what's about that... to be maintainer?

- Alex

------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel

Reply via email to