On 08/11/2018 10:05, Jan Beulich wrote: >>>> 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.
So I was thinking about this. I think I can arrange for the compiler to check the full-ness of the dummy and flask ops, and remove all of this runtime logic. This would be by having an interestingly typed sentinel at either end of the structure, then using a straight comma separated list of functions in the initialiser. Any change to the ops structure without a matching change in the flask and dummy ops will result in a function pointer type failure. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
