This adds utilities for working with the netgraph nodes provided in net/bone-kmods.
Details
Details
- Reviewers
adamw - Group Reviewers
Contributor Reviewers (ports) - Commits
- R11:943bddf018c0: net/bone-utils: Add port
I use jeiface and ngportal via jail.conf to create and destroy numerous wormholes per day.
I use ngpcap while developing new netgraph nodes.
Rather than go through everything I'll point back to D50245
Diff Detail
Diff Detail
- Repository
- R11 FreeBSD ports repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
| net/bong-utils/Makefile | ||
|---|---|---|
| 21 ↗ | (On Diff #176893) | I mean, if it needs exactly those two to build and exactly those two to run, then I absolutely get the intent. It's not wrong per se, but I want you to think it through first. Ask yourself: what situation are you guarding against? Let's say bong-kmods is installed but the first header is missing. What will the framework do when it goes to build this port? |
| 27 ↗ | (On Diff #176893) | As in bong-kmods, why a hash instead of tagging a release? |
| 29 ↗ | (On Diff #176893) | What does this line accomplish? |
| net/bong-utils/Makefile | ||
|---|---|---|
| 21 ↗ | (On Diff #176893) | Yeah I have a long history with more primitive implementations of make. With those the right thing was always to give make as much info as possible and let it decide. But only one is needed will fix |
| 27 ↗ | (On Diff #176893) | yeah I'll go make some tags. I got no reason not to. |
| 29 ↗ | (On Diff #176893) | nothing. and it will be pulled out of both. funny (now) story. i didn't see uidfix and was manually changing my makefiles so that UID/GID wouldn't blow up. I somehow missed uidfix when looking at other examples. I had patches for every makefile before I saw that. |
| net/bong-utils/Makefile | ||
|---|---|---|
| 21 ↗ | (On Diff #176893) | It's a perfectly valid (and not uncommon!) pattern, but there's a tradeoff, and it doesn't do what most people who use it are intending for it to do. Ostensibly, it's guarding against a build or install failure, right? If one of the headers (or a library) from the kmods port is missing, the framework will dutifully build and attempt to install bong-kmods. But because it's already installed, it will produce.... a build or install failure. So, this approach doesn't actually guard against a build or install failure, what it does is change the error and make it occur earlier. In this case, the user will get an error about bong-kmods already being installed. With only one BUILD and RUN dependency, they'd get an error about a missing header or a missing library. It's NOT an anti-pattern, so there's no requirement to change it. The decision point for you is which type of error you're more comfortable with. |
| 27 ↗ | (On Diff #176893) | As with the double-listed dependencies, it's not *wrong* and there's no requirement to change it. I'm thinking about it more from a UX standpoint. I'm automatically suspicious of ports based on hashes, because I don't know whether upstream is trying to tell me that the code's not ready. |
| 29 ↗ | (On Diff #176893) | Aha, that makes sense. It's been a very long time since I've seen that pattern in a port, so it definitely caught my eye! |
Comment Actions
- create MY_DEPENDS that depends on port/pkg not header/kernel module
- have BUILD_DEPENDS and RUN_DEPENDS refer to MY_DEPENDS
- remove GH_TAGNAME it has calver release tag now.
- update pkg-description with acronym
Also now I remember: without the release tag you can't do bong-kmods>=0 so I went with file dependencies.
Another reason to create tags and not use GH_TAGNAME.
Comment Actions
I found this thread when trying to find a way to have bone-utils depend on any flavor of bone-kmods. Doesn't appear possible. This change achieves bone-utils depends on bone-kmods and bone-utils@invariants depends on bone-kmods@invariants.
It just isn't satisfying since the two bone-utils packages will literally be bit-for-bit identical and only differ in package dependency. But I still think its better than having an option for bone-kmods.
Comment Actions
Is there any value in combining them into one port? Will users want the kmods without the utils? Combining them would mitigate the dependency question. Just food for thought.
Comment Actions
I am considering this. And I think the answer is I should look into this before we merge either one. Its also an excuse to create a combined github repo calsed "bone". Give me a few days to look into combining things. I bet its doable. And while the kmods are valuable without utilities, maybe that's where the port option lies, having a utilities be optional.
Comment Actions
Switch to new mono repo for bone-kmods/bone-utils
This one doe NOT have flavors. It also has neither a build dependency (mono-repo means it has its headers) nor a runtime dependency. Now ngportal(8) and ngpcap(8) will be useless without the appropriate bone-kmods. They will err out. But in the same way ngctl(8) does if you try to mkpeer with a non-existent node.
This is a compromise. This means there is only one package flavor for bone-utils and it doesn't care which (or even if) you installed bone-kmods.
@adamw I know you haven't had a chance to reply to email but I figured its easier to show you what I mean here than try to describe!
Comment Actions
I'm sorry about the long delay I updated my ports tree (yes I know ccache is the answwer).
I can verify that this port behaves reasonably without having bone-kmods:
# pkg info | grep bone bone-utils-2026.05.13 Collection of netgraph utilities for bone-kmods # jail -i -c name=test host.hostname=test.example.net vnet persist 1 # ngportal :wh0a test:wh0b ngportal: kld_ensure_load: unable to load kernel module "ng_wormhole": No such file or directory # jeiface test tst0 tst0 # pkg install bone-kmods ... # pkg info | grep bone bone-kmods-2026.05.13.1500506 Collection of netgraph kernel modules bone-utils-2026.05.13 Collection of netgraph utilities for bone-kmods # ngportal :wh0a:br1:link test:wh0b:tst0:ether # ngctl show wh0a: Name: wh0a Type: wormhole ID: 0000000f Num hooks: 2 Local hook Peer name Peer type Peer ID Peer hook ---------- --------- --------- ------- --------- evthorizon br1 bridge 00000004 link0 jid=1 wh0b wormhole 00000003 jid=0 # ngctl -j test show wh0b: Name: wh0b Type: wormhole ID: 00000003 Num hooks: 2 Local hook Peer name Peer type Peer ID Peer hook ---------- --------- --------- ------- --------- evthorizon tst0 eiface 00000002 ether jid=0 wh0a wormhole 0000000f jid=1 # jail -rv test test: removed
So I'm pretty happy with where we have ended up.
Comment Actions
poudriere testport -j FreeBSD15 -p local net/bone-utils
attaching recent poudriere test build.
| net/bone-utils/Makefile | ||
|---|---|---|
| 25 | Totally fair. especially since I admit it is not the perfect script for netgraph and I call it a cop-out myself! 😄 But before I do that, is it better to put this in files directory anyway to set USE_RC_SUBR or is that not important? Asking as that determines where I fix this. | |
| net/bone-utils/Makefile | ||
|---|---|---|
| 25 | Usually we keep rc scripts under the files/ dir of the port itself. In such cases USE_RC_SUBR comes in handy. The main reason for this is to be able to quickly fix the rc script without involving the upstream. But in you case I think you will always be nearby to fix things, so we can as well leave the rc script in the project itself. | |
Comment Actions
Pulling in change that renames netgraph to bone_netgraph.
Additionally incorporate comments:
- update CATEGORIES to have sysutils
- add GH_TAGNAME for bone_netgraph (not netgraph) name.
- post-patch bone_netgraph with LOCALBASE
| net/bone-utils/pkg-descr | ||
|---|---|---|
| 19 | This wording is a little odd to me. If it prints an error and exits, then it kindof does require bone-kmods to run. Technically you're correct, but from the users' perspective it's basically required. Maybe something like: Bone-utils needs the correct version of net/bone-kmods for your system. Most users want the default flavor: pkg install bone-kmods If you built your kernel with INVARIANTS (the default in CURRENT), use the @invariants flavor: pkg install bone-kmods@invariants Don't have to use that wording or anything, but it's a starting point. | |
| net/bone-utils/pkg-message | ||
| 11 | The pkg-message should also tell users that they need bone-kmods. Personally I'd copy whatever explanatory block you have in pkg-descr into here. In my experience, if it's in both pkg-descr and pkg-message, you have the best chance of users actually seeing it. | |