I think this would be useful for driver developers, but we'd need to document is suitably so people know to look for it.

Looks good thanks for chasing it down

The deletions seem fine. The convention is probably up to you if you are changing to this.

Holding until Tuesday on this, FreeBSD-ports-kmods still isn't receiving pkgs for nvidia-kmod and @bapt needs some time before looking at it.

There are two possible concerns that come to mind:

overall looks fine

@zlei do you know if all the consumer ifdi_get_counter implementations will still have been initialized correctly, for instance not making invalid references? It seems fine as long as there are no implicit initialization issues that relied on the current behavior.

Committed in 9dbf8452e1fbb8e075b0f8d978fe9be9d0df9355

In D50067#1188547, @kgalazka wrote:

Fixing Eric's comment about codename seemed as a trivial change so I tried to do it without engaging Yogesh and updating the review. I'm sorry, it looks like it was a poor idea. Commit wasn't automatically detected by Phabricator and this review is still open. Is there anything else I should do except for adding the commit with 'Edit Related Objects', and promising to not try to cut the corners in the future?

LGTM, it's out of the way aside from a branch and the change to iflib_encap (is this change strictly necessary for simple or can it be committed separately?).

@imp if I recall this was something we were looking at on my team at LLNW, if it were in Bugzilla I'd say "Close - OBE" is appropriate.

@kgalazka Nothing jumping out to me here for feedback on the code. I don't have an E610 so I can't do anything with this.. it looks like this is maybe a support tool where the file is sent to Intel for assistance, but if we can embellish anything as to how an end user might use any of this on their own that would be a worthwhile followup.

@kgalazka I'm ok with this, go ahead. Please think about budgeting some time for tinderbox, lint, and early user feedback issues that may come up, and by extension when you want to send it in, i.e. a Monday would be good.

'nvidia-drm' would also be belong in this list

In D50388#1177749, @kevans wrote:

In D50388#1177748, @kbowling wrote:

@kevans were you able to get any reaction from portmgr@?

No, sorry, I haven't had a chance to draft anything yet; I thought I had dropped a 'go ahead and do this, I will follow up on the cluster side' comment, but clearly not- sorry.

@kevans were you able to get any reaction from portmgr@?

@markj I think this behavior is identical to OpenBSD so adding part of their man doc.

I would remove the phrase 'change will not fix anything but' in the commit message and I think this is good.

In the commit message do you mean to say there is something else double counting?

Pushed as 9302fb05a0c6599bbe8963ff5201fd3b99994535

Although I suppose the existing change is fine and maybe preferable

1500052 was just allocated for this in ff2dc0bca372

Generally ok with this. I would like to know if the malloc thing can be addressed during init or if that is required by your upcoming changes.

I'm planning to commit this soon unless a serious objection is raised.

Is there a way to vendor the alt toolchains? It is imperative this doesn't start downloading from the internet outside of the fetch step, the same standards things like Cargo, Maven, etc have in ports. As long as that is addressed I think the overall concept is fine now -- it will be awkward if we have to patch Go but hopefully that is not common.

@markj go ahead and commit the initialization and style changes. I need a moment to think about the threading, so I would ask that goes in a separate commit, which you are free to do as well. Is there any reason not to use _int variant over long? This should MFC back to 32 bit platforms which seem to generate different code vs x86 for whatever it's worth. The driver is also "upstream" for RTEMS and other smaller systems.

In D50388#1149945, @jrtc27 wrote:

Or, like WITNESS or MALLOC_PRODUCTION, on in HEAD and off in stable branches?

In D50128#1149830, @kgalazka wrote:

In D50128#1147046, @kbowling wrote:

I would be somewhat curious why we need to serialize like this. Note that nothing else prodding the swfw in ixgbe is explicitly locked or asserted.

I was thinking about ixgbe_if_init and ixgbe_config_link. IIRC under the hood it does couple of MDIO reads and writes. The SWFW semaphore is hold for individual accesses, but not during whole operation. Without CTX lock writes from mdio bus may interfere with that and bringing link up may fail.

Please reupload with context (git diff -U9999). It also seems to not be based on FreeBSD main.

To add to what @erj said, multi-arch build is a requirement the same as on other OS projects. We have to provide some advance notice to drop things and this should be MFC'd back to 13 and 14. See build(7), 'make universe' or 'make kernels' is enough. I don't see anything off hand that is problematic, and there is no expectation on Intel for validation for odd platforms. But it has to build everywhere it currently does.

I do see the improvement here for the drm maintainers not having to deal with all this, but I'd like someone with more ports infra experience to evaluate the implementation.

The first change seems sensible.

I'm generally fine with what is here, it seems logical to me.

I would be somewhat curious why we need to serialize like this. Note that nothing else prodding the swfw in ixgbe is explicitly locked or asserted.

Fix DBUS, reported as https://github.com/bitcoin/bitcoin/issues/32464

Looks good

See the actual commit message from that https://reviews.freebsd.org/R9:a52de44df1a6534adec66174ee68d03444738907

It will be helpful, especially early on, to add a fully formatted commit message to the review description so we can have a look and make sure you have the git config right.