Re: [PATCH 01/24] XSM: reduce redundancy in hook machinery

On 7/31/26 4:03 AM, Jan Beulich wrote:
> On 30.07.2026 20:21, Daniel P. Smith wrote:
>> On 7/30/26 11:18 AM, Jan Beulich wrote:
>>> On 30.07.2026 17:05, Daniel P. Smith wrote:
>>>> On 7/28/26 9:13 AM, Jan Beulich wrote:
>>>>> Hooks not taking xsm_default_t as first argument could of course be
>>>>> adjusted to take one, at which point they could be covered here as well.
>>>>> Question is why there is this difference in the first place.
>>>>
>>>> I have a theory but I am not confident to write it down. I can see if I
>>>> can confirm with DDG if you really care that much to know the why.
>>>> Personally having a consistent hook interface convention would provide a
>>>> simpler pattern for people to follow if they are having to introdcue a
>>>> new hook.
>>>
>>> Well, I don't really need to know the reason. If you agree that making
>>> things uniform is a good move, I can simply stick a few more patches at
>>> the end of this series.
>>
>> Correct me if I am wrong, but we would be introducing an unused
>> parameter in exchange for uniform interfaces that can be generated with
>> machinery reducing hook maintenance overhead. IMHO I feel from a
>> security standpoint this would be a win. Would you disagree?
> 
> Definitely not. What I'm unsure is whether I'd call this a security related
> win. To me it's more a win in maintainability in general. Which of course
> (typically) also helps security of the resulting code.

That's what I was intending in that statement, Reducing fragility in 
code/maintenance increases stability and thus security.

v//r,
dps