[subexp-daq] NURDLIB: Init fast vs Init slow for modules

Hans Toshihide Törnqvist hans.tornqvist at chalmers.se
Thu Feb 29 18:04:19 CET 2024


Dear Günter,


Here is a hopefully quick summary of the not so long nurdlib history 
(tl;dr at the bottom):


The idea of two init functions came from the v1290, which has a 
controller for many settings that is really slow to talk to. 'init_slow' 
would do the slow configs which one does not want to sit through too 
much, and 'init_fast' the faster ones.

The crate calls 'init_slow' for all modules, does some checks, calls 
'init_fast' for all modules, and for certain modules also calls an 
optional 'postinit'.

Later came the idea to do online configuration while a DAQ is running. 
Rather than splitting the init functions (or my mind) even further, 
'init_slow' was taken as the non-online part (e.g. mapping) and 
'init_fast' the online part (e.g. writing thresholds). Some controller 
drivers have been buggy and reducing re-maps has been important.

Obviously, it turned out that some, or most, slow writes on the v1290 
were useful to do online, so lots of things in 'init_slow' moved over to 
'init_fast'. Voila, the names don't really make sense any longer...

The online feature has higher priority than the re-initialisation 
nowadays, since the latter should be rare in a properly working setup. 
Eventually there should be a refactoring which is great since it changes 
so much at once. I even have another one ready to go into 'master', but 
I didn't dare to push that onto others yet.


Now for the useful tl;dr part :)

Put mapping and things that should not be changed online in init_slow, 
and everything else in init_fast. Everything that comes from 
'config_get_*' could be changed online, I think.


Cheers,
Hans

On 2024-02-29 17:00, Weber, Guenter Dr. wrote:
> Dear friends,
> 
> 
> is there a clear rule what should happen in the two init routines? In 
> which cases INIT SLOW is executed and how is that different from INIT FAST?
> 
> 
> 
> Thanks a lot!
> 
> 
> 
> Best greetings
> 
> Günter
> 
> 
> 
> 


More information about the subexp-daq mailing list