Skip to content

Conversation

miri64
Copy link
Member

@miri64 miri64 commented Mar 27, 2018

Contribution description

This is a way simpler redo of #6413. There is no network interface initialization (yet), but I plan to provide one in a follow-up. This PR just focusses on names, options and a exemplary GNRC implementation.

Issues/PRs references

Supersedes #6413.

@miri64 miri64 added Area: network Area: Networking Type: new feature The issue requests / The PR implemements a new feature for RIOT Process: API change Integration Process: PR contains or issue proposes an API change. Should be handled with care. labels Mar 27, 2018
if (netif != NULL) {
res += fmt_str(name, "if");
res += fmt_u16_dec(&name[res], netif->pid);
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does this need to be null-terminated?

{
gnrc_netif_t *netif = NULL;

if ((strlen(name) > 2) && (name[0] == 'i') && (name[1] == 'f')) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if (strncmp(name, "if", 2) == 0) {

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have the feeling this would result in bigger code size, but I agree that this is better readable.


if ((strlen(name) > 2) && (name[0] == 'i') && (name[1] == 'f')) {
while ((netif = gnrc_netif_iter(netif)) != NULL) {
char pidstr[2];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be more efficient to convert the pid part of name to uint16 before the loop and then compare within the loop:

uint16_t _pid = scn_u32_dec(&name[2], 2));
if (_pid) {
 while ((netif = gnrc_netif_iter(netif)) != NULL) {
  if (_pid == netif->pid) {
    return (netif_t) _pid);
  }
}

/**
* @brief Network interface enumeration type
*/
typedef intptr_t netif_t;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this typedef would be in the stack-specific implementation part, the API would be way more flexible.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, I wanted to do this after thinking about it a bit anyway ;-)

@kaspar030
Copy link
Contributor

Maybe an interface like this makes more sense with specific functions instead of netopt get/set?

@miri64
Copy link
Member Author

miri64 commented Apr 1, 2018

Maybe an interface like this makes more sense with specific functions instead of netopt get/set?

Does it? This would explode the API to a lot of functions (as well as the adaption layer, remember: for most stacks this is mostly piped through to the netdev).

@miri64
Copy link
Member Author

miri64 commented Apr 1, 2018

Addressed comments.

@tcschmidt tcschmidt requested a review from cgundogan May 25, 2018 10:03
Copy link
Member

@cgundogan cgundogan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the idea of having a common interface to interact with different network interfaces. I am questioning the benefit of the gnrc specific netif_get_name() function, though .. IMO interface names are meant for a better user experience. Just converting a 0 to an if0 isn't cutting it. I'd suggest something like wpan0, eth0, ... instead. I am not blocking this PR because of such trivialities, though.

Regarding @kaspar030's comment: I am leaning more towards @miri64's answer. Having a getter/setter for each option in the API will produce clutter.

So, I suggest we get this merged as soon as my minor doc related comments are addressed.

* @return next network interface.
* @return @ref NETIF_INVALID, if there is no interface after @p last
*/
netif_t netif_iter(netif_t last);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

doxygen will certainly complain here, because last is undocumented.

*
* @param[in] netif A network interface.
* @param[out] name The name of the interface. Must not be `NULL`. Must at least
* hold @ref NETIF_NAMELENMAX bytes.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like a note here, that name must be null-terminated afterwards. At least this is what the gnrc specific function is doing.

*
* @note Supposed to be implemented by the networking module
*
* @param[in] name The name of an interface. Must not be `NULL`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here again I would expect a note about null-termination. The GNRC specific function doesn't need this, e.g., but another network stack may depend on it.

@kaspar030
Copy link
Contributor

Regarding @kaspar030's comment: I am leaning more towards @miri64's answer.

Ok, I thought about it, me too. 😄

@cgundogan
Copy link
Member

Ok, I thought about it, me too. 😄

Wanna dismiss your review then? (:

Copy link
Contributor

@kaspar030 kaspar030 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

untested ACK.

@miri64
Copy link
Member Author

miri64 commented May 29, 2018

IMO interface names are meant for a better user experience. Just converting a 0 to an if0 isn't cutting it. I'd suggest something like wpan0, eth0, ... instead. I am not blocking this PR because of such trivialities, though.

Since this would require some extra logic, I could prefer to do this as a feature later-on if it is wanted.

@miri64
Copy link
Member Author

miri64 commented May 29, 2018

@cgundogan I addressed your and Travis' comments.

@cgundogan
Copy link
Member

@miri64 okay, looks good. please squash

@miri64 miri64 force-pushed the netif/api/initial2 branch from adf7ab7 to 21427fe Compare May 29, 2018 17:12
@miri64
Copy link
Member Author

miri64 commented May 29, 2018

Squashed

Copy link
Member

@cgundogan cgundogan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK

@cgundogan cgundogan added CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR CI: run tests If set, CI server will run tests on hardware for the labeled PR labels May 29, 2018
@miri64 miri64 force-pushed the netif/api/initial2 branch from 21427fe to f97db64 Compare May 29, 2018 17:49
@miri64
Copy link
Member Author

miri64 commented May 29, 2018

Fixed murdock issues.

@miri64 miri64 removed the CI: run tests If set, CI server will run tests on hardware for the labeled PR label May 29, 2018
@miri64
Copy link
Member Author

miri64 commented May 29, 2018

Only failing tests were tests/ps_schedstatistics, tests/shell, and tests/struct_tm_utility, which aren't related to this PR and according to @cladmi and @bergzand false positives. So I'm letting the tests finish, but then restart without tests activated.

@miri64 miri64 removed the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label May 29, 2018
@miri64 miri64 added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label May 29, 2018
@miri64 miri64 merged commit fce5c75 into RIOT-OS:master May 29, 2018
@miri64 miri64 deleted the netif/api/initial2 branch May 29, 2018 20:10
@miri64 miri64 mentioned this pull request Jun 4, 2018
8 tasks
@cladmi cladmi added this to the Release 2018.07 milestone Jul 10, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: network Area: Networking CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Process: API change Integration Process: PR contains or issue proposes an API change. Should be handled with care. Type: new feature The issue requests / The PR implemements a new feature for RIOT
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants