-
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
ng_net: add global configuration options #2399
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,93 @@ | ||
/* | ||
* Copyright (C) 2015 Freie Universität Berlin | ||
* | ||
* This file is subject to the terms and conditions of the GNU Lesser | ||
* General Public License v2.1. See the file LICENSE in the top level | ||
* directory for more details. | ||
*/ | ||
|
||
/** | ||
* @defgroup net_netapi Configuration options for network APIs | ||
* @ingroup net | ||
* @brief List of available configuration options for network APIs | ||
* @{ | ||
* | ||
* @file | ||
* @brief Definition of global configuration options for netdev and netapi | ||
* | ||
* @author Hauke Petersen <[email protected]> | ||
*/ | ||
|
||
#ifndef NG_NET_CONF_H_ | ||
#define NG_NET_CONF_H_ | ||
|
||
#ifdef __cplusplus | ||
extern "C" { | ||
#endif | ||
|
||
/** | ||
* @brief Global list of configuration options available throughout the | ||
* network stack, e.g. by netdev and netapi | ||
*/ | ||
typedef enum { | ||
NETCONF_OPT_CHANNEL, /**< get/set channel as uint16_t in host | ||
byte order */ | ||
NETCONF_OPT_IS_CHANNEL_CLR, /**< check if channel is clear */ | ||
NETCONF_OPT_ADDRESS, /**< get/set link layer address in host byte | ||
order */ | ||
NETCONF_OPT_ADDRESS_LONG, /**< long link layer address in host byte | ||
order (e.g. IEEE802.15.4 EUI-64) */ | ||
NETCONF_OPT_ADDR_LEN, /**< get the default address length a | ||
network device expects as uint16_t in | ||
host byte order */ | ||
NETCONF_OPT_NID, /**< get/set the network ID (e.g. PAN ID in | ||
IEEE 802.15.4) as uint16_t in host | ||
byte order */ | ||
NETCONF_OPT_TX_POWER, /**< get/set the output power for radio | ||
devices in dBm as int16_t in host byte | ||
order */ | ||
NETCONF_OPT_MAX_PACKET_SIZE, /**< get/set the maximum packet size a | ||
network module can handle as uint16_t | ||
in host byte order */ | ||
NETCONF_OPT_PRELOADING, /**< en/disable preloading or read the | ||
current state. Preload using | ||
*send_data*, send setting state to | ||
*NETNETCONF_STATE_TX* */ | ||
NETCONF_OPT_PROMISCUOUSMODE, /**< en/disable promiscuous mode or read | ||
the current state */ | ||
NETCONF_OPT_AUTOACK, /**< en/disable link layer auto ACKs or read | ||
the current state */ | ||
NETCONF_OPT_PROTO, /**< get/set the protocol for the layer | ||
as type *ng_nettype_t*. */ | ||
NETCONF_OPT_STATE, /**< get/set the state of network devices as | ||
type *net_netconf_state_t* */ | ||
/* add more options if needed */ | ||
} ng_netconf_opt_t; | ||
|
||
/** | ||
* @brief Binary parameter for enabling and disabling options | ||
*/ | ||
typedef enum { | ||
NETCONF_DISABLE = 0, /**< disable a given option */ | ||
NETCONF_ENABLE = 1, /**< enable a given option */ | ||
} ng_netconf_enable_t; | ||
|
||
/** | ||
* @brief Option parameter to be used with *NETCONF_OPT_STATE* to set or get | ||
* the state of a network device or protocol implementation | ||
*/ | ||
typedef enum { | ||
NETCONF_STATE_OFF = 0, /**< powered off */ | ||
NETCONF_STATE_SLEEP, /**< sleep mode */ | ||
NETCONF_STATE_IDLE, /**< idle mode */ | ||
NETCONF_STATE_RX, /**< receive mode */ | ||
NETCONF_STATE_TX, /**< transmit mode */ | ||
/* add other states if needed */ | ||
} ng_netconf_state_t; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Does it make sense to put the word netdev somewhere here in between? The doc states it's for network devices, so I figured putting this into the name would make this more obvious. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. not sure, it's not dependent on netdev, so I would leave it out. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm with @haukepetersen, in theory you can apply all this states to a protocol's state machine, too. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. theoretically speaking we should then adjust the documentation to be something else than
For me, this sounds very restricting to a network device.. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 👍 |
||
|
||
#ifdef __cplusplus | ||
} | ||
#endif | ||
|
||
#endif /* NG_NET_CONF_H_ */ | ||
/** @} */ |
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.
Aren't these all netdev options?
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.
nope, they are also intended to be netapi options. For one they make sense to be used in netapi when send to the mac layer (just think of the
addr
shell command). Also you can set addresses for interfaces in the IP layer and so on. Sure some options are link layer specific, but you never implement all of them...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 was just wondering if it couldn't make sense for upper layers to enable things like autoack, too. However, this would rise the question of concurrent access again.
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.
what is "autoack"?
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.
Automatic (link layer) acknowledgments.
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.
OK, and what is "the question of concurrent access"?
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.
@OlegHahm Auto-Acking has nothing to do with ACKing of netapi commands. Or do you mean, that you would e.g. de-/activate automatic acking in TCP? That depends on the implementation and still has nothing to do with concurrent access.
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.
Again: these options are context sensitive. Some of them only make sense for link layer options, some of them make only sense for network layers and so on. But if you find a new option that you would like to set for the network layer, you try to find one that fits from this list, or you introduce a new option. This list just helps to keep available options synchronized so not every developer starts to introduce his/her own options...
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, this is more or less what I've meant. I see a problem if upper layers en/disable features like automatic acknowledgments if there's more than one running. This is where I see concurrency problems. (We discussed this during NSTF for the lower layer, where we agreed that this is a negligible problem, because we don't assume multiple modules accessing the same network interface.)