@fnack @thomaseichinger can you port this for your driver implementations?

(if you need a guideline: see #1733)

kicked travis

I adapted the cc110x driver implementation (see #2177).

I don't quite understand why this additional function is needed. I think just makes the interface bulkier without any benefit as I don't see any need for changing the event handler PID at after initialization.

I would suggest to call a simple thread_getpid() in the netdev::init() function and save the PID to the device descriptor. This works as we expect the init function to be called in the thread context of the drivers/MAC layers thread.

You are completely right, this would simplify a lot :/. Also in that the event handler PID is more a device dependent option than a driver dependent. I'm not quite sure though, if netdev::init() is always able to be called from the thread context of the MAC layer or if the need to change it could arise.

After digging a little bit through existing driver code (and porting for this change here), I realized, that a context value (to identify the position in the device internal buffer e.g.) for the IPC call by the driver and as argument for the netdev::driver::event() function might be beneficial for some hardware. What do you think, @haukepetersen?

I would suggest to call a simple thread_getpid() in the netdev::init() function and save the PID to the device descriptor. This works as we expect the init function to be called in the thread context of the drivers/MAC layers thread.

Another open implementation detail that remains is: how does the driver identify the device of which event handler it needs to notify. Usually the devices are allocated outside of the context of the driver and the driver thus usually does not have any (hardware interface -> event handler PID)-mapping context available.

(I'm aware that this problem is not solved with this PR either ;-))

[@haukepetersen we discussed this in RL, but can you give us a pointer to the interrupt argument in the current master/one of your PRs]

About the device/driver interfaces and hw interface -> handler PID mapping: I do not understand the question.
We have a 1-to-1 mapping between device driver and MAC layer. Both are run in the same thread, namely the MAC layer thread. This thread's PID is saved in the device descriptor. This device descriptor is passed as argument to the connected interrupt routines.
--> The ISRs know the PID of the MAC layer thread and therefore know which thread to message.

About the argument for the event() call: I don't think it's necessary. All scenarios should be able to be implemented just using the one existing parameter of the event() call.

This thread's PID is saved in the device descriptor. This device descriptor is passed as argument to the connected interrupt routines.

@haukepetersen that was exactly what you told me in but can you show me how to do this?

I can try :-)

say you have

typedef struct{
    kernel_pid_t pid;
    spi_t spi;
    gpio_t rx_int_pin;
    gpio_t cs;
    netdev_t driver;
} at86xx_t;

at86xx_t dev;

as the device descriptor for an imaginable device. During initialization of your driver you call

gpio_init_int(dev.rx_int_pin, GPIO_NOPULL, GPIO_FALLING, cb, &dev);

to initialize your external interrupt line that the radio device pulls low in case new data arrives. In the callback, that is called in the interrupt routine, you do something like

void cb(void *arg)
{
    at86xx_t *dev = (at86xx_t *)arg;
    msg_t msg;
    msg.type = NETDEV_MSG_EVENT_TYPE;  // don't remember what we called the type...
    mst.content.value = YOUR_CODE_HERE;
    msg_send_int(&msg, dev->pid);
}

Now in the event loop of the MAC thread you receive this message trigger the event call

...
case NETDEV_MSG_EVENT_TYPE:
    dev->driver.event(msg.content.value);
    break;
....

finally the event function is called in the context of the MAC thread

void event(int type)
{
    switch (type) {
        case YOUR_CODE_HERE:
            // transfer data, reset status, do whatever is appropriate... e.g.
            gpio_clear(dev.cs);
            spi_transfer_bytes(dev.spi, NULL, &buf, 123);
            gpio_set(dev.cs);
        break;
    }
}

Is this what you meant?

@OlegHahm: I don't want to add a HACK n ACK candidate label unauthorized (especially as I am not taking part in the event) but I'd vote to take this PR into consideration. A lot of other PRs (#1968, #2164, #2166, #2237, ...) are depending on it, so it would be great to see this merged anytime soon!

Seems valid to me. I wasn't tracking this PR after #2163 (comment).

Ping @authmillenon, @haukepetersen . What's the status of this PR? A lot of other PR's seem to rely on this one to be merged.

@fnack this is still on the table, but netdev itself will see some major changes (see #2297), too. Also we kind of set the whole network stack implementation more or less on hold until the Network Stack Task Force Workshop next week, in hopes that we get a [more] stable model from this.

Okay, I don't like it but I guess I have to accept it. From my point of view, the restructuring of netdev will probably take a lot of time and meanwhile this PR could simplify using the current master branch.

That's up to the reviewers of this and the follow-up PRs ;-)

@fnack, I would not build on this PR yet, in my opinion is still subject to change (see #2297 for a first draft)...

Closed in favor for #2398