libsuricata: library capture mode - v2

[jasonish]

Library run mode. Allows library user to provide packets.

Based on https://github.com/OISF/suricata/pull/10769. Mainly breakout the example into its own to keep one very simple.

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 7.65027% with 169 lines in your changes missing coverage. Please review.

Project coverage is 82.68%. Comparing base (d9148d1) to head (a29642d). Report is 618 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #10802      +/-   ##
==========================================
- Coverage   82.73%   82.68%   -0.05%     
==========================================
  Files         927      929       +2     
  Lines      247785   247968     +183     
==========================================
+ Hits       204996   205025      +29     
- Misses      42789    42943     +154     

Flag	Coverage Δ
fuzzcorpus	64.10% <7.10%> (-0.08%)	:arrow_down:
suricata-verify	61.94% <7.65%> (-0.04%)	:arrow_down:
unittests	62.15% <7.10%> (-0.05%)	:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

[suricata-qa]

Information: QA ran without warnings.

Pipeline 19996

[victorjulien]

Would like to see a bit more explanation in commits, docs and code comments on the additions.

[jasonish]

/cc @amirabell as I can't assign or mark you as a reviewer.

[jasonish]

The sample program does segfault on exit. TmThreadKillThread tries to join a thread ID of 0. This is due to the "fake" thread setup for user owned threads to satisfy Suricata's thread lifecycle.

The simple fix is to not join the thread IDs of 0, assume they are externally managed threads. They could even be the main process of a library user. I've made this change locally. However, if there are more places such logic needs to occur, perhaps a new thread family for "external" threads would be ideal. Will show in the next PR.

[amirabell]

The sample program does segfault on exit. TmThreadKillThread tries to join a thread ID of 0. This is due to the "fake" thread setup for user owned threads to satisfy Suricata's thread lifecycle.

The simple fix is to not join the thread IDs of 0, assume they are externally managed threads. They could even be the main process of a library user. I've made this change locally. However, if there are more places such logic needs to occur, perhaps a new thread family for "external" threads would be ideal. Will show in the next PR.

Yes, in library mode TVT_PPT threads should not be joined.

[jasonish]

Yes, in library mode TVT_PPT threads should not be joined.

Fixed in my local branch by not join "external" threads. Will be ready for review soon.

[jasonish]

Replaced by https://github.com/OISF/suricata/pull/11711.