-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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.
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.
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.
> 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.
- --
pozdrawiam / best regards _.-._
Wojtek Porczyk .-^' '^-.
Invisible Things Lab |'-.-^-.-'|
| | | |
I do not fear computers, | '-.-' |
I fear lack of them. '-._ : ,-'
-- Isaac Asimov `^-^-_>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJaMoE+AAoJEL9r2TIQOiNREYcP/R/42hDpF6Are0gfn1FWjiVV
RMhoqumksg8DT4wJwU/B8jxY90c6OL7z/pe2V+6I3HY5yls3igAc8h0Vlihg7whk
jxs56EG6kpdM/eTorZwq1HGp7t3kjlqgBktVeIWiGaGxwwDqni5G+qfS+Cv9SvW9
LegOA0o/vXR8c7nX5uUydXXi/v4EDDyIpYEipGGA0ue9Ha6jBdOTpvoxkaAoqOor
8IesXkEccInv0GQFsz4DXMt+kNXauX87shpx+Lcdh5V4SsIw+E1jYYlUOKJyPPJr
naJLziyd4YsI22J6G7vAhSpuq2ZqGBV57F5pbLtNeH4zgpYGmSBTvHpyw4sJZ0DG
LtO89OwIwI7xH3ehMz/D0TNRJ1FTHXwUsZEsQyzXZ9caZ6iCPfkZy8M1R6gIRZ0Z
CVFU9kgXP4wwZv3rqdTAbua65oVnZR4MRvSiKPx67pEAMjRC7iXErSX1a/aTPmIl
3ULSnKQINp9ip4dK/EC3a8cxKhfSf42bugFaxCzZc3t2UA2vvCOEsIwGITasJRNg
XLf075OyRfDKxmGrClprr6pCD2cKe1u7tHIv0ev2C95Rn3rg+yzBH1QyhwsCQRMF
q4IhE6NaMINBZVZUodxxW153L56gwtvmm9xOIJ7ybt44B+zAjI5/n0HpEHyRSdYZ
V5CpdxdNAyAoIXgQVrvZ
=YKkJ
-----END PGP SIGNATURE-----
--
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 qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/20171214134850.GG3534%40invisiblethingslab.com.
For more options, visit https://groups.google.com/d/optout.
