>>> On 07.11.18 at 18:52, <dgde...@tycho.nsa.gov> 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@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
