net: minimization and simplification of netdev (WIP)#2297
net: minimization and simplification of netdev (WIP)#2297haukepetersen wants to merge 3 commits intoRIOT-OS:masterfrom
Conversation
|
@thomaseichinger Are you currently working on the AT86RFxxx driver? I wasn't sure if it would make sense to go on and completely touch it... |
sys/net/include/netdev.h
Outdated
There was a problem hiding this comment.
Would vote for calling the parameter pkt now.
There was a problem hiding this comment.
Please explain how you imagine to get the source and destination address.
|
Didn't look into it in depth now (I am to tired for this right now) but from what I can gather at first glance 👍 (except the comments I already gave) |
There was a problem hiding this comment.
How are the netdev instance and the device specific type (at86..._t in your example) connected?
There was a problem hiding this comment.
Each driver has a device descriptor (a struct containing the devices run-time data). This is the same concept used for many of our device driver (e.g. sensors, network interfaces, etc). The above netdev_t struct simply forces any network device descriptor to have these two parameters on the first positions. This way you can cast any device descriptor to act as netdev_t for being used by MAC layer implementations, while the device driver internally uses it's own type (e.g.at86rf231_t).
|
Actually I wouldn't look too much into documentation details for know, I have hardly touched it (as you can see). I rather wanted a first feedback on the changes in general before I spend more time on implementing them... |
sys/net/include/netdev.h
Outdated
There was a problem hiding this comment.
I think the name event_handler is much more precise (see https://github.com/RIOT-OS/RIOT/pull/2163/files#diff-d6bffe48827d881fd19847c6af23179bR351 in #2163)
|
Please split |
|
no, I won't. Just implement preloading by:
But maybe it makes sense to give |
|
Fine with me, 👍 for renaming |
|
hm, how about |
|
Thinking about it, |
|
True. I don't really have an opinion about this name - so whatever the community likes best... |
346b989 to
21cf593
Compare
|
rebased. |
|
After talking to @thomaseichinger about the requirements of using OpenWSN with the netdev interface, I generalized it a little more by renaming The concept is that the driver is now able to signal all kind of events (standardized in Now we have a two-directional event communication between a device driver and MAC layer, |
There was a problem hiding this comment.
Is the idea to hand over the netapi_pkt_t (see #2286) struct on NETDEV_EVENT_RX_COMPLETE e. g.?
There was a problem hiding this comment.
(the structure that comes into arg for what event should be well documented is what I want to say ;))
There was a problem hiding this comment.
not quite, the idea is to hand over a pkt_t * on NETDEV_EVENT_RX_COMPLETE.
|
closed in favor of #2398 |
This PR is not meant to produce production code, but as base for discussion (I guess it won't even compile...).
I was looking at the netdev interface for the last two days and I think it has grown to complicated... Here is a proposal for simplification. One main idea is, that
netdev_tis basically a parent class for network device descriptors, meaning that structs holding the state of a network device simply are forced to have their first two members being of typekernel_pid_tandnetdev_driver_t *. The rest of the members are free to be defined by the driver itself, typically stuff like SPI device, GPIO pins used, internal state data and option fields...The major changes are:
sys/net/include/netdev.hhlists-> this code is being moved topkt.hanyhow... (pkt: Initial import #2158)netdev_tdata structureset_state(state)totrigger(action)and added actionsI further touched the
AT86RF231driver slightly, to demonstrate the usage of the netapi interface:netdev_t). All functions of the radio driver should take this struct as their first argumentI think this simplifies matters quite a bit, please let me know what you think!