-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sock: doc fixes #5884
sock: doc fixes #5884
Conversation
Also includes the HOWTOs requested by @emmanuelsearch. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had a "brief" look at this one and put some comments (typo, rephrasing). Good job !
* they serve as a common API that connects application- and network stack code. | ||
* This module provides a set of functions to establish connections or send and | ||
* receive datagrams using different types of protocols. Together, they serve as | ||
* an API allows an application or library to connect to a network. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that allows
or allowing
* Implementors Notes | ||
* ================== | ||
* ### Type definition | ||
* For simplicity and modularity this API doesn't put any restriction of the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
on the
* ### Type definition | ||
* For simplicity and modularity this API doesn't put any restriction of the | ||
* actual implementation of the type. For example, one implementation might | ||
* choose to have all `sock` types have a common base class or use the raw IP |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
types having
* res = sock_ip_send(NULL, data, data_len, PROTNUM, &remote); | ||
* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
* | ||
* With `data` being the data send, `data_len` the length of `data`, `PROTNUM` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
data sent
* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
* | ||
* With `data` being the data send, `data_len` the length of `data`, `PROTNUM` | ||
* the next header number for the send packet and `remote` the remote end point |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sent packet
* } | ||
* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
* | ||
* We then create a remote end point for the link-local all nodes multicast |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not sure I correctly understand this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you tell me how you understand it I maybe can clear that up. As is the sentence seems straight forward to me... :-/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if I understand well (I hope I do ;) ), I would rephrase like this :
create a remote end point with the link-local multicast address of all nodes and send
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not completely. It creates a remote end point with the link-local all-nodes multicast address (which is a defined address (ff02::1
) and is called as such)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Better now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, thanks for the clarification :)
* @return -EAFNOSUPPORT, if `local != NULL` or `remote != NULL` and | ||
* sock_ip_ep_t::family of @p local or @p remote is not supported. | ||
* @return -EINVAL, if `proto` is not supported or if sock_ip_ep_t::netif of | ||
* @p local or @p remote is not a valid interface or contradict each | ||
* other (i.e. `(local->netif != remote->netif) && | ||
* ((local->netif != SOCK_ADDR_ANY_NETIF) || | ||
* (remote->netif != SOCK_ADDR_ANY_NETIF))` if neither is `NULL`). | ||
* @return -ENOMEM, if the stack can't provide enough resources for `sock` to | ||
* be created. | ||
* @return -ENOMEM, if not enough resources for `sock` to be created can be |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
strange rephrasing ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe ... not enough resources can be provided for sock
to be created ?
* uint8_t buf[128]; | ||
* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
* | ||
* To be able to listen for incoming packets we want to bind the sock so we need |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we want to bind the sock so we need, etc
=> we bind the sock by setting a local end point with a port ?
* } | ||
* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
* | ||
* We then wait indefinitely for an incoming message in `buf` from `remote`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think using 'we' when explaining the behavior of the code should be replaced with something more non personal.
Example:
The program then wait indefinitely for an incoming message...
* With `data` being the data send, `data_len` the length of `data` and `remote` | ||
* the remote end point the packet is to be sent. | ||
* | ||
* To see some other utilization we look at a more complex example in form of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
usage
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See #5884 (comment)
Applied requested changes. |
* choose to have all sock types have a common base class or use the raw IP | ||
* sock type to send e.g. UDP packets, while others will keep them | ||
* completely separate from each other. | ||
* Note that there might be no relation between the different `sock` types. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think users might try that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
People tried it with conn
so why wouldn't they try it with sock
?
* The actual code very much depends on the used `sock` type. Please refer to | ||
* their documentation for specific examples. | ||
* | ||
* Implementors Notes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Implementors -> implementor?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a caption... Why should I remove the capitalization?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
just remove the plural s at the end of Implementors, capital I is fine. |
Someone tried to re-cast the objects into each other? |
oops I actually overlooked that. |
Yes some testers get funny ideas when you do not explicitly state that a behavior is forbidden ;-). And actually I can understand that when you come from the socket world. Also: casting |
Mind you, they didn't cast a |
I just tried testing this and I get a missing "sock_types.h' from udp.h:198, I have gnrc_sock_udp and gnrc_ipv6_default included. I also cannot find sock_types.h anywhere in the codebase. Any tips? |
My humblest apologies, I did not see #5772. |
Ping? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like a good documentation with good examples.
@aabadie was that an ACK? |
@miri64, Murdock is asking for squashing. Then I'll give an ACK. |
Squashed. |
Murdock is happy 😀 |
ACK and Go ! |
Fixes the comments in #5758.