I appologize that I have not read the the Pull Request in detail, and thanks to overwork, I'm admitting that I probably won't have the chance. Nor am I an expert in the IEEE 802.15.4 document, where it specifies these "functions". (Maybe Tero Kivinen might help here) My alternative thoughts were to: 1) fill this in the "someday" folder, 2) delete it without comment.
I have often been frustrated that many reasonable things that we need to do
to make L3 and L2 interfaces work right are not well described by IEEE and
one winds up a situation where some mechanisms are not well taken by the STD
community because they contravene some abstract 802154 document API, when in
reality many systems do not impose hard interfaces between radio/MAC layers
and L3 users.
My question is whether or not it's worth making any link from this HAL to the
primitives that IEEE seems to suggest. It's not my goal to lock us into such
a thing (I think that would very bad), but rather to more clearly say where
are complying with the spec, and where we have intentionally done something
different. (vs unintentionally done something different)
My other request is that when there is code like:
/**
* @brief Prototype of the IEEE802.15.4 device event callback
*
* @param[in] dev IEEE802.15.4 device descriptor
* @param[in] status the status
*/
typedef void (*ieee802154_cb_t)(ieee802154_dev_t *dev,
ieee802154_tx_status_t status);
(This might not be new, but I am just latching on it)
That we might say in the description:
"such as foo_bar_blah_cb() in foo/bar/blah.c"
As the functional OOP mechanism in C can be difficult to track.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
