Hi Vlad,

On Mon, May 9, 2016 at 1:28 PM, Vlad Dogaru <vlad.dogaru(a)intel.com> wrote:

On Mon, May 09, 2016 at 01:16:21PM +0300, Luiz Augusto von Dentz wrote:

Hi Vlad,

On Mon, May 9, 2016 at 11:29 AM, Vlad Dogaru <vlad.dogaru(a)intel.com> wrote:

Many drivers need to start fibers whose parameters are based on user
configuration. Make it easier to specify such parameters by creating a
fiber_config structure and a wrapper to use it.

Change-Id: I26917ada71acbc676c0f32b6ee081aff7bb1d6d8
Signed-off-by: Vlad Dogaru <vlad.dogaru(a)intel.com>
---
include/nanokernel.h | 53 ++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 53 insertions(+)

diff --git a/include/nanokernel.h b/include/nanokernel.h
index 8d7a864..d79bde6 100644
--- a/include/nanokernel.h
+++ b/include/nanokernel.h
@@ -230,6 +230,45 @@ extern void fiber_yield(void);
*/
extern void fiber_abort(void);

+/**
+ * @brief Fiber configuration structure.
+ *
+ * Parameters such as stack size and fiber priority are often
+ * user configurable. This structure makes it simple to specify such a
+ * configuration.
+ */
+struct fiber_config {
+ char *stack;
+ unsigned stack_size;
+ unsigned prio;
+};

You can embedded the stack on the struct making it the last field with size 0:

char stack[0];

How would one allocate a stack in this case? Normally it might be
something like:

struct fiber_config *conf = malloc(sizeof(*conf) + STACK_SIZE);

But I fail to see how it could be done easily without dynamic
allocation.

Just have it in a super struct:

struct config {
struct fiber_config fg;
char __stack[STACK_SIZE];
}

For size I think size_t should be used.

I've used unsigned to match the fiber creation API. I can change to
size_t in the fiber_config structure, but I'm reluctant to also change
the core fiber creation code.

I didn't say you have to change there, but it seems this is wrong
there as well since unsigned may not be big enough to be used with
sizeof, since we are quite limited in number of architectures this is
probably fine but I would add new APIs with that limitation.

--
Luiz Augusto von Dentz