Hi Marcel,
Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote:
> I am not sure that 6LoWPAN long-term should be a compile time option of
> IPv6. However that is certainly a possibility. If we want to discuss that, then it
> needs to be a discussion on the netdev mailing list with the netdev folks.
>
> Initially the direction was to go for net/6lowpan/ and make 6LoWPAN a
> subsystem of its own. Making it part of IPv6 would mean this has to move into
> net/core/ and that needs convincing of the netdev folks.
>
> My viewpoint of 6LoWPAN subsystem was always that besides compression, it
> actually becomes a full net_device abstraction. So instead of BLE and 802.15.4
> allocating net_device on its own, we have something like lowpan_netdev that
> gets allocated by each subsystem. And then you just provide the framing
> functions that take the encapsulated frames and transport it over the bearer.
> Right now we are doing a lot of duplication in each subsystem to support
> 6LoWPAN. The less it takes to hook up 6LoWPAN to new bearers, the better.
> Moving the compression into a separate module was just the first step.
>
> Regards
>
> Marcel
Thanks a lot for your feedback and valuable comments.
I hope it is okay that I am responding using the new mail thread.
As you might have noticed I have resubmitted the RFC patch after
addressing your comments in a new thread, and split the patch
into smaller parts.
The idea of making an abstraction of lowpan_dev sounds like a good idea,
but I'm not sure if I'm grasping the details involved. Could you please
elaborate a bit more on you proposal?
Is the structure like below something you had in mind for lowpan_dev?
struct lowpan_dev { // Struct build-in /net/core like wpan_dev
net_device * net_dev; // Pointer to net device
FUNC_PTR tx_xmit; // Transmit function in the subsystem
(assigned on the registration of a
lowpan_dev)
FUNC_PTR decompress; // Is called after receive of new data from
the subsystem. But how to deliver such data,
for example by creating lowpan_dev_rx() API?
FUNC_PTR compress; // Is called when net_device sends packet to
lowpan_dev (xmit).
FUNC_PTR handle_ra; // Is called when ndisc.c finds lowpan options
e.g. 6CO.
}
struct net_device {
...
lowpan_dev * lowpan_dev_ptr;
...
}
For now 6CO is the only flag that I am currently interested in, but with
such structure, it could easily be extended to handle other message types.
Having the pointers to compress/decompress and to act upon lowpan options,
allow us to keep 6lowpan as a module in /net/6lowpan. Could this work?
Or you are proposing to completely move IP Header compression mechanism to
lowpan_dev implementation (built-in - /net/core)?
Best regards,
Łukasz Duda
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
