In D40300#917683, @kib wrote:

In D40300#917678, @bz wrote:

Can you please add details (a proposed commit message) as that might shed light onto why you may think this is needed/useful?

This is needed to properly test IPSEC+NAT-T hardware offload. (I do not think that mentioning this in commit message is too useful).

Can you please add details (a proposed commit message) as that might shed light onto why you may think this is needed/useful?

Jailed sockets with a wildcard local address should have lower priority than non-jailed sockets with a wildcard local address.

In D40246#916350, @emaste wrote:

I'm not sure if this one needs to be the non-get version, could be getnanotime?

Make function argument const as suggested by @emaste

In D33168#914780, @bcr wrote:

Can we get an update on the status of this review?

Update types as suggested by @emaste

ping6?

ping6?

In D40120#914011, @hselasky wrote:

@bz : Another thing coming to mind, is to apply the greatest common divisor between x,y,z. This computation is pretty cheap. When you have exact fractions, it doesn't look so good seeing rounding errors.

Is this function being used for clock computations?

From a quick glance looks good to me

Hooray!!!!! THANK YOU! I'll give it a try the next days.

In D40120#913699, @hselasky wrote:

Please don't implement integers like floating point!

I think you need to do something exactly like below. I just quickly sketched this up. Can you verify it?

Change function argument names to floor/ceil as suggested by @emaste.

Fix dedup as reported by @bapt.

Thanks to you two!

Can you "Approve" this change as well given I am not a ports committer?

In D40071#912590, @manu wrote:

In that case we can also remove all the shell redirection since we do not echo anymore and the log functions can just echo directly.
Otherwise lgtm

In D40014#912660, @jrm wrote:

One minor nit. portclippy/portfmt have a few suggestions.

Move RUN_DEPENDS before USES

In D40014#912626, @ehaupt wrote:

Looks good to me.

Anyone?

Here's an example of how this could look (sorts out a duplicate, applies two fixups based on previous reviews)

I am really not too keen on adding the "pci_fixup_class" bit but the alternative is splattering semi-empty files including another file for silly silicon.
This also remains one of the concerns I raised on the original review. It feels like something needs to change to avoid adding hacks early on...

Great. I am doing a rebuild now.

And if @mhorne is okay as well, feel free to commit.
Approved by: bz (mentor)

All the changes I pointed out seem of more cosmetic nature. I'll leave it up to you if you want to do them.

Can we do "bus"_"class"_"drivername" at least then -- though that doesn't work on the search parts so easily as you have to iterate over all the matching bus_class_* files.

That's what's done here no ?

In D39825#907514, @manu wrote:

In D39825#907512, @bz wrote:

I understand the idea. There's several drawback here for wifi:

(1) class information is (at times) useless for wifi cards - on one machine I see (for various vendors):

1 class=0x000280
3 class=0x028000
1 class=0xff0000

I don't see any problems here with intel cards.

I understand the idea. There's several drawback here for wifi: