FAST: Do not store pmap_bit inside fast field structure

So far there was a one-to-one correspondence between a
particular fast field and PMAP bit number. That is to
say, if a fast field requires a pmap bit then we could
say for sure what bit should be set/checked. This makes
sense in almost all cases except for a single one, namely
when a decimal field has individual operators. In the latter
case, "the presence of the mantissa field and any related
bits in the presence map are dependent on the presence of
the exponent". Hence, as we are going to support decimals
with individual operators in the future, we can no longer
rely on the one-to-one correspondence between a particular
fast field and PMAP bit associated.

This patch assumes that if one has to check/set PMAP bit
the last active bit is used. That's why, pmap_bit is stored
under fast_pmap structure.

Signed-off-by: Marat Stanichenko <mstanichenko@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
FAST: decimal fields with individual operators support

The patch implements decimal fields with individual operators
i.e. exponent and mantissa are treated as individual fast fields.

Signed-off-by: Marat Stanichenko <mstanichenko@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
FAST: leave a unified way reading a template file

There should not be any difference between reading
testing suite xml or particular venue template.

Any divergence in the future should be handled
separately.

Signed-off-by: Marat Stanichenko <mstanichenko@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
tape tools: Rename test-nasdaq-itch41.c to tools/tape

Rename test-nasdaq-itch41.c to tools/tape/tape.c in preparation for
making it more generic.

Signed-off-by: Pekka Enberg <penberg@kernel.org>
tape tools: Add new 'check' command

Move the current functionality under a 'tape check' command.

Signed-off-by: Pekka Enberg <penberg@kernel.org>
tape tools: Fix formatting in print_stats

Convert spaces to tabs.

Signed-off-by: Pekka Enberg <penberg@kernel.org>
tape check: Prettify usage

Make the usage text pretty like with perf.

Signed-off-by: Pekka Enberg <penberg@kernel.org>
tape check: Switch to getopt_long

Signed-off-by: Pekka Enberg <penberg@kernel.org>
FAST: Fix uninitialized variable

Compilation fails with GCC 4.4.5 if the variable is not initialized.

Signed-off-by: Aki Saarinen <aki@akisaarinen.fi>
Add WERROR makefile variable

Signed-off-by: Pekka Enberg <penberg@kernel.org>
Merge pull request #9 from akisaarinen/features/fix-compile-error

FAST: Fix uninitialized variable
Revert "FAST: Fix uninitialized variable"

This reverts commit 57979f0d2888819b14b1df4f003b355756519e15. It clashes with
Marat's FAST index map patch.
FAST: Do not use index maps to search fast fields

Preamble: Every FAST message has a set of associated
fields. So far this set presents a simple linear array.
When a fast message is processed (e.g. to reconstruct
order book dynamics) one has to manipulate with fields
by exploring their values. In order to prevent inspecting
the whole array of fields we can use the FAST specific
advantage, namely the order of fast fields can be obtained
from a template file in advance. We used this fact to
manipulate with Snapshot and Incremental messages (see
msg_map and md_map data structures and map_field() function).

This patch claims that we should abandon the aforementioned
logic for three main reasons:

* FAST template usually defines many types of
Incremental and Snapshot messages
(e.g. ftp://ftp.cmegroup.com/fix/Production/Templates/Active/templates.xml)
Generally speaking, each incremental or snapshot message
has its own field order. Hence, we should maintain index
maps for each type of snapshot and incremental messages.
This seems to be quite inflexible: firstly, we have to
construct additional data structure to manage such maps,
secondly, we can map the predefined fast field types only,
thirdly, such design makes difficult to support it
accross the venues.

* The main reason of why we are using index mapping is
the original way we store fast fields inside the fast
message. So far, it was a simple linear array which does
not allow us neither perform advance search nor use
FAST specific details. Hence, we should not struggle
with the consequence of such poor design but to change
such design.

* Order books reconstruction is not the only place where
fast messages are explored. Hence, we should not
develop a specific solution whenever we need it.
Instead, a generic way should be provided (fast_message
specific but not fast_book specific).

To sum up, this patch suggests that we should use
the generic way to handle fast_fields (sequential
search in case of linear array). Any advanced
technique has to be generic and should be developed
in the future (if needed, of course).

Signed-off-by: Marat Stanichenko <mstanichenko@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>