On Thu, Dec 14, 2017 at 8:48 AM, Wojtek Porczyk <[email protected]> wrote: > On Wed, Dec 13, 2017 at 09:19:59PM -0500, Jean-Philippe Ouellet wrote: >> Hello, >> >> There are some events with specific names after a colon, e.g.: >> - device-pre-attach:block >> - device-list-attached:pci >> - property-set:netvm >> etc. >> >> and sometimes the same names show up both with and without colons, e.g.: >> in core-admin/qubes/vm/__init__.py: >> self.vm.fire_event('domain-feature-delete', feature=key) >> self.vm.fire_event('domain-feature-set', feature=key, >> value=value, >> self.vm.fire_event('domain-feature-set', feature=key, >> value=value) >> >> in desktop-linux-common/qubesappmenusext/__init__.py: >> @qubes.ext.handler('domain-feature-set:internal') >> >> I think this specific with/without colons mismatch is a bug, but >> perhaps the original intention was that two events would be fired, one >> foo-bar:specific and one foo-bar, as a means of pre-filtering which >> events you care about? I could see this being useful for e.g. >> listening on generic property-setting for all properties, but idk. > > If there is no explicit fire_*() with this name with colon (maybe calculated > as 'domain-feature-set:' + variable), this is a bug, and IIUC it will cause > the handler in qubesappmenuext (desktop-linux-common) not to fire.
Indeed. Patch here: https://github.com/QubesOS/qubes-desktop-linux-common/pull/7 I'm still not sure whether that's the right way to fix it though. Perhaps the event firing (and tests) should be changed to match the existing handler instead? Idk. > It is a general convention that events with colon are intented as generic > classes with exact instance being named after color. This should happen at > least for devices (qubes/devices.py and qubes/ext/*), which are implemented > using extensions and communicating with events. > >> Also, I wonder if perhaps event identifiers might be better as classes >> instead of strings so that we can statically catch event name >> mismatches at compile time instead of silently firing or listening for >> a typo (or other oversight) which goes nowhere / never comes. > > Having this exact concern, I wrote this tool for static analysis: > https://github.com/QubesOS/qubes-core-admin/blob/master/contrib/check-events. > However it cannot be used with automatic tests, because there are some events > that no-one currently listens for and, more importantly, when I wrote this, > there were events that were fired in extensions and handled in core. I don't > know if that's still the case. Nice :) > Also, the event identifiers sooner or later will have to be coerced to str, > because they are also forwarded over Admin API (see admin.Events, > https://www.qubes-os.org/doc/admin-api/). Also, I'd like to retain the > possibility to fire any event without constrain. But I see no reason not to > generate those with some predefined functions/classes/macros/whatever. Makes sense. >> P.S.: more documentation for qubes-core-* would be awesome > > https://dev.qubes-os.org/projects/core-admin > https://dev.qubes-os.org/projects/core-admin-client > > Sorry, but that's all we've got. It seems core-admin-client is currently > broken, but I don't know why. > > In core-admin there are some events documented on some classes, but > 1) they are not indexed AFAIK, because I don't know sphinx good enough, and > 2) because they are just strings, anyone can fire any event they wish. > > HTH. Thanks, Jean-Philippe -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/CABQWM_ARVqPycmOs7q0poEjAGMUd3jrEzGLr%2BWzKKE6RSi92%3DQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
