Why not implement this with procctl()? That seems more natural to me.

In D58206#1335050, @pi wrote:

iridium is normally build using poudriere for those that want to walk outside the beaten path. And there it builds fine. Please keep it.

Address review feedback

In D56474#1337086, @khorben wrote:

In D56474#1336929, @ivy wrote:

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.

i agree and i object to landing this as-is; this simply isn't a workable solution.

when the original SBOM proposal was announced, i was disappointed when FF declared that pkgbase was out-of-scope for that work, but it seems like this and pkgbase and trying to solve similar problems when it comes to dependencies. can we not find a solution that works for both without requiring manual upkeep?

I totally see and understand how this solution is not perfect, and can lead to additional, undesired maintenance burden and possible inconsistencies in the data.

On one hand, this approach is pkgbase-agnostic; on the other hand, it is something pkgbase could do - but does not support yet as far as I know.

If this is not acceptable in the meantime, I am fine putting this on hold and looking for other solutions, pointers welcome as to how it could look.

please re-upload the patch with the full context.

oh good catch! (I've found/fixed these width bugs in the deep past, they can be a pain to find as not every counter is the damned same... :-) )

Add PTCHLD_TRACED_BY_ME.
Add space for future ABI expansion.

Thanks for the patch.
Approved.

In D58318#1337993, @jrtc27 wrote:

D58301 seems a better alternative to this?

Add missing const qualifiers

Address @mmel 's and @mhorne 's comments.

D58301 seems a better alternative to this?

Remove CLAUDE.md file and also update FreeBSD-Xlist to exclude this file from being imported in the tree.

Please upload patches with the full context.

In D58301#1337958, @jrtc27 wrote:

In D58301#1337950, @aokblast wrote:

In D58301#1337946, @jrtc27 wrote:

In D58301#1337933, @aokblast wrote:

In D58301#1337930, @jrtc27 wrote:

In D58301#1337928, @aokblast wrote:

In D58301#1337926, @jrtc27 wrote:

bus_read_8 has been replace to bus_space_read series in sys/bus.h.

Not sure what "bus_space_read series" is though, should that not be bus_space_read_8?

Sorry, it should be bus_space_{read,write} series.

But why series? I don't understand. Why not just use the _8 suffix everywhere?

The _8 suffix remains unchanged before and after my patch. The purpose of this change is to replace the original bus_ series with the bus_space_ series.

Ok, I think I now can decipher what you're trying to get at. What you're trying to say, I think, is something like the following?

bus_{read,write}_8 are macro wrappers around the corresponding bus_space functions in sys/bus.h, so implementing bus_{read,write}_8 won't work. Implement the underlying bus_space functions instead.

Yes, sorry about my bad english expression:)

No worries; normally these things are understandable even if they don't read as perfect English, but in this case for whatever reason I couldn't quite follow it :')

Might I suggest you use my interpretation as inspiration for amending your own message? (I mean, you can just copy the whole thing if you want, but you may prefer it to sound more like you!)

kib feedback and earlier olce comment: CPU_FOREACH

kib feedback from D58336: just provide pc_small_core on i386

In D58301#1337950, @aokblast wrote:

In D58301#1337946, @jrtc27 wrote:

In D58301#1337933, @aokblast wrote:

In D58301#1337930, @jrtc27 wrote:

In D58301#1337928, @aokblast wrote:

In D58301#1337926, @jrtc27 wrote:

bus_read_8 has been replace to bus_space_read series in sys/bus.h.

Not sure what "bus_space_read series" is though, should that not be bus_space_read_8?

Sorry, it should be bus_space_{read,write} series.

But why series? I don't understand. Why not just use the _8 suffix everywhere?

The _8 suffix remains unchanged before and after my patch. The purpose of this change is to replace the original bus_ series with the bus_space_ series.

Ok, I think I now can decipher what you're trying to get at. What you're trying to say, I think, is something like the following?

bus_{read,write}_8 are macro wrappers around the corresponding bus_space functions in sys/bus.h, so implementing bus_{read,write}_8 won't work. Implement the underlying bus_space functions instead.

Yes, sorry about my bad english expression:)

In D58301#1337946, @jrtc27 wrote:

In D58301#1337933, @aokblast wrote:

In D58301#1337930, @jrtc27 wrote:

In D58301#1337928, @aokblast wrote:

In D58301#1337926, @jrtc27 wrote:

bus_read_8 has been replace to bus_space_read series in sys/bus.h.

Not sure what "bus_space_read series" is though, should that not be bus_space_read_8?

Sorry, it should be bus_space_{read,write} series.

But why series? I don't understand. Why not just use the _8 suffix everywhere?

The _8 suffix remains unchanged before and after my patch. The purpose of this change is to replace the original bus_ series with the bus_space_ series.

Ok, I think I now can decipher what you're trying to get at. What you're trying to say, I think, is something like the following?

bus_{read,write}_8 are macro wrappers around the corresponding bus_space functions in sys/bus.h, so implementing bus_{read,write}_8 won't work. Implement the underlying bus_space functions instead.

Yes, sorry about my bad english expression:)

Results from the affected hardware (em0, 82541PI), ~44 h
on a v3 kernel. Summary: 16 watchdog fires, all true positives, 0 false
positives.

In D58301#1337933, @aokblast wrote:

In D58301#1337930, @jrtc27 wrote:

In D58301#1337928, @aokblast wrote:

In D58301#1337926, @jrtc27 wrote:

bus_read_8 has been replace to bus_space_read series in sys/bus.h.

Not sure what "bus_space_read series" is though, should that not be bus_space_read_8?

Sorry, it should be bus_space_{read,write} series.

But why series? I don't understand. Why not just use the _8 suffix everywhere?

The _8 suffix remains unchanged before and after my patch. The purpose of this change is to replace the original bus_ series with the bus_space_ series.

New tested version, on hardware which triggers the watchdog.

In D58301#1337930, @jrtc27 wrote:

In D58301#1337928, @aokblast wrote:

In D58301#1337926, @jrtc27 wrote:

bus_read_8 has been replace to bus_space_read series in sys/bus.h.

Not sure what "bus_space_read series" is though, should that not be bus_space_read_8?

Sorry, it should be bus_space_{read,write} series.

But why series? I don't understand. Why not just use the _8 suffix everywhere?