-
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
netdev2: some parameter type changes #5495
Conversation
@@ -128,7 +128,7 @@ typedef struct netdev2_driver { | |||
* | |||
* @return nr of bytes sent, or <=0 on error | |||
*/ | |||
int (*send)(netdev2_t *dev, const struct iovec *vector, int count); |
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.
the int comes from how POSIX uses iovecs (see man readv
).
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.
Is there a reason to stay with posix here? Not that it would make a difference, as no iovec count should be > wordsize/2
on our boards.
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 can also use unsigned
here, because it's not really a size. I think there is no reason to stay with POSIX here. A wrapper can cast if ever want to give readv
access to netdev2
directly. Since the range of int
>0
is smaller than the one of unsigned
or size_t
we should be on the save side.
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 can also use unsigned here, because it's not really a size
did
I think I'm with you on that. Let's discuss that in #5497 and maybe change all over the place. |
BTW, I came to this error, because I tried to compile |
Now that #5497 was discussed to an extend, what's with this PR? |
Fixes #5717 ;-) |
Oops, I guess I should have searched first!
|
ACK for the change, needs fixing in the drivers though |
Done. Please Re-review. |
(per-driver commits can also be squashed down if you prefer it) |
Hmyeah, what about two commits, one for the netdev2 change, one for the drivers? |
re-ACK for the change. Murdock seem down though (502 Bad Gateway).. |
Should be back up. I'm migrating the Server it is running on. I didn't migrate murdock, yet, but was stupid enough to migrate the VPN vm that connects the build box. |
5cce180
to
5b6fb12
Compare
Done. |
@miri64 Yesterday murdock complained about wrong types in netdev2_test, did you fix those? |
5b6fb12
to
d2eebd6
Compare
nope, but did so now. |
(also fixed a squashing error). |
cc2420 and cc2538 are missing adaption. |
`len` and `count` are both values that should never go `< 0`, so instead of having to test this (in theory) every time the function is called (regardless of by assert or if its unnecessary code), I propose to change it to `size_t`. As a bonus I made the type of recv's buf parameter generic - no reason for it to be a char and it might lead to unnecessary static casting requirements
d2eebd6
to
2d09c90
Compare
Done and rebased to master to get those devices into this PR. |
Looking good, pls squash. (let's not merge before RC2 is out, because I think we can still just fast-forward). |
2d09c90
to
bd2429f
Compare
Done |
Murdock is happy. |
Well, as this is not pressing, should we wait until the release is out? Saves us the backporting edit of upcoming quickfixes... |
👍 |
recv
'slen
parameter andsend
'scount
parameter are currentlyint
, though it wouldn't make any sense to have them< 0
. We could add an assert every time this function is implemented, but I would rather vote to change the type.As a bonus I made the type of
recv
'sbuf
parameter generic - no reason for it to be achar
and it might lead to unnecessary static casting requirements (already happening in https://github.com/RIOT-OS/RIOT/blob/master/tests/driver_at86rf2xx/recv.c#L37).