Hello,
I began to use function pointers in the 'radio_driver.h' when trying to
create a unified model for radio drivers. I guess it went over later to
the whole netdev effort.
My idea then was to have a "fast", predictable call chain from the MAC
layer to the physical radio transceiver functions: most MAC protocols
expect to run with precise delays, and a mechanism relying on message
between threads (like 'transceiver') did not fit that need.
The model of driver as structs containing function pointers is the one
used in Contiki: it seemed quite a natural way to handle the problem to
me... In their code, the needed drivers are aliased as 'NETSTACK_xxx'
macros, then functions are called by invoking 'NETSTACK_xxx.func()'.
I've never seen advanced dereferencing (->) nor object-oriented like
constructs in that context.
As P. Nikander said, since you are supposed to know your hardware at
compile time, these pointers are actually constants that should be
resolved at compile (linking) time -- even with GCC. Theoretically, it
should be translated by standard indirect calls at the assembler level.
Could you tell us more about your previous experiments? It seems quite
strange to me that such a mechanism (that seems simple to me) could
impose speed and debugging penalties.
The other question is how could we implement the network stack? Using a
mechanism like 'transceiver', that relies on message-passing between
threads, implies that there is no predictable delay for executing
network functions (one has to wait for the scheduler to switch to the
thread(s) that execute(s) the feature(s) you want to use). At some
levels -- like between MAC and PHY -- this can be a huge disadvantage.
Is there a better way to obtain deterministic/direct API calls than
using the "struct of function pointers" scheme ?...
Regards,
Le 18/02/2015 11:38, Oleg Hahm a écrit :
Dear remodeling IoTlers!
Ludwig just made me aware that Joakim's PR for NVRAM [1] introduces function
pointers as part of the device driver struct. This made me remember that there
were already similar function pointers introduced as part of netdev.
As I was always opposed to use function pointers in that way, I could not
recall what was the reason to use them for netdev. I don't like this pseudo
object oriented C style (dev->write() and the like) because we made bad
experiences with it at my former company. While writing the whole HAL for our
firmware there using function pointers this way, made programming pretty
convenient, it turned out to become problematic speed-wise and was a nightmare
to debug.
Hence, I would like to trigger a fundamental discussion on this topic. Does
anyone has a particular opinion on the topic why function pointer based
device drivers should be a good or a bad idea? And can anyone explain to me
the need of function pointers for netdev?
Cheers,
Oleg
[1] https://github.com/RIOT-OS/RIOT/pull/2353
_______________________________________________
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel
--
Kévin Roussel
Doctorant, projet LAR
Équipe MADYNES, INRIA Nancy Grand-Est / LORIA
Tél. : +33 3 54 95 86 27
kevin.rous...@inria.fr
_______________________________________________
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel
