Posix implementation layer #5667

youvedeep · 2018-01-13T17:45:56Z

Currently Zephyr does not support POSIX APIs. This patch patch provides a compatibility layer for supporting POSIX1003.1 PSE52. patch series use Zephyr APIs as foundation and provides a layer to map POSIX APIs to ZEPHYR APIs.

codecov-io · 2018-01-13T18:07:12Z

Codecov Report

Merging #5667 into master will increase coverage by 0.13%.
The diff coverage is 62%.

@@            Coverage Diff             @@
##           master    #5667      +/-   ##
==========================================
+ Coverage   53.14%   53.28%   +0.13%     
==========================================
  Files         412      424      +12     
  Lines       40148    40729     +581     
  Branches     7733     7845     +112     
==========================================
+ Hits        21338    21702     +364     
- Misses      15675    15817     +142     
- Partials     3135     3210      +75

Impacted Files	Coverage Δ
kernel/posix/pthread_cond.c	`82.75% <0%> (ø)`	⬆️
include/posix/time.h	`100% <100%> (ø)`
kernel/posix/pthread_mutex.c	`57.14% <100%> (ø)`	⬆️
include/posix/pthread.h	`100% <100%> (+28.57%)`	⬆️
include/posix/posix_sched.h	`100% <100%> (ø)`
kernel/posix/pthread_sched.c	`41.66% <41.66%> (ø)`
kernel/posix/timer.c	`46.98% <46.98%> (ø)`
kernel/posix/pthread.c	`61.5% <61.5%> (ø)`
tests/kernel/posix/pthread/src/pthread.c	`61.85% <61.85%> (ø)`
tests/kernel/posix/pthread_join/src/pthread.c	`64.7% <64.7%> (ø)`
... and 18 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a73e8fa...9ae6024. Read the comment docs.

aescolar · 2018-01-15T19:51:17Z

kernel/posix/pthread.c

