r6.0.1:abstraction (test)

Source Files

/test/src/abstraction_cpu_count.c
/test/src/abstraction_thread_start.c
/test/src/abstraction_thread_wait.c
/test/src/abstraction.h

Prototypes

unsigned int abstraction_cpu_count( void );
int abstraction_thread_start( thread_state_t *thread_state, unsigned int cpu, thread_function_t thread_function, void *thread_user_state );
void abstraction_thread_wait( thread_state_t thread_state );

Typedefs

typedef [type]  thread_state_t;
typedef [type]  thread_return_t;

Defines

#define CALLING_CONVENTION  [calling convention]

Overview

This API is not a data structure. It is the abstraction layer for the test program, which must be implemented on a given platform for the test program to compile and run on that platform.

The test program and its abstraction layer are not versioned or namespaced, which is why they lack the "lfds[major version number]_" namespace prefix. The library proper is versioned and namespaced, as it has users needing to select the version to use and ensure that it does not conflict with other versions or other libraries, but the test program is itself an executable; other binaries do not link to it, depend upon it or need to select a version.

It would still have some value to version the test abstraction, as it would allow users to know which versions of earlier test abstraction ports they could use with new liblfds releases.

I feel though this creates more complexity than value, as test porting is rare and currently there is only one version, for the library, an arrangement as simple as it can be.

Accordingly, the test abstraction API is simply part of the test program, is valid for and only for its given release and can vary in arbitrary ways over releases. If you port a new release of liblfds, you will need to check the new test abstraction, compare it to the old test abstraction and copy over that which you can re-use.

In general changes between releases should be limited.

Please read the porting guide for detailed instructions.