Because the devi-* framework is multithreaded, you should be aware of a possible reentrancy issue. When a devi-* driver is invoked, a module may be specified multiple times, where each invocation will belong to a separate event bus line.
An example is the keyboard controller device module (kb). This module can communicate with a keyboard and with a PS/2 mouse. We would invoke the driver as follows:
devi-hirun kbd kb ps2 kb -2
Here we'll have two event bus lines: one for the keyboard and one for the mouse. Upon initialization, the input framework will use the static kb data structure (input_module_t) for one of the bus lines and dynamically allocate/copy another one for the other bus line.
If you keep your module-specific data confined to the private data member of the module structure, you won't have any problems with reentrancy. But if your module contains global variables, then you'll have to use some sort of mutual exclusion mechanism for protection.
Note that you don't have to ensure that the init(), reset(), and parm() callbacks are reentrant, because they're always called from a single thread upon initialization. (However, if for some reason you need to call them when the runtime system is up, then you'd have to ensure that they're reentrant.) The callbacks used at runtime (e.g. the pulse() callback) are the ones at risk.
For more information, see the keyboard controller module code (hirun/kb.c).