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

ng_net: add global configuration options #2399

Merged
merged 1 commit into from
Feb 10, 2015
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
93 changes: 93 additions & 0 deletions sys/include/net/ng_netconf.h
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
Copy link
Member

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?

Copy link
Contributor Author

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...

Copy link
Member

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.

Copy link
Member

Choose a reason for hiding this comment

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

what is "autoack"?

Copy link
Member

Choose a reason for hiding this comment

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

Automatic (link layer) acknowledgments.

Copy link
Member

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"?

Copy link
Member

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.

Copy link
Contributor Author

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...

Copy link
Member

Choose a reason for hiding this comment

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

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.

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.)

*/
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;
Copy link
Member

Choose a reason for hiding this comment

The 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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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.

Copy link
Member

Choose a reason for hiding this comment

The 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.

Copy link
Member

Choose a reason for hiding this comment

The 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

the state of a network device

For me, this sounds very restricting to a network device..

Copy link
Member

Choose a reason for hiding this comment

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

👍


#ifdef __cplusplus
}
#endif

#endif /* NG_NET_CONF_H_ */
/** @} */