+
+}
+
+int pthread_attr_setschedparam(pthread_attr_t *attr,


Please add all these functions also to posix_cheats.h
Otherwise you prevent the POSIX arch port from using the host ones.
It wouldn't harm adding also the ones you included as static inlines in the header, in case somebody would change them later to normal/global definitions.

aescolar · 2018-01-15T19:55:55Z

kernel/posix/pthread_sched.c

+#include <kernel.h>
+#include <sched.h>
+
+int sched_get_priority_min(int policy)


Also these 2, and any other which is in the POSIX API

lpereira

Please review my comments on the other pthread PR; some of the issues there were not addressed in this PR.

(I did not review this fully.)

lpereira · 2018-01-16T21:44:42Z

include/posix/pthread.h

+ *  Default pthread attributes on attributes initialization.
+ */
+static pthread_attr_t initpthreadattrs = {
+	K_LOWEST_APPLICATION_THREAD_PRIO,	/* priority */


Please see comments on #5494 about this. Structs should be initialized like so:

static const struct foo = { .bar = 3, .baz = 4, .quux = SOME_CONSTANT, };

This way, you can get rid of comments, and if the order of elements change (due to packing reasons, implementing new features, etc), you can be sure that the values that were set before will continue to be set in the future; unset values will be initialized to 0 by the compiler.

lpereira · 2018-01-16T21:45:26Z

kernel/Kconfig

+if PTHREAD_IPC
+config MAX_PTHREAD_COUNT
+	int
+	prompt "Maximu pthread count in POSIX application"


Typo: maximu

lpereira · 2018-01-16T21:48:33Z

kernel/posix/pthread.c

+int pthread_create(pthread_t *newthread, const pthread_attr_t *attr,
+		   void *(*threadroutine)(void *), void *arg)
+{
+	static int thread_count;


This should be an atomic_val_t.

lpereira · 2018-01-16T21:52:53Z

kernel/posix/pthread.c

+		errno = EINVAL;
+		return -1;
+	}
+	if (thread_count < CONFIG_MAX_PTHREAD_COUNT) {


Between creating a thread and incrementing the value, preemption might occur. This will cause a race condition that will lead to either invalid memory access, or elements being skipped in the threads array (and two elements being initialized in the same spot).

A way to fix this is to peruse the fact that atomic_inc() will return the previous value, which is the one you want to use as an index to the threads array:

atomic_val_t index = atomic_inc(&thread_count); if (index < CONFIG_MAX_PTHREAD_COUNT) { ... &threads[index] ... }

There's no race condition here, because index is guaranteed to be below CONFIG_MAX_PTHREAD_COUNT, even if preemption occurs: no other thread will use the same index. (That's why index here is not static like thread_count is.)

Thanks @lpereira I will take care of this.

youvedeep · 2018-01-17T10:13:46Z

Addressed comments from @lpereira and @aescolar-ot in new patch version.

lpereira · 2018-01-19T00:10:27Z

kernel/posix/pthread_sched.c

+
+int sched_get_priority_min(int policy)
+{
+	if (!((policy == SCHED_FIFO) || (policy == SCHED_RR))) {


You can apply De Morgan's Law here and simplify this expression.

Sure I will change it to - if((policy != SCHED_FIFO) && (policy != SCHED_RR)))

No need for the extra parenthesis.

lpereira · 2018-01-19T00:21:33Z

kernel/posix/pthread_sched.c

+
+	if (IS_ENABLED(CONFIG_COOP_ENABLED)) {
+		if (policy == SCHED_FIFO) {
+			errno = 0;	/* Valid negative return */


This function can't return a negative value on success; that's how the API is defined, and how code using it will expect it to behave.

A solution is not to have priorities mapping 1:1 between Zephyr and POSIX. You can derive the formula for the proper mapping like so:

Consider two points in the space: (x0, y0) and (x1, y1). The X axis is the POSIX priority, and the Y axis is the Zephyr priority.

Find two points, P1 and P2, that maps the minimum priority in Zephyr (that's a negative value) to a value that's acceptable in POSIX (say, 1). Do the same for P2, for the maximum value.

Calculate the slope: m = (y1 - y0) / (x1 - x0)

Use the calculated slope in the line equation: y - y0 = m(x - x0), where y0 and x0 are the coordinates from P1

Isolate y or x depending on which direction you want to go (Zephyr -> POSIX or POSIX -> Zephyr). If you're calculating y, any x in the line is valid (could be even x0), and vice versa.

It's important to round m to the nearest integer, to not use floating point math here. It shouldn't matter if it's ceiled or floored; just make sure that you'll never get a negative x.

As per my understanding if a function returns a negative value then it should set errno to 0.
because of which I was putting 0 as ERROR code.

https://www.unix.com/man-page/posix/3posix/sched_get_priority_min/

That's the opposite: if the function returns -1, errno must be set; otherwise, errno isn't touched (see RETURN VALUE in the linked man page).

Per the POSIX specification, only a return value of -1 will signal error. However, a lot of code will verify error conditions by testing the sign bit (i.e. checking if the return value is < 0 rather than == -1), as it often generates slightly tighter code.

Being a compatibility layer, it's best to assume that any function returning -1 per the specification will also return a negative number (whatever it is) on error, and 0 or a positive value on success. Returning any value from 0 to INT_MAX is fine for these functions, as long as they're consistent with each other, and that the functions to set the priorities are also consistent with these priority values.

Looking at documentation @ https://www.systutorials.com/docs/linux/man/2-sched_get_priority_max/#index, (Looks like man page for IEEE Std 1003.13-2003 is silent on number of priorities level in POSIX https://www.unix.com/man-page/posix/3posix/sched_get_priority_min/)-
As per POSIX :-

Higher the numerical value Priority, Higher the priority. Something like a thread with priority 5 will have higher priority than a thread with priority 1. (something opposite of Zephyr).

There should be at least 32 priority levels, but this can vary based on other standards. I think we can avoid this as for RTOS this may be too high number of priority levels.

I think we can not use the slope technique to map Zephyr priort levels to POSIX prioirty levels as this may create confusion/issues. Let us assume (Numerical lower priority has Higher Priority than numberical high only for example).
Let us take an example - If we have premptive based scheduling enabled with
Zephyr_Max_ priority = 15
Zephyr_Min_ priority = 0
Now mapping this range to POSIX_MAX = 31, POSIX_MIN=0.
Let us say that a POSIX compliant application has 3 threads with priority 2, 3, 4. then it may be expected that 1 has higher priority than 2 and so on.
But internally :-
Thread 1 ==> POSIX_PPRIOITY = 2 mapped to ZEPHYR_PRIORTY = 1
Thread 2 ==> POSIX_PPRIOITY = 3 mapped to ZEPHYR_PRIORTY = 1
Thread 3 ==> POSIX_PPRIOITY = 4 mapped to ZEPHYR_PRIORTY = 2
So this may give undesirable results. So i think there should be 1:1 or n:m (n>= m) mapping between POSIX and ZEPHYR .

I think we can map ZEPHYR_PRIORITY to POSIX_PRIORTY :-

For Preemptive_thread :-
posix_priorty= (CONFIG_NUM_PREEMPT_PRIORITIES - 1) - zephyr_priorty
*-1 to keep maximum priority reserved for highest priority thread.
This will make POSIX_MIN_PRIORITY = 0 and POSIX_MAX_PRIORTY = CONFIG_MAX_APPLICATION_PRIORITY

For COOPERATIVE scheduling policy:-
posix_application_priority = (-1 * zephyr_priority) +1 . (cooperative priorities are -ive).

lpereira · 2018-01-19T00:28:47Z

include/posix/pthread.h

+ *
+ * See IEEE 1003.1
+ */
+static inline void pthread_exit(void *retval)


Do we have a pthread_join()?

As of now we do not have pthread_join(). We need to figure out how to implement it. Before that we will target other POSIX APIs.

One way to do this is the following:

struct pthread { struct k_thread thread; void *retval; }; typedef pthread_t struct pthread;

This way, it's possible to use type-punning to convert between a struct k_thread and a struct pthread. And, for pthreads, it's possible to set/obtain the return value. So, this function could be implemented like so:

static void pthread_exit(void *retval) { pthread_t *self = (pthread_t *)k_current_get(); self->retval = retval; k_thread_abort(self); }

Then, pthread_join() will get the retval from pthread_t. Calling pthread_exit() should also give a mutex that pthread_join() is waiting on, before it aborts itself.

Yes I got your Idea, but I wanted to enhance it to be compatible with pthread_join after first set of patch merge.

For making pthread_join() we need to have 2 members (mutex and Condition variable to signal the state exit). But before that i am waiting for my first set of patches to be merged. I am planning to take this as enhancement,
struct pthread {
struct k_thread thread;
void retval;
pthread_mutex_t state_lock; / Locks the state. /
pthread_cond_t state_cond; / Signalled when the state changes. */
};

lpereira · 2018-01-19T00:42:45Z

There are some spelling/typos in the commit messages as well; please fix them.

andrewboie

Why is this PR and #5494 both open for review at the same time, they have the same code in them!
This is wasting developer time, clean up your stuff and send for review in one or more PRs that are completely disjoint.

andrewboie · 2018-01-23T23:39:01Z

include/posix/pthread.h

+#define PTHREAD_CANCELABLE     (0 << PTHREAD_CANCEL_POS)
+/* Essential Thread */
+#define PTHREAD_NON_CANCELABLE (1 << PTHREAD_CANCEL_POS)
+#define K_LOWEST_STACK_SIZE     256


how was this value arrived at?

I just went through the Zephyr Code base and looked that 256 is least stack size used by a thread.

Hi @andrewboie Sorry for confusion. But i have mentioned clearly on PR #5494 that discussion for this patch is moved to #5667.
@nashif requested to merge all POSIX related patches into 1 PR and for that I created this PR later.
To avoid confusion, I have closed other POSIX related PRs.

You don't need this value at all unless I'm missing something.
It only seems to be used for the defaults which have a NULL stack pointer anyway,
Just use NULL for the default stack pointer and 0 for the size. There is no actual minimum. I have a stack in a double fault handler which is about 12 bytes in size.

hmm got it, So basically your suggestion to to define stack_size as 0, something like stack pointer. Let the user provide stack_size along with stack pointer,

Hi @andrewboie Sorry for confusion. But i have mentioned clearly on PR #5494 that discussion for this patch is moved to #5667.

Don't have multiple open PRs with the same code. Just don't do it. Close one of them.

youvedeep · 2018-01-28T17:11:09Z

Guys, Can you please please provide quick review comments on this PR as this is targeted for Release 1.11

lpereira · 2018-01-31T00:06:33Z

include/posix/pthread.h

+/* Pthread cancellation */
+#define PTHREAD_CANCEL_POS     0
+/* Non Essential Thread */
+#define PTHREAD_CANCELABLE     (0 << PTHREAD_CANCEL_POS)


I can't seem to find any reference to PTHREAD_CANCELABLE. Is this documented somewhere?

lpereira · 2018-01-31T00:07:59Z

include/posix/pthread.h

+#define PTHREAD_CANCELABLE     (0 << PTHREAD_CANCEL_POS)
+/* Essential Thread */
+#define PTHREAD_NON_CANCELABLE (1 << PTHREAD_CANCEL_POS)
+#define THREAD_INIT_FLAGS       PTHREAD_CANCELABLE


Why is this prefixed with THREAD_? If someone includes pthread.h, this will pollute their namespace with things that are not POSIX-specific. There doesn't seem to exist any THREAD_INIT_FLAGS in Linux as well, so I don't know why is this defined in the header file.

lpereira · 2018-01-31T00:08:40Z

include/posix/pthread.h

-struct timespec {
-	s32_t tv_sec;
-	s32_t tv_nsec;
+static const pthread_attr_t initpthreadattrs = {


Nitpick, but please use _ to separate words in variable names: init_pthread_attrs.

Also, this shouldn't be in the header file; there will be multiple copies of it if it's included multiple times. Define it inside pthread_attr_init() instead, even if you have to move it to a .c file.

lpereira · 2018-01-31T00:11:49Z

include/posix/pthread.h

+	k_thread_abort((k_tid_t) self);
+}
+
+static inline u32_t zephyr_to_posix_priority(s32_t z_prio, int *policy)


Functions that are implementation details should be in the .c file.

lpereira · 2018-01-31T00:13:11Z

include/posix/time.h

+ */
+static inline int clock_settime(clockid_t clock_id, const struct timespec *ts)
+{
+	errno = (clock_id != CLOCK_MONOTONIC) ? EINVAL : ENOSYS;


The error here should always be ENOSYS, since it's just a stub. Returning EINVAL does not help the user figure out what's wrong.

lpereira · 2018-01-31T00:21:48Z

kernel/posix/pthread.c

+	new_prio = posix_to_zephyr_priority(param->priority, policy);
+	cur_prio = k_thread_priority_get(*thread);
+
+	if ((is_posix_prio_valid(new_prio, policy) == false) ||


Nitpick: please remove the excessive parenthesis.

lpereira · 2018-01-31T00:21:57Z

kernel/posix/pthread_sched.c

+
+static bool valid_posix_policy(int policy)
+{
+	if ((policy != SCHED_FIFO) && (policy != SCHED_RR)) {


Nitpick: please remove the excessive parenthesis.

I feel removing internal braces (if (policy != SCHED_FIFO && policy != SCHED_RR) ) will lose the readability. So keeping the braces is better. What is your thought ?

I don't have strong opinions on this -- I find it less visually polluted without the parenthesis, and don't see any readability issues without them. It's just a nitpick, we can agree to disagree.

lpereira · 2018-01-31T00:22:30Z

kernel/posix/pthread_sched.c

+
+	return true;
+}
+int sched_get_priority_min(int policy)


Nitpick: Missing newline before function.

lpereira · 2018-01-31T00:24:28Z

kernel/posix/pthread.c

+	prio = posix_to_zephyr_priority(attr->priority, attr->schedpolicy);
+
+	thread_index = atomic_inc(&thread_count);
+	if (thread_index < CONFIG_MAX_PTHREAD_COUNT) {


BTW, I was thinking: can't we just use a memory pool for this? It's possible to return a handle to a pool when the thread ends. Doing it this way, there's no way to recycle a pthread struct: once the system runs out of them, they're gone.

Hi @lpereira I will take this as enhancement after M2 milestone.

lpereira · 2018-01-31T00:26:41Z

tests/kernel/pthread/src/pthread.c

+	}
+
+	for (i = 0; i < N_THR; i++) {
+		/* Thread Attribute initialization */


Please avoid comments that are not adding any value. If a line says foo_init(&foo), don't say /* Initializes foo */. Comments should document the intent of the code or things that are not obvious just from reading the code itself.

lpereira · 2018-01-31T00:29:28Z

The patches are looking better, but I don't think they're ready to be merged yet.

lpereira · 2018-02-15T00:14:09Z

kernel/posix/pthread.c

+		pthread_cond_wait(&pthread->state_cond, &pthread->state_lock);
+	}
+
+	if (pthread->state == PTHREAD_EXITED) {


Use an else if here.

PTHREAD_JOINABLE and PTHREAD_EXITED are not implemented through ifelse as status of thread will change from PTHREAD_JOINABLE --> PTHREAD_EXITED on pthread_cond_broadcast (inside pthread_exit).
Example :

Thread T1 calls pthread_join for thread T2.

Thread T1 waits at pthread_cond_wait as T2 has not exited.
.
.

Thread T2 calls pthread_exit and it updates self->state and retvalue. and calls pthread_cond_broadcast.

Now thread T1 receives the condition variable.

It enters into pthread->state == PTHREAD_EXITED and gets the return value,

So a thread need to enter into both the conditions, so it has not been put through else if.

lpereira · 2018-02-15T00:14:51Z

kernel/posix/pthread.c

+	pthread_mutex_lock(&pthread->state_lock);
+
+	if (pthread->state == PTHREAD_JOINABLE) {
+		pthread_cond_wait(&pthread->state_cond, &pthread->state_lock);


This should return 0 here

when the state if thread will change from PTHREAD_JOINABLE to PTHREAD_EXITED. it will pass through pthread->state == PTHREAD_EXITED) and will eventually return 0.

detailed explanation in previous comment.

lpereira · 2018-02-15T00:16:02Z

kernel/posix/pthread.c

+ *
+ * See IEEE 1003.1
+ */
+int pthread_join(pthread_t thread, void **status)


For this function, it might be better to have a int ret that's set by each block comparing with pthread->state. This will reduce its size slightly, and have only one mutex_unlock/return block.

youvedeep · 2018-02-15T14:32:29Z

Addressed comments received (except @andrew's comment to fix mutex Object issue). Can you please review it further and provide feedbacks.

youvedeep · 2018-02-16T07:49:28Z

implemented memory allocation for pthread object using mempool.
Added pthread_cancel test.

youvedeep · 2018-02-17T04:00:36Z

Guys Can you please give further comments or provide feedback on this PR?

lpereira

Looking a lot better, thanks!

lpereira · 2018-02-21T01:48:46Z

kernel/posix/pthread.c

+	struct posix_thread *thread;
+	struct k_mem_block block;
+
+	/*


Comments such as these should be in the comment block that doxygen will find. Users are not expected to look at the implementation to find out why the function is returning EINVAL.

Addressed
sure I put comment in doxygen.

lpereira · 2018-02-21T01:49:08Z

kernel/posix/pthread.c

+	prio = posix_to_zephyr_priority(attr->priority, attr->schedpolicy);
+
+	if (k_mem_pool_alloc(&posix_thread_pool, &block,
+			     sizeof(sizeof(struct posix_thread)), 100) == 0) {


Why sizeof(sizeof(T))?

Addressed.
This is a typo, thanks for catching it. I will fix this.

lpereira · 2018-02-21T01:51:31Z

kernel/posix/pthread.c

+ */
+int pthread_setcancelstate(int state, int *oldstate)
+{
+	struct posix_thread *pthread = (struct posix_thread *) pthread_self();


Put in doxychain currently.

This is still an issue: if pthread_setcancelstate() is called from a thread that's not a pthread, it'll access memory that it shouldn't access (in the best case scenario; it's undefined behavior, so who knows what's going to happen.)

This is an issue with all functions that call pthread_self().

If we're not going to fix this -- which is a big issue, IMO -- at least comment in the pthread_self() Doxygen block that the results of calling it outside a thread created with pthread_create() are undefined.

lpereira · 2018-02-21T02:11:40Z

kernel/posix/pthread.c

+};
+
+/* Memory pool for pthread space */
+K_MEM_POOL_DEFINE(posix_thread_pool, sizeof(struct posix_thread),


Nothing is returned to this memory pool; we'll still run out of pthread handles.

I remember threads having a callback function that got called whenever they were destroyed. Can't we used that to return something to the pool? It might be only for threads that are aborted, which is fine; pthread_exit() can schedule a call to k_mem_pool_free() (it can't call it directly).

Not Addressed. Need to figure out solution for this.

Currently I am not returning back to mem pool becuase we need to keep pthread object to handle
pthread_join requests. If we will free the space then pthread_join will have issue.

But I agree we need to figure out a way to return back to mem pool on pthread termination. I can explore it further. But even when k_thread is destroyed, we may need to access pthread object such as retval, pthtread state, statue_mutex to address pthread_join.

youvedeep · 2018-02-21T16:05:50Z

Addressed comments from @lpereira .
Also Added 2 patches for :
POSIX Timer APIs (12/13)
POSIX timer test API (13/13)

As per IEEE 1003.1 POSIX APIs should return ERROR_CODE on error. But currently these are returning -ERROR_CODE instead of ERROR_CODE. So fixing the return value. Signed-off-by: Youvedeep Singh <[email protected]>

As per POSIX standard typedef should be part of sys/types.h file. So moving typedef from pthread.h to sys/types.h file. Signed-off-by: Youvedeep Singh <[email protected]>

This patch provides pthread APIs for POSIX 1003.1 PSE52 standard. Signed-off-by: Youvedeep Singh <[email protected]>

This patch provides scheduler APIs for POSIX 1003.1 PSE52 standard. Signed-off-by: Youvedeep Singh <[email protected]>

This patch provides POSIX sleep APIs for POSIX 1003.1 PSE52 standard. sleep(n) is implemented using Zephyr k_sleep API. uleep(n) is implemented using Zephyr k_sleep/k_busy_Wait API. Signed-off-by: Youvedeep Singh <[email protected]>

This patch provides POSIX clock APIs for POSIX 1003.1 PSE52 standard. Signed-off-by: Youvedeep Singh <[email protected]>

This patch removes unused member element from POSIX object attributes (mutex, condition variable and barrier). Signed-off-by: Youvedeep Singh <[email protected]>

Implement pthread_join test application. Signed-off-by: Youvedeep Singh <[email protected]>

Add posix clock API test. Signed-off-by: Youvedeep Singh <[email protected]>

This test is POSIX based implementation of tests:kernel:pthread test. It used POSIX APIs instead of Zephyr APIs. Signed-off-by: Youvedeep Singh <[email protected]>

Added test for POSIX thread cancel APIs. Signed-off-by: Youvedeep Singh <[email protected]>

This patch provides POSIX timer APIs for POSIX 1003.1 PSE52 standard. Signed-off-by: Youvedeep Singh <[email protected]>

Added test for POSIX timer APIs. Signed-off-by: Youvedeep Singh <[email protected]>

Some of APIs of POSIX implmentation layer has same name as native_posix architecture. posix_cheats.h is used to handle this duplication in API name. Adding a guard in posix_cheats.h based on CONFIG_PTHREAD_API. Signed-off-by: Youvedeep Singh <[email protected]>

youvedeep requested review from andrewboie, andyross, nashif and SebastianBoe as code owners January 13, 2018 17:45

youvedeep requested a review from lpereira January 13, 2018 17:46

This was referenced Jan 13, 2018

kernel: posix: typedef should be defined into types.h file. #5545

Closed

kernel: posix: implement schedule related APIs for POSIX. #5510

Closed

Pthread sleep #5507

Closed

Posix pthread #5494

Closed

youvedeep requested a review from punitvara January 13, 2018 17:51

youvedeep force-pushed the Posix_Implementation_Layer branch 2 times, most recently from 871177c to 6e82ccd Compare January 14, 2018 09:38

SebastianBoe removed their request for review January 15, 2018 14:40

aescolar reviewed Jan 15, 2018

View reviewed changes

lpereira suggested changes Jan 16, 2018

View reviewed changes

youvedeep force-pushed the Posix_Implementation_Layer branch from 6e82ccd to d56ecad Compare January 17, 2018 10:12

youvedeep force-pushed the Posix_Implementation_Layer branch from d56ecad to 02f1655 Compare January 18, 2018 16:19

lpereira reviewed Jan 19, 2018

View reviewed changes

andrewboie suggested changes Jan 23, 2018

View reviewed changes

youvedeep force-pushed the Posix_Implementation_Layer branch from 02f1655 to efca769 Compare January 28, 2018 17:06

lpereira suggested changes Jan 31, 2018

View reviewed changes

nashif added this to the v1.11.0 milestone Jan 31, 2018

jmtorrespalma mentioned this pull request Feb 2, 2018

kernel: posix: implementation of POSIX semaphores #5955

Closed

youvedeep force-pushed the Posix_Implementation_Layer branch from efca769 to f3dca31 Compare February 3, 2018 08:15

lpereira reviewed Feb 15, 2018

View reviewed changes

youvedeep force-pushed the Posix_Implementation_Layer branch from 9fd2ae7 to abe7859 Compare February 15, 2018 14:29

youvedeep force-pushed the Posix_Implementation_Layer branch 3 times, most recently from e348fbd to b39dc64 Compare February 16, 2018 07:47

lpereira reviewed Feb 21, 2018

View reviewed changes

youvedeep force-pushed the Posix_Implementation_Layer branch from b39dc64 to 1e92b5a Compare February 21, 2018 16:03

youvedeep-singh added 14 commits February 21, 2018 23:15

kernel: POSIX: Fixing return value of POSIX APIs on error.

3f10d3d

As per IEEE 1003.1 POSIX APIs should return ERROR_CODE on error. But currently these are returning -ERROR_CODE instead of ERROR_CODE. So fixing the return value. Signed-off-by: Youvedeep Singh <[email protected]>

kernel: POSIX: moving POSIX related typedef into sys/types.h file.

c29dd0d

As per POSIX standard typedef should be part of sys/types.h file. So moving typedef from pthread.h to sys/types.h file. Signed-off-by: Youvedeep Singh <[email protected]>

kernel: POSIX: Compatibility layer for pthread APIs.

7f17666

This patch provides pthread APIs for POSIX 1003.1 PSE52 standard. Signed-off-by: Youvedeep Singh <[email protected]>

kernel: POSIX: Compatibility layer for scheduler APIs.

9f7747d

This patch provides scheduler APIs for POSIX 1003.1 PSE52 standard. Signed-off-by: Youvedeep Singh <[email protected]>

kernel: POSIX: Compatibility layer for POSIX clock APIs.

b845895

This patch provides POSIX clock APIs for POSIX 1003.1 PSE52 standard. Signed-off-by: Youvedeep Singh <[email protected]>

kernel: POSIX: removing unused elements from POSIX object attribute.

347fc61

This patch removes unused member element from POSIX object attributes (mutex, condition variable and barrier). Signed-off-by: Youvedeep Singh <[email protected]>

tests: kernel: posix: pthread_join: Add pthread join test.

2261f14

Implement pthread_join test application. Signed-off-by: Youvedeep Singh <[email protected]>

tests: kernel: posix: clock: Add posix clock test.

7181b09

Add posix clock API test. Signed-off-by: Youvedeep Singh <[email protected]>

tests: kernel: posix: pthread: Add pthread test.

cef171e

This test is POSIX based implementation of tests:kernel:pthread test. It used POSIX APIs instead of Zephyr APIs. Signed-off-by: Youvedeep Singh <[email protected]>

tests: kernel: posix: pthread_cancel: POSIX thread cancel test.

da5609c

Added test for POSIX thread cancel APIs. Signed-off-by: Youvedeep Singh <[email protected]>

kernel: POSIX: Compatibility layer for POSIX timer APIs.

4d8bad8

This patch provides POSIX timer APIs for POSIX 1003.1 PSE52 standard. Signed-off-by: Youvedeep Singh <[email protected]>

tests: kernel: posix: timer: POSIX timer test.

a4d00b5

Added test for POSIX timer APIs. Signed-off-by: Youvedeep Singh <[email protected]>

youvedeep force-pushed the Posix_Implementation_Layer branch from 1e92b5a to 9ae6024 Compare February 21, 2018 17:46

nashif approved these changes Feb 22, 2018

View reviewed changes

nashif merged commit 4d72e48 into zephyrproject-rtos:master Feb 22, 2018

nashif mentioned this pull request Feb 22, 2018

Initial Posix PSE52 Support #1291

Closed

12 tasks

golowanow mentioned this pull request Jan 14, 2024

posix: sched: Implement sched_getparam() and sched_getscheduler() #67028

Merged

Posix implementation layer #5667

Posix implementation layer #5667

Conversation

youvedeep commented Jan 13, 2018 • edited Loading

codecov-io commented Jan 13, 2018 • edited Loading

Codecov Report

aescolar Jan 15, 2018 • edited Loading

Choose a reason for hiding this comment

aescolar Jan 15, 2018 • edited Loading

Choose a reason for hiding this comment

lpereira left a comment

Choose a reason for hiding this comment

lpereira Jan 16, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lpereira Jan 16, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

youvedeep commented Jan 17, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lpereira Jan 19, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

youvedeep Jan 22, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lpereira commented Jan 19, 2018

andrewboie left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

youvedeep commented Jan 28, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lpereira Jan 31, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lpereira commented Jan 31, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

youvedeep Feb 15, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

youvedeep Feb 15, 2018 • edited Loading

Choose a reason for hiding this comment

youvedeep commented Feb 15, 2018

youvedeep commented Feb 16, 2018

youvedeep commented Feb 17, 2018

lpereira left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

youvedeep Feb 21, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

youvedeep Feb 21, 2018 • edited Loading

Choose a reason for hiding this comment

lpereira Feb 21, 2018 • edited by youvedeep Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

youvedeep commented Jan 13, 2018 •

edited

Loading

codecov-io commented Jan 13, 2018 •

edited

Loading

aescolar Jan 15, 2018 •

edited

Loading

aescolar Jan 15, 2018 •

edited

Loading

lpereira Jan 16, 2018 •

edited

Loading

lpereira Jan 16, 2018 •

edited

Loading

lpereira Jan 19, 2018 •

edited

Loading

youvedeep Jan 22, 2018 •

edited

Loading

lpereira Jan 31, 2018 •

edited

Loading

youvedeep Feb 15, 2018 •

edited

Loading

youvedeep Feb 15, 2018 •

edited

Loading

youvedeep Feb 21, 2018 •

edited

Loading

youvedeep Feb 21, 2018 •

edited

Loading

lpereira Feb 21, 2018 •

edited by youvedeep

Loading

youvedeep Feb 21, 2018 •

edited

Loading