[Linux] DnssdImpl: rework avahi implementation#26397
Conversation
|
PR #26397: Size comparison from ed8d546 to 87454a7 Increases (1 build for cc32xx)
Decreases (1 build for cc32xx)
Full report (3 builds for cc32xx, qpg)
|
|
PR #26397: Size comparison from ed8d546 to dd264c7 Increases (3 builds for nrfconnect)
Decreases (3 builds for mbed, nrfconnect)
Full report (4 builds for mbed, nrfconnect)
|
dd264c7 to
4092aca
Compare
|
PR #26397: Size comparison from 6c0c5ea to 4092aca Increases (1 build for cc32xx)
Decreases (1 build for cc32xx)
Full report (1 build for cc32xx)
|
2df2786 to
0dbeeab
Compare
|
PR #26397: Size comparison from 69aaacd to 0dbeeab Increases (12 builds for bl702, cc32xx, esp32, k32w, psoc6, telink)
Decreases (11 builds for bl602, bl702, cc32xx, psoc6, telink)
Full report (57 builds for bl602, bl702, cc32xx, cyw30739, efr32, esp32, k32w, linux, mbed, nrfconnect, psoc6, qpg, telink)
|
ceec371 to
a0c2268
Compare
|
PR #26397: Size comparison from f467d6f to a0c2268 Increases (20 builds for bl702, cc32xx, esp32, psoc6, telink)
Decreases (7 builds for bl602, bl702, psoc6, telink)
Full report (57 builds for bl602, bl702, cc32xx, cyw30739, efr32, esp32, k32w, linux, mbed, nrfconnect, psoc6, qpg, telink)
|
a0c2268 to
4ce69b2
Compare
|
PR #26397: Size comparison from 1c694cf to 4ce69b2 Increases (15 builds for bl702, bl702l, cc32xx, nrfconnect, psoc6, telink)
Decreases (8 builds for bl702, esp32, nrfconnect, telink)
Full report (58 builds for bl602, bl702, bl702l, cc32xx, cyw30739, efr32, esp32, k32w, linux, mbed, nrfconnect, psoc6, qpg, telink)
|
|
The failing Darwin tests don't have anything to do with this Linux-only PR, correct? Just asking in case I should do something to help getting the PR through. |
|
@plan44 Just rebasing to tip should fix the darwin tsan failure there (that test has been disabled for now). What this PR needs is review from someone familiar with the avahi bits... @yunhanw-google @andy31415 |
4ce69b2 to
6a90d6c
Compare
|
PR #26397: Size comparison from 488aabf to 6a90d6c Increases (18 builds for bl602, bl702, bl702l, cc32xx, esp32, psoc6, qpg, telink)
Decreases (16 builds for bl702, bl702l, cc32xx, cyw30739, efr32, k32w, psoc6, telink)
Full report (58 builds for bl602, bl702, bl702l, cc32xx, cyw30739, efr32, esp32, k32w, linux, mbed, nrfconnect, psoc6, qpg, telink)
|
|
Now the Linux Test Suite fails, apparently related to mDNS. But judging from the log that test is not even using the Avahi implementation but minimal mDNS. I might be wrong, but I'm currently failing to understand the details of the error. |
…ressIterator Required for improving dns-sd avahi based implementation
This commit fixes two problems with the previous avahi based dns-sd implementation: - Publishing more than one service at the same time did not work. This needs to be possible e.g. when a node is commissioned into multiple fabrics. The previous implementation falsely assumed that additional services can be added to already committed (=published) AvahiEntryGroup, which is not the case. An AvahiEntryGroup can only publish multiple services ALL AT ONCE. The new implementation creates a new AvahiEntryGroup per service, on demand. - The previous implementation took ownership of the platform-global default hostname, (by overwriting it). This is not a good idea because the default hostname is usually of relevance for other non-matter services on a given Linux platform. The new implementation establishes the matter-mandated MAC-derived hostname separately and explicitly adds interface addresses.
(found by code-lints)
6a90d6c to
d9777fc
Compare
* InetInterface: add IsLoopback() to InterfaceIterator and InterfaceAddressIterator Required for improving dns-sd avahi based implementation * [Linux] DnssdImpl: rework avahi implementation This commit fixes two problems with the previous avahi based dns-sd implementation: - Publishing more than one service at the same time did not work. This needs to be possible e.g. when a node is commissioned into multiple fabrics. The previous implementation falsely assumed that additional services can be added to already committed (=published) AvahiEntryGroup, which is not the case. An AvahiEntryGroup can only publish multiple services ALL AT ONCE. The new implementation creates a new AvahiEntryGroup per service, on demand. - The previous implementation took ownership of the platform-global default hostname, (by overwriting it). This is not a good idea because the default hostname is usually of relevance for other non-matter services on a given Linux platform. The new implementation establishes the matter-mandated MAC-derived hostname separately and explicitly adds interface addresses. * DnssdImpl.cpp: avoid shadowing local vars to prevent warning/error * DnssdImpl.cpp: make work without INET_CONFIG_ENABLE_IPV4 * DnssdImpl.cpp: fix missing error variable assignment in SuccessOrExit() (found by code-lints)
This work was triggered by investigating into #25932, but is not yet confirmed to be a fix for it.
It does fix two general problems with the previous Avahi-based implementation that became apparent:
Publishing more than one service at the same time did not work.
This needs to be possible e.g. when a node is commissioned into multiple fabrics.
The previous implementation falsely assumed that additional services can be added
to already committed (=published) AvahiEntryGroup, which is not the case.
An AvahiEntryGroup can only publish multiple services ALL AT ONCE.
The new implementation creates a new AvahiEntryGroup per service, on demand.
The previous implementation took ownership of the platform-global default hostname,
(by overwriting it). This is not a good idea because the default hostname is usually
of relevance for other non-matter services on a given Linux platform.
The new implementation establishes the matter-mandated MAC-derived hostname separately
and explicitly adds interface addresses.