5 Commits (3ae714d3544e80c40c873112b0b8aeefb0805d42)

Author	SHA1	Message	Date
Victor Julien	22f3205664	var-names: expose outside of detect engine ... Until now variable names, such as flowbit names, were local to a detect engine. This made sense as they were only ever used in that context. For the purpose of logging these names, this needs a different approach. The loggers live outside of the detect engine. Also, in the case of reloads and multi-tenancy, there are even multiple detect engines, so it would be even more tricky to access them from the outside. This patch brings a new approach. A any time, there is a single active hash table mapping the variable names and their id's. For multiple tenants the table is shared between tenants. The table is set up in a 'staging' area, where locking makes sure that multiple loading threads don't mess things up. Then when the preparing of a detection engine is ready, but before the detect threads are made aware of the new detect engine, the active varname hash is swapped with the staging instance. For this to work, all the mappings from the 'current' or active mapping are added to the staging table. After the threads have reloaded and the new detection engine is active, the old table can be freed. For multi tenancy things are similar. The staging area is used for setting up until the new detection engines / tenants are applied to the system. This patch also changes the variable 'id'/'idx' field to uint32_t. Due to data structure padding and alignment, this should have no practical drawback while allowing for a lot more vars.	9 years ago
Victor Julien	cb08f02140	xbits: clean up parsing and tests	9 years ago
Victor Julien	fbdcffabc2	xbits: expire (first steps)	11 years ago
Victor Julien	dea8dda3c1	vars: redo var name <-> idx handling ... Can't use sm type anymore as multiple var carriers (host/flow/etc) will all have xbits.	11 years ago
Victor Julien	61cb2abc8d	ippair: xbit implementation ... detect xbits for ippair: initial implementation	11 years ago