| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Currently the receiver fetches an imsg via imsg_get() and if he expects
an fd, he then calls imsg_get_fd() to fetch the next fd queued on the
imsgbuf from which the imsg came.
This changes hides the fd queueing mechanism to the API user. When closing
an imsg with an fd, the message is flagged so that the receiving end knows
it must dequeue the fd in imsg_get() and return it with the imsg structure.
This way there is no (less) possible screw up from imsg_get_fd() not being
called directly after imsg_get() by the user. The retreived imsg is
self-contained.
ok pyr@, "I like that" henning@
|
|
ok pyr@
|
|
Stop pushing event handling in the imsg framework.
Instead, provide a small glue layer on top of both imsg and libevent.
This finally clearly separates event handling and imsg construction.
Sidetrack bonus: remove the mega-ugly hack of having a dummy imsg_event_add
stub in relayctl.
This will make bgpd (and thus henning) happy. Next up are smtpd and ospfd.
ok eric@
|
|
imsg_event_add function to be provided (which ended up being a named
callback).
Instead provide a wrapper in the daemon and call that everywhere.
Previsously discussed with the usual suspects,
ok eric@ though not too happy about the function name
(imsg_compose_event).
|
|
ok pyr@
|
|
|
|
a SNMP trap when the state of a host changes. relayd(8) will try to
(re-)connect to snmpd(8) and request it to send a trap to the
registered trap receivers, see snmpd.conf(5) for more information
about the configuration.
ok pyr@ thib@
|
