If a runmode is missing but other params are passed on the commandline,
issue an error.
Ticket: #5711
Signed-off-by: Promise Charles <descencybobby@gmail.com>
Only demonstrates EVE callbacks for now, but I plan to turn this into a
show case of a variety of callbacks a Rust plugin can do as we add Rust
bindings to the ffi crate.
To prep for the removal of the lib runmode, simplify this C++ example
to match our simple example. We don't yet have the C++ compatible
headers to allow for a C++ app to register its own custom runmode.
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
Ticket: 7666
The end goal is to remove all dependencies on suricata and just
use suricata_sys or suricata_ffi
For now, make usage of what is already available
Bindgen the Rust bindings to the C JsonBuilder API along with the rest
of the Rust bindings to C. Breaking it out was probably the wrong
idea.
This should make it easier, and more correct to bindgen C functions
that use SCJsonBuilder types.
Instead of enabling signal handlers by default, require the user of
the library to opt-in. This is done with the call to
SCEnableDefaultSignalHandlers, which sets a flag to add the default
signal handlers.
This seems like the least invasive way to do this at this time, but it
will require some re-thinking for 9.0, especially if migrate globals
to engine instances, signal handling will need to be re-thought.
Ticket: #6814
When a plugin is first initialized, it is too early to register
transaction loggers. Instead, a plugin can register a callback to be
called when Suricata is ready for outputs like transaction loggers to
be registered.
Likewise for library users, there is a window in SuricataInit where
transaction loggers can be registered that library users don't have
access to. So a lifecycle callback useful here as well.
Ticket #7236
Introduce DetectGetSingleData which does the generic wrapping,
including the transforms, using a new callback prototype
DetectTxGetBufferPtr
The goal is to replace most InspectionBufferGetDataPtr.
For this commit, we do not change every callback to keep the
change relatively small.
Focus here is to remove DetectHelperGetData as its functionality is
provided more directly by the new DetectTxGetBufferPtr.