Re: [PATCH v2 bluetooth-next] Simplify lowpan receive path so skb is freed in lowpan_rcv when dropped.

[Alexander Aring <alex.aring@gmail.com>]

Hi Martin,

On Mon, Sep 08, 2014 at 08:36:52PM +0200, Alexander Aring wrote:
> Hi Martin,
> 
> On Mon, Sep 08, 2014 at 07:13:02PM +0100, Martin Townsend wrote:
> ...
> > >>Hi,
> > >>
> > >>I'll respin and include the memory leak fix and this patch and a couple of
> > >>others I have and send as a series to bluetooth.  What bluetooth git
> > >>repository should I base the series on?
> > >>
> > >What's the state about to fix this bad issue? :-)
> > >
> > >I didn't saw any new patches because of this.
> > >
> > >- Alex
> > >--
> > >To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
> > >the body of a message to majordomo@vger.kernel.org
> > >More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> > Sorry for the delay, been on hols for a few days, I will create the patches
> > tomorrow if I get time.
> > 
> > I have also implemented Generic Header Compression[0] which is still in
> > draft at the moment but I can't imagine it will change much before being
> > released.  I'm going to integrate it into our linux repository this week.
> > Would you be interested in putting it in linux-wpan or linux-wpan-next or
> > would you prefer to wait until it gets it RFC status?
> > 
> 
> no, for me it's okay to have this mainline. I heard that a draft becomes
> no RFC when nobody implements it.
> 

I thought more about that, you mean the receiving part only? So the
uncompression. The point is that we don't have no interface for an user
that can decide if he like to use UDP compression like RFC 6282 or UDP
compression like GHC. This is only relevant for the transmit part. So
compression is optionally. (We should have some interface to make this
configurable by user -> adding this to the nhc layer, later).

On the uncompression part, means the receiving part we can support both.
UDP RFC 6282 or UDP like GHC, the next header id value should be
different there. That means currently we can receive every packets but
transmit only RFC6282 compression formats.

So for receiving this, it's okay. But for compression, since we don't
have some interface to make this configurable we should use RFC 6282.


Same opinion here? We can talk about that point.

- Alex