This patch refactors dma request types to remove generic function
pointers from the library. This include modifying the linux_seq
implementation to:
- move the copy/move implementation to the dma ops
- remove one layer of indirection, as the request type no longer need
_data and _ops substructures.

Enforcing dma requests to have a fully qualified generic type, with
function pointers, will cause issues for future kinds of dma
implementation, that might require a different way of handling requests
altogether.

This work is driven by our current work on a parallel dma implementation.

Missing instructions in autogen.sh and missing jemalloc file to allow a
clean repo to compile.

Things have changed. Reflect the new code.

This patch adds the basics for a dma interface, including
type-dependent requests structures, and an API based on explicit
copy/move calls.

The APIs is flexible enough to deal with sync/async calls. The internal
design is inspired by aml_area, with the goal that create/init stay type
specific, but the core interactions are generic.

Using variable arguments on the tile id for retrieving tiling info makes
the API difficult to use when more than one tile must be used at the
same time.

We change the API to use a tileid, with the assumption that any valuable
tiling will be able to define a workable uuid scheme.

A few missing declarations in aml.h, to make it easier to deal with the
library.

As we cannot find out in advance the binding an area uses, it is not
possible to use a correctly allocated pointer to aml_area_binding.

Fixes a segfault we observed outside of current unit-tests.

Allows memory movement logic to ask a target area how memory should be
bound to it.

Note that it would be safer in the long term to have areas take a
binding at creation time, and translate to nodemasks internally.

Still the same schema, although it looks a bit messier on linux because
of all the options needed.

Same schema as for arena, we create init functions for each type of
area, to make sure that users know what they are working with.

The functions are easy here, as posix is more an allocator than anything
proper.

Add arena_jemalloc initialization, working the same way than tiling and
binding initializations.

We made the choice of not building generic arena allocation functions,
as the benefit of that isn't exactly obvious right now.

Also, we want users to understand the kind of arenas and areas they are
manipulating.

create -> register
purge -> deregister

create is a name we are using elsewhere for dynamic allocation.
And those names match better what we are doing.

Implement 1d tiling and simple binding support. The idea is to allow
an application to explain the AML how data should be organized, and to
be able to reuse this info when dealing with memory movement.

The current interfaces are not great, but they work.

Use a gitignore trick to ignore all files that don't have an extension.
That will cover all binary files generated by make on Linux.

The jemalloc subpackage install rule is too big, and includes stuff that
we don't need to add to the target system. This patch makes sure we only
install the valuable stuff.

We also correct the pkg-config data to match the new installs.

Using both --with-jemalloc-prefix=jemk_ and --with-install-suffix=-aml
ensures that the libjemalloc we build for our internal use has unique
functions names and library names.

This patch fixes a problem with the libtool configuration, where we had
to link a static jemalloc library into the shared aml library to make
everything work. Instead, we can now use the proper LIBADD variables
with the unique library.

Note that with this patch the `make check` target requires a `make
install` beforehand.

This is the result of countless interations on the internal design of
the various building blocks we want to have for this library.

At this point, I hope that this is stable enough. There are still some
tweaks needed here and there, but the core is implemented AND tested.

Some of the design decisions made:
- all functions are public, but most are not meant to be used directly.
- intended public functions take "generic" structs as arguments
- intended actual implementations rely on more complex structures, with
their own family of data and operators.
- split all objects between data and operator structs.

Exemple:
- area.c and arena.c are generic dispatch functions to call the actual,
  specific implementations.
- struct aml_area and struct_aml_arena are the same.

Currently implement:
- 2 area types: posix (malloc) and linux (numa).
- 1 arena type: jemalloc

This is a redesign of the library, as a hierarchy of core objects
implementing its various features. The idea is to create an API that is
as flexible and customizable as possible, by exposing as much as
possible of its internals, so that users can create customs versions
easily.

We also move away from memkind as a possible backend, opting instead to
vendor the jemalloc interface and implement everything ourselves on top
of that.

We expect to start building the low-level pieces using hwloc as a
backend soon, at least in terms of accessing available devices.

libnuma will sometimes fail for our test cases if NUMA node 0 is not
available on the system. Use "all" instead as the default, as it will
always work.

gcc was complaining about type mismatch between the argv declaration and
the prototype of aml_init. This is fixed by declaring argc and argv
properly in stream_vanilla main.

This is a rewrite of the existing code into a memory library exposing
more of its internal abstractions. This refactoring is required to:
- make progress faster by focusing on the core new features
- abstract more of the underlying components and expose those
abstractions
- build upon existing libraries (memkind) for the internal stuff.

Memkind is used as a crutch here, we do not intend to use it in the long
term, as some of its internal are opposed to what we want (topology
management in particular).

Nevertheless, it currently provides a good allocator internally, and
decent access to deep memory, for now.

Over time, we figured out that the best way to build this API was to
create several layers of APIs, each with more abstractions over the
devices. At the same time, we want each layer to expose its internal
mechanisms, so that a user can customize any of them.

This is why we end up with areas and dma engines, and we will add in the
future other stuff, like data decomposition and distribution methods, as
well as direct support for "pipelining".

preprocessor macro ifndef takes a single argument.

Based on github.com/gitignore project, CC0-1.0

This is a mmap-based, non-transparent version of the library, with a
unit test checking that we can call move_pages properly from it.

No node tracking performed. Memcpy not working.

I'm quite convinced that this is not the appropriate way of working with
this stuff but I prefer to checkpoint everything before a wipeout.

This is the first working version of the library. It does very little:
- only numa support
- one allocation per node only
- limited tests
- limited set of functions

Nevertheless, this gives a good idea of what the API should look like, and the
kind of benchmarks we can write with it.