Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <6d672602-55b2-fb11-2707-84bd360411f2@uni-rostock.de>
Date:   Wed, 26 Apr 2023 08:19:09 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.10.0
Subject: Re: [RFC PATCH v3] average: change non-init state and add check for
 added values
Content-Language: de-DE
To:     Johannes Berg <johannes@sipsolutions.net>, <nbd@nbd.name>,
        <linux-wireless@vger.kernel.org>
References: <20230424210430.390592-1-benjamin.beichler@uni-rostock.de>
 <a3ac7cf40706771977138a437560475b035efee4.camel@sipsolutions.net>
From:   Benjamin Beichler <Benjamin.Beichler@uni-rostock.de>
Organization: =?UTF-8?Q?Universit=c3=a4t_Rostock?=
In-Reply-To: <a3ac7cf40706771977138a437560475b035efee4.camel@sipsolutions.net>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE
Precedence: bulk

Am 25.04.2023 um 20:18 schrieb Johannes Berg:
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F
>   Achtung! Externe E-Mail: Klicken Sie erst dann auf Links und Anh=C3=A4nge,=
 nachdem Sie die Vertrauensw=C3=BCrdigkeit der Absenderadresse gepr=C3=BCft ha=
ben.
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F
>
> 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=5Frcp 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=5FMAX. 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=3F 
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=3F Should be enough to have them
> once, since we always compile the static inline functions=3F

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=5Fasserts 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=3F

Benjamin