On Monday 10 February 2014 16:23:48 Courtney Cavin wrote: > While I'm not sure the dislike of notifiers entirely justifies not using > them here, where they seem to make sense, I can understand that they > might not fully implement what we need to expose. I think we need to look at a few more examples of things that people want to with the framework to come up with a good interface. It's possible that we end up with multiple alternative notification methods, but it would be good to come up with one that works well for everyone. > Regarding handlers running in IRQ context: currently the API is designed > to do just that. From the use-cases I've found, most message handlers > simply queue something to happen at a later point. This is logical, as > the callback will be async, so you'll need to swap contexts or add locks > in your consumer anyway. Right. You may also have some handlers that need to run with extreme latency constraints, so we need at least the option of getting the callback from hardirq context, or possibly from softirq/tasklet as in the dmaengine case. > The dma engine is large and confused, so I'm not sure entirely which > part you are refering to. I've looked at having async completion going > both ways, but what I see every time is code complication in both the > adapter and in the consumers in the simple use-case. It doesn't really > make sense to make an API which makes things so generic that it becomes > hard to use. What I tried to follow here when designing the API was > what I saw in the actual implementations, not what was future-proof: > - Message receive callbacks may be called from IRQ context > - Message send implementations may sleep I can imagine cases where you want to send messages from softirq context, or from the same context in which you received the incoming mail, so it would be good to have the API flexible enough to deal with that. As a first step, always allowing send to sleep seems fine. Alternatively, we could have a 'sync' flag in the send API, to choose between "arrange this message to be sent out as soon as possible, but don't sleep" and "send this message and make sure it has arrived at the other end" as you do now. > What I can do is try to alleviate implementation efforts of future > requirements--as honestly, we can't really say exactly what they are--by > turning the messages into structs themselves, so at a later point flags, > ack callbacks, and rainbows can be added. I can then stop using > notifiers, and re-invent that functionality with a mbox_ prefix. I don't think there is a point in reimplementing notifiers under a different name. The question is rather how we want to deal with the 'multiple listener' case. If this case is the exception rather than the rule, I'd prefer making the callback API handle only single listeners and adding higher-level abstractions for the cases where we do need multiple listeners, but it really depends on what people need. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
