Am 25.04.2023 um 20:18 schrieb Johannes Berg:
________________________________
Achtung! Externe E-Mail: Klicken Sie erst dann auf Links und Anhänge, nachdem Sie die Vertrauenswürdigkeit der Absenderadresse geprüft haben.
________________________________
On Mon, 2023-04-24 at 21:04 +0000, Benjamin Beichler wrote:
The uninitialized state 0 involves the danger of reaching that state in
normal operation. Since the weight_rcp value needs to be bigger than one
(otherwise no averaging takes place), the final shifting in add ensures,
that the internal state never reach ULONG_MAX. Therefore use this value
to signal, that the ewma has no initial value.
The add function needs to check, that val is not to big, otherwise the new
value can overflow the internal state, which results in unexpected outputs.
This seems nice to me, FWIW.
Okay. I would split up the patch into sensible parts and send it later.
You are also fine with the extra init function with explicit init value?
Of course this one also needs the check, that it really fits into the
internal state :-D
Move the compile time checks into a separate macro, as they are used
multiple times and noise up the functions.
Why do we even have those multiple times? Should be enough to have them
once, since we always compile the static inline functions?
Good question ... my assumption was, that the build-bug macro may not
work, if the function is unused and maybe optimized away, but I'm not
that familiar with those details. I'm more in favor with the
static_asserts of C++, which have defined semantics. :-D
It would be nice to put the check into the struct, as some zero size bad
member, but I found no example in the kernel, so maybe this is not
easily doable.
One may argue, that we only put it in init and if the users do not use
init, we call it shit-in-shit-out, but I'm not really in favor of that.
Anyone with more experiences on build time asserts in the kernel?
Benjamin
