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

["Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>]

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