Skip to content
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

RFC: use continuous interface identifiers #4852

Closed
OlegHahm opened this issue Feb 18, 2016 · 10 comments
Closed

RFC: use continuous interface identifiers #4852

OlegHahm opened this issue Feb 18, 2016 · 10 comments
Assignees
Labels
Area: network Area: Networking Discussion: RFC The issue/PR is used as a discussion starting point about the item of the issue/PR State: won't fix State: The issue can not or will not be fixed

Comments

@OlegHahm
Copy link
Member

The current solution using the driver's PID as an identifier for a network interface is a bit uninituitive and very dependent on the actual application. Since these PIDs are stored in an array anyway, using the array index for the identifier instead, would make the identifiers continuous and persistent over all applications on the same board (as long as we don't change the initialization code).

@OlegHahm OlegHahm added Area: network Area: Networking Discussion: RFC The issue/PR is used as a discussion starting point about the item of the issue/PR labels Feb 18, 2016
@miri64
Copy link
Member

miri64 commented Feb 19, 2016

If we do this only for the user representation this should be alright I guess. Stack-internally the PIDs should still be the identifier to prevent multiple lookups and to keep them consistent to netapi. But then the documentation needs to be very precise about this dualism. Otherwise it's getting confusing, too.

@miri64
Copy link
Member

miri64 commented Feb 19, 2016

(also: I would prefer hard-coded names, when it comes to intuitive (i.e. human readable) identifiers). lwIP uses 2 letters (set by driver) plus a digit (set by initialization order). This way we also don't have to "invent" names if we ever want to support POSIX's <net/if.h>)

@OlegHahm
Copy link
Member Author

Yes, I was talking only about the user/application interface - and I would stick to the number, especially since it comes without any overhead.

@stale
Copy link

stale bot commented Aug 10, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

@stale stale bot added the State: stale State: The issue / PR has no activity for >185 days label Aug 10, 2019
@stale stale bot closed this as completed Sep 10, 2019
@miri64
Copy link
Member

miri64 commented Sep 10, 2019

This will become a must, if network interfaces are e.g. identified by pointers (e.g. with #9903)

@miri64 miri64 reopened this Sep 10, 2019
@stale stale bot removed the State: stale State: The issue / PR has no activity for >185 days label Sep 10, 2019
@stale
Copy link

stale bot commented Mar 13, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

@stale stale bot added the State: stale State: The issue / PR has no activity for >185 days label Mar 13, 2020
@stale stale bot closed this as completed Apr 13, 2020
@miri64 miri64 reopened this Apr 13, 2020
@stale stale bot removed the State: stale State: The issue / PR has no activity for >185 days label Apr 13, 2020
@miri64
Copy link
Member

miri64 commented Jun 30, 2020

@leandrolanzieri @jia200x can you please look into this?

@stale
Copy link

stale bot commented Jan 2, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

@stale stale bot added the State: stale State: The issue / PR has no activity for >185 days label Jan 2, 2021
@miri64 miri64 removed the State: stale State: The issue / PR has no activity for >185 days label Jan 4, 2021
@MrKevinWeiss MrKevinWeiss added this to the Release 2021.07 milestone Jun 22, 2021
@MrKevinWeiss MrKevinWeiss removed this from the Release 2021.07 milestone Jul 15, 2021
@stale
Copy link

stale bot commented Mar 2, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

@stale stale bot added the State: stale State: The issue / PR has no activity for >185 days label Mar 2, 2022
@stale stale bot closed this as completed Apr 19, 2022
@miri64 miri64 reopened this Apr 19, 2022
@stale stale bot removed the State: stale State: The issue / PR has no activity for >185 days label Apr 19, 2022
@maribu
Copy link
Member

maribu commented Sep 16, 2022

IMO, this can be closed as wontfix. In the GNRC stack the advantage of using more human readable identifiers doesn't justify the overhead, and with lwip identifiers are already human readable.

If anyone disagrees, please reopen.

@maribu maribu closed this as completed Sep 16, 2022
@miri64 miri64 added the State: won't fix State: The issue can not or will not be fixed label Sep 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: network Area: Networking Discussion: RFC The issue/PR is used as a discussion starting point about the item of the issue/PR State: won't fix State: The issue can not or will not be fixed
Projects
None yet
Development

No branches or pull requests

4 participants