search

jp-embedded / scxmlcc

The SCXML state machine to C++ compiler
GNU General Public License v3.0
140 stars 34 forks source link

Add support for inclusion of generated state machines into OS kernel code #119

Closed wizfromoz closed 3 months ago

wizfromoz commented 3 months ago

I'd like to use scxmlcc to generate a state machine that is a part of a driver I'm writing. Use of STL in kernel drivers poses some challenges (memory allocation, C++ exceptions).

It looks to me that the use of STL in generated state machines may be circumvented if the generated state machine class was a template class, where implementation classes for event queue and session id could be provided as template parameters. Maybe there's another way, but this is just the first thing that comes to mind.

I don't know why #include vector is in the generated code - std::vector doesn't seem to be used.

Do you know if anyone uses/used scxmlcc-generated code in kernel drivers? If so, what steps were done to make it work?

Thanks

jp-embedded commented 3 months ago

The option --baremetal is made for exactly this. With this it won't use STL. There are limitations though with this. Eg hierachical and parallel state machines are not (currently) supported with this option.

Including vector when not used is an error.

jp-embedded commented 3 months ago

Oh I see there has been introduced some errors with baremetal and pmr (There are no unit test for baremetal yet). I will look into fixing this.

jp-embedded commented 3 months ago

fixed in 8491ab1

wizfromoz commented 3 months ago

Thanks Jan, I wasn't aware of the "baremetal" option. I've tried your fix and I can see the generated code is different now. However, there's one thing that may still be a problem, and I encountered this when I tried to implement hand-coded state machine, but using a lot of ideas from your generated code.

The problem is with the get_state template function implementation. It's a very neat trick you did, but creates a problem in kernel environment because it introduces global static objects, and, in Windows environment for example, the compiler was generating references to at_exit function, which remained unresolved, but are no problem when using on user level code.

I solved this by declaring a member variable per each state class in the state machine class and then doing the switch by using pointers to those members. Maybe there's a better solution, but I'm working on some proof of concept code and didn't want to get stuck on this. Just to let you know...

jp-embedded commented 3 months ago

Thanks for your info. Maybe I should look into this get_state method. It would be nice to get rid of those static objects. Now even more with your arguments :-)

jp-embedded commented 3 months ago

And also the baremetal and other options should be documented :)

wizfromoz commented 3 months ago

Thanks Jan. Yes, that would be great if you could eliminate the need for global objects, as the code that calls their constructors and destructors is highly dependent on the environment and possibly very hard to interfere with, if your environment is different from the standard, user level application development.