Re: [PATCH] trace: convert init_trace_bufs() to constructor

[Julien Grall <julien@xxxxxxx>]

Hi Jan,

On 27/03/2025 15:08, Jan Beulich wrote:
> On 27.03.2025 15:49, Julien Grall wrote:
> > On 13/03/2025 13:38, Jan Beulich wrote:
> > > There's no need for each arch to invoke it directly, and there's no need
> > > for having a stub either. With the present placement of the calls to
> > > init_constructors() it can easily be a constructor itself.
> > >
> > > Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> > Acked-by: Julien Grall <jgrall@xxxxxxxxxx>
> Thanks.
>
> > > ---
> > > Same could then apparently be done for heap_init_late(). Thoughts?
> > Looking at the code, I couldn't figure out whether any of the
> > constructors may rely on some changes done by heap_init_late().
> >
> > The only issue I can think of is scrubbing. In the case it is
> > synchronous, would the memory allocated before hand be scrubbed?
> Memory that is allocated can't possibly be scrubbed; only memory that's
> still un-allocated can be. With that I fear I don't properly understand
> the question you raise.
I meant that if memory is allocated by calls from init_constructors(). 
Before this patch, the memory would be scrubbed. After this patch, 
anything constructors called before heap_init_late() would end up to not 
be scrubbed if it is synchronous.
Cheers,

--
Julien Grall