[En-Nut-Discussion] Driver configuration at runtime

[Harald Kipp]

Hi Henrik,

On 10.10.2013 12:58, Henrik Maier wrote:
> - Run-time configuration will usually always be more costly in regards
> to code, so we may even more so increase the code size of our humble
> 8-bit AVR targets.

Not necessarily, consider LAN/PHY drivers. The configurable part is
quite small. Ole's extension would not add much.


> - How are all the possible (and not possible) configuration parameters
> documented?

Bingo! It's not always the Configurator, but the lack of documentation,
that leaves newbies in the dark when trying to configure a new board.

We, the long term developers, know the structure of Nut/OS and where to
look for specific features, problems etc. We are just fine with the
source code and rarely look into the documentation. So, my wild guess
here is, that Ole tries to compensate the lack of documentation in the
Configurator by moving the configuration to the code. ;-)

(Please do not misinterpret my motivation. I still see the advantages in
Ole's suggestion.)


> But then I guess most users use nutconf only to compile Nut/OS and never
> tweak the configuration settings.

Surprisingly this is often the case, even within our company, some
people prefer the Configurator to build the libraries...strange...


> As an OS developer it puts additional burden on me as instead of adding
> a simple #define to choose a feature I have to understand LUA syntax and
> add entries to the hierarchy of conf files.

Sigh! Once again. What's so bloody difficult with these structures? It's
not Lua. Lua is simply used to define a hierarchical structure. OK, I
often forgot a bracket or a comma. But the Configurator clearly tells
you, where the problem is and it's easily fixed.

There are a few real Lua scripts too, but you don't need to touch them
when adding a new module.


> I am yet to be convinced that there are really advantages. The coding
> effort and in particular increased code size (even only for range
> checking of parameter values) is a big drawback for my opinion.

I think, the increase of code size depends on the driver and the
required configuration. For many drivers this may be marginal.

Wile I feel responsible for those very large multilevel ifdefs, I never
get tired to point to

http://www.literateprogramming.com/ifdefs.pdf

Reducing ifdefs is always a good thing, as long as it doesn't introduce
new problems. Passing structures like Ole suggested makes code more
readable. That's a fact.

It also offers additional flexibility. For example, instead of
pre-defining endless lists of LED-indication options, you may simply
provide a user-defined function, that takes care of the LEDs. Doing this
in the Configurator could become a nightmare.


> Before we roll it out at least I would like to see one or two reference
> implementations of non-trivial drivers.

Exactly, that would be great.

Regards,

Harald

P.S.: It would be also great, if you (and others) become a bit more
disciplined in quoting. E.g.

http://www.gnubg.org/index.php?itemid=11

While working on a current thread, it's easy to follow. But sometimes I
like to follow old post.