Any blocker for this change? Just wondering.

Any comments from reviewers of this change? The current search box is still broken as far as I can check. Does it work for you?

Changes in rD54076 were wrong because listing the domain names with "site:" does not work correctly. I think the correct fix is removing the whitespaces between "site:" and the domain names and using OR keyword to group the domain names like this:

Looks good to me.

Sorry for the delay. Looks good to me.

Looks good to me. Thanks!

• You have to add libnetmap to lib/Makefile, too.
• nmreq.c does not build on 32-bit platforms because nr_options is uint64_t and uintptr_t is not uint64_t in that case. I think the following casting is required at least:

@@ -587,11 +587,11 @@ nmreq_remove_option(struct nmreq_header *h, struct nmr
 {
        uintptr_t *scan;

Sorry for the delay. Looks good to me.

In D26099#581086, @bz wrote:

Anyone else comments? Otherwise I'll get it in no later than Tuesday.

In D26161#580967, @vmaffione wrote:

Thanks a lot @hrs !
However, there is still a pending change in the upstream netmap repository:

https://github.com/luigirizzo/netmap/blob/master/apps/vale-ctl/vale-ctl.c

I like the idea for optimization. Several comments are added in-line.

Please use … instead of three periods. It is the correct way to show a horizontal ellipsis.

Adding the following two lines between the invocation of ni6_input() and the "nroff =" line is simpler. This noff line was added to suppress a "uninitialized variable" warning a long time ago, and the proposed change reverts it effectively while the code paths have no problem.

Committed. Thanks for the patch.

Looks good to me while I agree with a blank line between <name> and <day> as already pointed out.

Ping? I will commit the revised patch if there is no objection.

Fix the lines pointed out in the review.

In D23695#521499, @melifaro wrote:

In D23695#521458, @hrs wrote:

I have no strong objection to allow a prefix route with no gateway, but I think the case pointed out in Bug 194485 can be solved by just adding an address with the delegated prefix on the interface (EUI-64 always works as the interface id). Is there any specific reason for DHCP-PD (or another use case) to have an interface route?

Thank you for looking into this!

Indeed, I should have provided a more accurate description. The problem is a bit bigger than just DHCPv6.

In general, RFC 5942 advocates for the explicit split between address management and prefix assignment:

Remove irrelevant references to smbus(4).

I have no strong objection to allow a prefix route with no gateway, but I think the case pointed out in Bug 194485 can be solved by just adding an address with the delegated prefix on the interface (EUI-64 always works as the interface id). Is there any specific reason for DHCP-PD (or another use case) to have an interface route?

Remove device_printf()s just for debugging.

Updated the patch based on feedback from bz@:

Looks good to me.