[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] XSM SILO boot time spew



>>> On 07.11.18 at 18:52, <dgdegra@xxxxxxxxxxxxx> wrote:
> On 10/31/2018 11:19 PM, Xin Li (Talons) wrote:
>> In patchset v4, we call register_xsm() to setup silo module.
>> This debug log is to check if some ops not overrided by the module.
>> I thought this is OK, since the log level is debug.
>> 
>> I think calling register_xsm() is good,
>> if we do want to suppress this debug log explicitly,
>> we can check if ops eqauls silo_xsm_ops in macro set_to_dummy_if_null().
>> 
>> The follow diff shows what I am suggesting, is it OK?
> 
> If SILO is a good example of what a potential third XSM module would look
> like, it's probably better to just remove the printing and allow the
> dummy module's hooks to fill in any null values in the xsm_operations
> structure.  The printing part was written with FLASK and ACM in mind,
> which both intended to hook everything and might add new hooks without
> changing the other.
> 
> Another possible solution would be to add a bool parameter to register_xsm
> that disables the warnings instead of checking the pointer value, but that
> feels like overkill to me; we still only have two XSM modules.

Why? Retaining the log message for the FLASK case seems quite
desirable, and comparing pointers to special ops structures seems
quite obviously worse to me. Of course a patch to drop the logging
altogether was already posted, so you're free to ack that one and
the discussion would be ended.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.