Received-SPF: pass (google.com: domain of linux-kernel+bounces-153878-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Message-ID: <d046d195-6fa3-4c52-bc5f-3e5e763bc692@linux.intel.com>
Date: Mon, 22 Apr 2024 10:52:17 -0500
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 00/14] ASoC: Constify local snd_sof_dsp_ops
To: Krzysztof Kozlowski <krzk@kernel.org>, Liam Girdwood
 <lgirdwood@gmail.com>, Peter Ujfalusi <peter.ujfalusi@linux.intel.com>,
 Bard Liao <yung-chuan.liao@linux.intel.com>,
 Ranjani Sridharan <ranjani.sridharan@linux.intel.com>,
 Daniel Baluta <daniel.baluta@nxp.com>,
 Kai Vehmanen <kai.vehmanen@linux.intel.com>, Mark Brown
 <broonie@kernel.org>, Jaroslav Kysela <perex@perex.cz>,
 Takashi Iwai <tiwai@suse.com>, Shawn Guo <shawnguo@kernel.org>,
 Sascha Hauer <s.hauer@pengutronix.de>,
 Pengutronix Kernel Team <kernel@pengutronix.de>,
 Fabio Estevam <festevam@gmail.com>, Matthias Brugger
 <matthias.bgg@gmail.com>,
 AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Cc: sound-open-firmware@alsa-project.org, linux-sound@vger.kernel.org,
 linux-kernel@vger.kernel.org, imx@lists.linux.dev,
 linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org
References: <20240414-n-const-ops-var-v1-0-8f53ee5d981c@kernel.org>
 <89f8f0be-2534-46c8-9058-cabea4f68568@linux.intel.com>
 <9d1eda85-32a0-4e53-86ca-ce3137439bd7@kernel.org>
Content-Language: en-US
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
In-Reply-To: <9d1eda85-32a0-4e53-86ca-ce3137439bd7@kernel.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit


On 4/22/24 00:43, Krzysztof Kozlowski wrote:
> On 15/04/2024 16:19, Pierre-Louis Bossart wrote:
>>
>>> The core code does not modify the 'struct snd_sof_dsp_ops' passed via
>>> pointer in various places, so this can be made pointer to const.
>>
>> The structure itself is NOT always const - the initialization itself
>> does have platform-specific changes, so what do we really gain from all
>> this?
> 
> In the context of these patches, the structure is *always* const. In
> other drivers, it is not, but they are not really relevant here.
> 
>>
>> some commit messages say the code is "a bit safer", but I personally
>> find the 'const' more confusing since the information that the structure
>> can be modified during initialization is lost.
> 
> Functions which take some data and do not modify it are easier to read
> if the pointed data is marked as const. Then it is obvious that
> functions for example is re-entrant. Or that it does not affect the
> state of other devices/core structures.
> 
> Additionally, the static data is safer when is const, because it cannot
> be used in some attacks.

agree, but here you are marking as 'const' non-static data.

> I really do not understand which information you lost here? Core does
> not change the ops, so the data should be passed as const as often as
> possible. If anyone wants to write a driver which does not use static
> ops, but somehow dynamically allocated and changed, nothing stops him.
> This patch did not make it less readable/doable.
> 
> The point is that these ops do not differ from other ops or some other
> driver-passed structures, which we have around 100 already in checkpatch.

I am so old that I remember times where we had to put things in ROM.
That's what 'const' means to me: a dedicated memory space for immutable
values.

that's a different interpretation to the 'software' view you're
describing. "this structure will not modified by this function" is not
the same thing as "this structure CANNOT be modified".

I am not going to lay on the tracks, if Mark wants to apply the patches
that's fine. I just wanted to highlight that the reason we did not use
'const' was that the data is dynamically allocated/modified and not
constant at all.