When I was implementing my first driver at work, I was a bit surprised that the OS (WinCE) wasn’t providing a mechanism for notifying the application from the driver. Of course, I cleverly used a named event to accommodate for the missing “feature” of the OS.

And of course, this was wrong. And I wasn’t alone in my mistake. I saw other colleagues, as well as people on the web (here is an example from Stackoverflow) trying to do the same. So I think this is a good mistake to share, especially for rookies in driver development. Continue reading Rookie mistake: kernel to user-space notification →

In contrast to application software, embedded software generally have multi-threaded designs. The main driving factor behind this is a complex environment in which multiple events are occurring in parallel: user(s), inputs from peripherals or network etc. Drivers in particular are also affected in this context, maybe even more so as because they may be servicing multiple applications and HW components simultaneously. In addition, the driver models of OSs are generally not very specific about threading models, therefore the drivers become passive servers of multi-threaded and sometimes buggy clients, which makes it hard to foresee which function of the driver will be called when.

So, this context prepares almost all conditions for several race conditions. In my experience, most race conditions are caused by a few common situations, and in this post I’d like to summarize my knowledge about them. Continue reading Common race conditions in drivers →

In this post I’d like to reuse one of my previously written pieces. I wrote it as part of a take-home exam for a software architect training program at Siemens^[1]SSWA, Senior Software Architect training program. I believe ;-) the copyright is still with me.. We were asked to choose and elaborate on a quote about “late phases”, i.e. the stuff that happens to your software after it is released.

The thing the ecologically illiterate don’t realize about an ecosystem is that it’s a system. A system! A system maintains a certain fluid stability that can be destroyed by a misstep in just one niche. A system has order, a flowing from point to point. If something dams the flow, order collapses. The untrained might miss that collapse until it was too late. That’s why the highest function of ecology is the understanding of consequences.
— Pardot Kynes in “Appendix I: The Ecology of Dune”, Frank Herbert, Dune Continue reading Late phases and ecology →

The Pareto principle (aka. the 80/20 rule), which tells us that at 20% of the cost we can realize 80% of the value, is applied widely and IMHO wisely in SW development.

In this post, I’d like to direct your attention to the remaining 20% of the value. Let us define  a “simple” SW release as a release for which you don’t need to take into account aspects like: Continue reading The boring part of the 80/20 rule →