Debug validation revealed that library ThreadVars were being
created *after* the threads were sealed. And the only way to create
your ThreadVars that fits within the current application life-cycle is
to create them in your own custom run mode.
This is likely a better model for users who are bringing their own
packets and threads anyways, as they are essentially providing their
own capture method, and all capture methods provide their own run
mode. They're also using their own threads, which means adapting to
their own threading model.
This is suitable for a backport to 8.0. But for 9.0 we can go further
and remove the built-in library run mode, which will be done in a
follow-up commit.
Ticket: #8259
(cherry picked from commit
|
1 month ago | |
|---|---|---|
| .. | ||
| .gitignore | ||
| Makefile.am | 1 year ago | |
| Makefile.example.in | ||
| README.md | 1 year ago | |
| main.c | 1 month ago | |
README.md
Custom Library Example
This is an example of using the Suriata library with your own packets and threads.
Building In Tree
The Suricata build system has created a Makefile that should allow you to build this application in-tree on most supported platforms. To build simply run:
make
Running
./custom -l . -- filename.pcap
For this example, any arguments before -- are passed directly as
Suricata command line arguments. Arguments after the first -- are
handled by this example program, and currently the only argument is a
PCAP filename to be read.
Building Out of Tree
A Makefile.example has also been generated to use as an example on how to build against the library in a standalone application.
First build and install the Suricata library including:
make install-library
make install-headers
Then run:
make -f Makefile.example
If you installed to a non-standard location, you need to ensure that
libsuricata-config is in your path, for example:
PATH=/opt/suricata/bin:$PATH make -f Makefile.example