this might be a good time to move this to the FreeBSD-efi-tools package. it's probably a bug/oversight that it isn't already there.

by the way, there seems to be a typo in the review title :-) (RTA_PERFSRC)

with D58305 + the new version of D58294, everything seems to be working fine, including with BIRD. (i only did cursory testing, though.)

In D58294#1337460, @pouria wrote:

1. Did you use the last version of this patch?

i've done some basic testing with this. IPv4 seems to work with both route(8) and BIRD. IPv6 works with route(8) but not with BIRD:

i'll try to test this later today. is this compatible with the Linux netlink API? it would be nice if it worked out of the box with BIRD.

In D56474#1317500, @markj wrote:

I don't really see how this is going to stay up-to-date: this seems to depend on developers remembering to update the file each time they add a dependency.

In D58287#1336898, @pouria wrote:

Thank you so much for your explanation @ivy

In D58287#1336891, @pouria wrote:

I'd appreciate if you could test this patch in your lab and see if it does really affect it or not.

In D58287#1336894, @pouria wrote:

Oh, so my original thought was correct, we don't need the ip address on the loopback, we only need its route to the loopback:

[...]
vtnet0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
options=880028<VLAN_MTU,JUMBO_MTU,LINKSTATE,HWSTATS>
inet 172.23.1.101 netmask 0xffffffff broadcast 172.23.1.101

In D58287#1336891, @pouria wrote:

Same result.

In D58287#1336891, @pouria wrote:

With this patch, you're still able to do this.

i really don't like the filename /usr/include/profile.h, it's very generic and seems certain to conflict with something else in the future.

as an aside, for the ICMP case i believe you can work around this using the sysctl net.inet.icmp.reply_src=lo0 -- although i haven't tested this on a fully unnumbered interface, i would assume it works. but this doesn't affect outgoing non-ICMP connections, and it doesn't let you choose the source address per-interface, so it's not a replacement for the existing functionality.

In D58287#1336793, @pouria wrote:

Can you explain this please? The local address will be added as a loopback route anyway, with or without this patch.
Therefore, this should not break your use case.

In D58287#1336724, @pouria wrote:

Assigning the same prefix (e.g. in your case /32) to two different interfaces in the same FIB shouldn't be allowed.

i would rather not go with this approach as it will break my existing, functional network configuration:

this makes the sample commands more difficult to copy and paste for no clear benefit. i'm not sure this is an improvement.

sorry, i am unexpectedly busy irl. as you are more familiar with the docs style than me, it's probably easier for you to land this.

i've added mark's ZFS change and also documented this for the dist set path, as it's not pkgbase specific. i've added a new step for pkgbase to update the installed system, since we want users to be in the habit of doing this.

rf

this is the wrong diff. sorry! please ignore this.

I'm not sure offhand which files go in this directory, but in general bhyve should be unlinking preexisting files owned by the current VM.

i appreciate that powerpc64 is a tier 2 port, but even so, i'm a little unsure about breaking ABI compatibility like this. do we have any idea how widespread use of long double is?

in the mean time, this diff is still wrong: while it fixes my original problem, it breaks poudriere somehow. so i'll have another look at this and see if we can handle tri-state options better.

wouldn't this allow non-root users, who are in the vmm group, to interfere with the VMs of other users (e.g., root) by pre-creating files/sockets in that directory? i wonder if it's better to say that non-root users should put their control sockets in a different directory.

rf

a couple of comments:

In D56632#1307030, @lukas.engelhardt_gmx.de wrote:

Once this lands we might be able to use the VERSION_MINOR environment variable.
I will try to test this, but if i understand correctly this should be fixed with latest pkg Version?

remove an unused prototype

improve buffer handling

re: pointer arithmetic, i have a better idea of how to do this, but let's
see if this is a better way to handle shutdown in the mean time.

use uint8_t for bitfields

fix big-endian systems

i haven't tested this, but the changes as described seem reasonable to me.

rebase

rebase

rebase

actually update

rebase on current main

one potential issue here is that the user might not realise why their new packages aren't being used if the version number didn't change. but the previous behaviour does not seem intentional, and i think this is better than an error.

In D56717#1299810, @jlduran wrote:

I recently learned that the official term is freebsd-base(7).

rf