mailing list of musl libc
 help / color / mirror / code / Atom feed
* Re: [musl] [PATCH 1/3 libc-test] functional:time:clock_nanosleep test
@ 2024-11-07  4:39 Gardner, Ryan P
  2024-11-10 11:45 ` Szabolcs Nagy
  2024-11-13 11:51 ` Szabolcs Nagy
  0 siblings, 2 replies; 8+ messages in thread
From: Gardner, Ryan P @ 2024-11-07  4:39 UTC (permalink / raw)
  To: musl

Szabolcs Nagy <nsz@...t70.net> writes:

> thanks
> patches look good. but it will take a week or two
> for me to be able to test and apply them.

Thank you for the quick response. We appreciate your timeline for testing and applying the patches.

Our plan is to submit tests for the majority of functions that currently lack coverage within libc-test. 
We already have a significant number of tests written and ready for submission. To avoid overwhelming
you with patches, do you have a preferred cadence for the submission of these tests?

Additionally, we are planning to setup runtime tests in collaboration with the Buildroot community. This
would facilitate testing across various embedded configurations and processor architectures. Once up 
and running, when we submit new test patches we can reference a fork of Buildroot that shows the tests 
passing on various hardware configurations.

Looking forward to your guidance,
Ryan Gardner

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [musl] [PATCH 1/3 libc-test] functional:time:clock_nanosleep test
  2024-11-07  4:39 [musl] [PATCH 1/3 libc-test] functional:time:clock_nanosleep test Gardner, Ryan P
@ 2024-11-10 11:45 ` Szabolcs Nagy
  2024-12-04  1:19   ` [musl] RE: [EXTERNAL] " Ward, Ryan C
  2024-11-13 11:51 ` Szabolcs Nagy
  1 sibling, 1 reply; 8+ messages in thread
From: Szabolcs Nagy @ 2024-11-10 11:45 UTC (permalink / raw)
  To: Gardner, Ryan P; +Cc: musl

* Gardner, Ryan P <ryan.p.gardner@boeing.com> [2024-11-07 04:39:59 +0000]:
> Szabolcs Nagy <nsz@...t70.net> writes:
> 
> > thanks
> > patches look good. but it will take a week or two
> > for me to be able to test and apply them.
> 
> Thank you for the quick response. We appreciate your timeline for testing and applying the patches.
> 
> Our plan is to submit tests for the majority of functions that currently lack coverage within libc-test. 
> We already have a significant number of tests written and ready for submission. To avoid overwhelming
> you with patches, do you have a preferred cadence for the submission of these tests?
> 

over the next month im only in front of a computer sporadically

but code style or quality of tests are less strict than for libc,
so i dont expect many iterations. just post the patches so when i
can take a look i can comment or apply them.

btw if there is a repo with a branch i can cherrypick from that
is a bit easier for me than handling mails. then i think you
dont even have to post "obvious" patches to the list. i can pick
them from the branch.

> Additionally, we are planning to setup runtime tests in collaboration with the Buildroot community. This
> would facilitate testing across various embedded configurations and processor architectures. Once up 
> and running, when we submit new test patches we can reference a fork of Buildroot that shows the tests 
> passing on various hardware configurations.

nice.

the infra in libc-test is not amazing for continous tests.
when i get to it i will try to improve it.

> 
> Looking forward to your guidance,
> Ryan Gardner

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [musl] [PATCH 1/3 libc-test] functional:time:clock_nanosleep test
  2024-11-07  4:39 [musl] [PATCH 1/3 libc-test] functional:time:clock_nanosleep test Gardner, Ryan P
  2024-11-10 11:45 ` Szabolcs Nagy
@ 2024-11-13 11:51 ` Szabolcs Nagy
  1 sibling, 0 replies; 8+ messages in thread
From: Szabolcs Nagy @ 2024-11-13 11:51 UTC (permalink / raw)
  To: Gardner, Ryan P; +Cc: musl

* Gardner, Ryan P <ryan.p.gardner@boeing.com> [2024-11-07 04:39:59 +0000]:

> Szabolcs Nagy <nsz@...t70.net> writes:
> 
> > thanks
> > patches look good. but it will take a week or two
> > for me to be able to test and apply them.
> 
> Thank you for the quick response. We appreciate your timeline for testing and applying the patches.

applied the patches and added you to authors
(which is not very formal, more for acknowledgement)

thanks.

> 
> Our plan is to submit tests for the majority of functions that currently lack coverage within libc-test. 
> We already have a significant number of tests written and ready for submission. To avoid overwhelming
> you with patches, do you have a preferred cadence for the submission of these tests?
> 
> Additionally, we are planning to setup runtime tests in collaboration with the Buildroot community. This
> would facilitate testing across various embedded configurations and processor architectures. Once up 
> and running, when we submit new test patches we can reference a fork of Buildroot that shows the tests 
> passing on various hardware configurations.
> 
> Looking forward to your guidance,
> Ryan Gardner

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [musl] RE: [EXTERNAL] Re: [musl] [PATCH 1/3 libc-test] functional:time:clock_nanosleep test
  2024-11-10 11:45 ` Szabolcs Nagy
@ 2024-12-04  1:19   ` Ward, Ryan C
  2024-12-04 21:42     ` Szabolcs Nagy
  0 siblings, 1 reply; 8+ messages in thread
From: Ward, Ryan C @ 2024-12-04  1:19 UTC (permalink / raw)
  To: musl; +Cc: nsz

*Szabolcs Nagy <nsz@...t70.net> writes:
> Gardner, Ryan P <ryan.p.gardner@boeing.com> [2024-11-07 04:39:59 +0000]:
> > Szabolcs Nagy <nsz@...t70.net> writes:
> >  
> > > thanks
> > > patches look good. but it will take a week or two for me to be able 
> > > to test and apply them.
> > 
> > Thank you for the quick response. We appreciate your timeline for testing and applying the patches.
> > 
> > Our plan is to submit tests for the majority of functions that currently lack coverage within libc-test. 
> > We already have a significant number of tests written and ready for 
> > submission. To avoid overwhelming you with patches, do you have a preferred cadence for the submission of these tests?
> > 
>
> over the next month im only in front of a computer sporadically
>
> but code style or quality of tests are less strict than for libc, so i dont expect many iterations. just post the patches so when i can take a look i can comment or apply them.
>
> btw if there is a repo with a branch i can cherrypick from that is a bit easier for me than handling mails. then i think you dont even have to post "obvious" patches to the list. i can pick them from the branch.

Hi, we have now pushed some scripts we have used during development to
to our external staging branch, located here:

https://github.com/Boeing/libc-test/tree/boeing-staging-next-libc-test/rfc/rfc_add_testing_scripts 

This email serves as an RFC for adding some test scripting/infrastructure, with
an overview provided:

run_tests:
A simple shell script that was written to assist with continuous testing, 
both locally and a CI/CD pipeline.

The script serves to provide a more verbose output of both passed and failed
tests, and assumes that musl has been installed in the default directory of
`/usr/local/musl`.

The `run_tests` script can be used with the `-r` flag to generate test coverage
reports of libc-test on the musl shared object. However, this option is more involved, 
and requires the user to have at least clang and llvm 19 installed on the host system. 
It also requires that `musl` has been build, installed and instrumented with the 
`-fprofile-instr-generate` and `-fcoverage-mapping` flags.

Note that some `*printf_chk()` functions will need to be implemented (as stubs)
for musl to compile. An example patch has been added, outlining the necessary
functions that need to be implemented.

stress_test:
Another simple shell script to run newly added multiple times to catch any 
missed edge cases, particularly in the context of timing/synchronisation.

> > Additionally, we are planning to setup runtime tests in collaboration 
> > with the Buildroot community. This would facilitate testing across 
> > various embedded configurations and processor architectures. Once up 
> > and running, when we submit new test patches we can reference a fork of Buildroot that shows the tests passing on various hardware configurations.
>
> nice.
>
> the infra in libc-test is not amazing for continous tests.
> when i get to it i will try to improve it.

Kind regards,

Ryan W


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [musl] RE: [EXTERNAL] Re: [musl] [PATCH 1/3 libc-test] functional:time:clock_nanosleep test
  2024-12-04  1:19   ` [musl] RE: [EXTERNAL] " Ward, Ryan C
@ 2024-12-04 21:42     ` Szabolcs Nagy
  0 siblings, 0 replies; 8+ messages in thread
From: Szabolcs Nagy @ 2024-12-04 21:42 UTC (permalink / raw)
  To: Ward, Ryan C; +Cc: musl

* Ward, Ryan C <ryan.c.ward3@boeing.com> [2024-12-04 01:19:34 +0000]:

> *Szabolcs Nagy <nsz@...t70.net> writes:
> > Gardner, Ryan P <ryan.p.gardner@boeing.com> [2024-11-07 04:39:59 +0000]:
> > > Szabolcs Nagy <nsz@...t70.net> writes:
> > >  
> > > > thanks
> > > > patches look good. but it will take a week or two for me to be able 
> > > > to test and apply them.
> > > 
> > > Thank you for the quick response. We appreciate your timeline for testing and applying the patches.
> > > 
> > > Our plan is to submit tests for the majority of functions that currently lack coverage within libc-test. 
> > > We already have a significant number of tests written and ready for 
> > > submission. To avoid overwhelming you with patches, do you have a preferred cadence for the submission of these tests?
> > > 
> >
> > over the next month im only in front of a computer sporadically
> >
> > but code style or quality of tests are less strict than for libc, so i dont expect many iterations. just post the patches so when i can take a look i can comment or apply them.
> >
> > btw if there is a repo with a branch i can cherrypick from that is a bit easier for me than handling mails. then i think you dont even have to post "obvious" patches to the list. i can pick them from the branch.
> 
> Hi, we have now pushed some scripts we have used during development to
> to our external staging branch, located here:
> 
> https://github.com/Boeing/libc-test/tree/boeing-staging-next-libc-test/rfc/rfc_add_testing_scripts 
> 
> This email serves as an RFC for adding some test scripting/infrastructure, with
> an overview provided:

thanks for doing this.

fyi i'm travelling and my laptop got stolen.

will be able to recover. but it will take a while.
the integrity of the repo is not in danger.

> 
> run_tests:
> A simple shell script that was written to assist with continuous testing, 
> both locally and a CI/CD pipeline.
> 
> The script serves to provide a more verbose output of both passed and failed
> tests, and assumes that musl has been installed in the default directory of
> `/usr/local/musl`.
> 
> The `run_tests` script can be used with the `-r` flag to generate test coverage
> reports of libc-test on the musl shared object. However, this option is more involved, 
> and requires the user to have at least clang and llvm 19 installed on the host system. 
> It also requires that `musl` has been build, installed and instrumented with the 
> `-fprofile-instr-generate` and `-fcoverage-mapping` flags.
> 
> Note that some `*printf_chk()` functions will need to be implemented (as stubs)
> for musl to compile. An example patch has been added, outlining the necessary
> functions that need to be implemented.
> 
> stress_test:
> Another simple shell script to run newly added multiple times to catch any 
> missed edge cases, particularly in the context of timing/synchronisation.
> 
> > > Additionally, we are planning to setup runtime tests in collaboration 
> > > with the Buildroot community. This would facilitate testing across 
> > > various embedded configurations and processor architectures. Once up 
> > > and running, when we submit new test patches we can reference a fork of Buildroot that shows the tests passing on various hardware configurations.
> >
> > nice.
> >
> > the infra in libc-test is not amazing for continous tests.
> > when i get to it i will try to improve it.
> 
> Kind regards,
> 
> Ryan W

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [musl] [PATCH 1/3 libc-test] functional:time:clock_nanosleep test
@ 2024-11-15  5:16 Gardner, Ryan P
  0 siblings, 0 replies; 8+ messages in thread
From: Gardner, Ryan P @ 2024-11-15  5:16 UTC (permalink / raw)
  To: musl; +Cc: Weber (US), Matthew L

[-- Attachment #1: Type: text/plain, Size: 792 bytes --]

Szabolcs Nagy <nsz@...t70.net> writes:

> over the next month im only in front of a computer sporadically

> but code style or quality of tests are less strict than for libc,
> so i dont expect many iterations. just post the patches so when i
> can take a look i can comment or apply them.

> btw if there is a repo with a branch i can cherrypick from that
> is a bit easier for me than handling mails. then i think you
> dont even have to post "obvious" patches to the list. i can pick
> them from the branch.

That works well for us, here is our branch -
https://github.com/Boeing/libc-test/tree/boeing-staging-next-libc-test

This branch hasn't quite got every test we have written so far on it,
but it should be up to date within the next week.

Thanks,
Ryan Gardner

[-- Attachment #2: Type: text/html, Size: 3240 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [musl] [PATCH 1/3 libc-test] functional:time:clock_nanosleep test
  2024-11-05 22:44 Ryan Gardner
@ 2024-11-06  7:38 ` Szabolcs Nagy
  0 siblings, 0 replies; 8+ messages in thread
From: Szabolcs Nagy @ 2024-11-06  7:38 UTC (permalink / raw)
  To: Ryan Gardner; +Cc: musl

* Ryan Gardner <ryan.p.gardner@boeing.com> [2024-11-05 22:44:35 +0000]:
> Testing of musl API against POSIX 2008 standard.
> 
> Tests added:
> 
> - EINTR is returned when sleep is interupted by a signal
> - ENOTSUP is returned when clock_id specifies an unsupported clock
> - EINVAL is returned when tv_nsec is out of range
> - EINVAL is returned when clock_id specifies an unknown clock

this is technically not futureproof as new clocks may be introduced
it's a common issue i dont have a good solution for.
but i think it's fine to pick an int for now.

> - EINVAL is returned when clokc_id specifies the CPU-time clock of calling thread
> - rmtp is set to the remaining unslept time when interupted.
> - time elapses as expected
> 
> References:
> - https://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_nanosleep.html
> 
> Signed-off-by: Ryan Gardner <ryan.p.gardner@boeing.com>

thanks
patches look good. but it will take a week or two
for me to be able to test and apply them.


^ permalink raw reply	[flat|nested] 8+ messages in thread

* [musl] [PATCH 1/3 libc-test] functional:time:clock_nanosleep test
@ 2024-11-05 22:44 Ryan Gardner
  2024-11-06  7:38 ` Szabolcs Nagy
  0 siblings, 1 reply; 8+ messages in thread
From: Ryan Gardner @ 2024-11-05 22:44 UTC (permalink / raw)
  To: musl; +Cc: Ryan Gardner

Testing of musl API against POSIX 2008 standard.

Tests added:

- EINTR is returned when sleep is interupted by a signal
- ENOTSUP is returned when clock_id specifies an unsupported clock
- EINVAL is returned when tv_nsec is out of range
- EINVAL is returned when clock_id specifies an unknown clock
- EINVAL is returned when clokc_id specifies the CPU-time clock of calling thread
- rmtp is set to the remaining unslept time when interupted.
- time elapses as expected

References:
- https://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_nanosleep.html

Signed-off-by: Ryan Gardner <ryan.p.gardner@boeing.com>
---
 src/functional/clock_nanosleep.c | 133 +++++++++++++++++++++++++++++++
 1 file changed, 133 insertions(+)
 create mode 100644 src/functional/clock_nanosleep.c

diff --git a/src/functional/clock_nanosleep.c b/src/functional/clock_nanosleep.c
new file mode 100644
index 0000000..071000a
--- /dev/null
+++ b/src/functional/clock_nanosleep.c
@@ -0,0 +1,133 @@
+/*
+ * clock_nanosleep unit test
+ */
+
+#include "test.h"
+#include <errno.h>
+#include <signal.h>
+#include <string.h>
+#include <time.h>
+
+#define MAX_NSEC 1000000000
+#define SLEEP_NANO 500000
+#define TEST(c, ...) ((c) || (t_error(#c " failed: " __VA_ARGS__), 0))
+
+static void dummy_signal_handler(int signum) {}
+
+static void test_time_elapsed(void)
+{
+	// get start time
+	struct timespec time1;
+	if (clock_gettime(CLOCK_MONOTONIC, &time1) == -1) {
+		t_error("clock_gettime() failed. Errno: %s\n", strerror(errno));
+		return;
+	}
+
+	struct timespec ts = {0, SLEEP_NANO};
+	TEST(clock_nanosleep(CLOCK_MONOTONIC, 0, &ts, &ts) == 0,
+	     "clock_nanosleep failed with clock id %d\n", CLOCK_MONOTONIC);
+
+	// get finish time
+	struct timespec time2;
+	if (clock_gettime(CLOCK_MONOTONIC, &time2) == -1) {
+		t_error("clock_gettime() failed. Errno: %s\n", strerror(errno));
+		return;
+	}
+
+	// calculate elapsed time
+	time_t elapsed = time2.tv_sec > time1.tv_sec
+	                     ? time2.tv_nsec + (MAX_NSEC - time1.tv_nsec)
+	                     : time2.tv_nsec - time1.tv_nsec;
+
+	TEST(elapsed >= SLEEP_NANO,
+	     "Elapsed time test failed: expected >= %d "
+	     "nanoseconds, got %ld nanoseconds.\n",
+	     SLEEP_NANO, elapsed);
+}
+
+static void test_invalid_inputs(void)
+{
+	struct timespec ts = {1, 0};
+
+	// check EINVAL is returned when tv_nsec is too big
+	ts.tv_nsec = MAX_NSEC;
+	int retval = clock_nanosleep(CLOCK_MONOTONIC, 0, &ts, NULL);
+	TEST(retval == EINVAL,
+	     "Oversized tv_nsec test failed: Expected %s, got %s\n",
+	     strerror(EINVAL), strerror(retval));
+
+	// check EINVAL is returned when tv_nsec is too small
+	ts.tv_nsec = -1;
+	retval = clock_nanosleep(CLOCK_MONOTONIC, 0, &ts, NULL);
+	TEST(retval == EINVAL,
+	     "Undersized tv_nsec test failed: Expected %s, got %s\n",
+	     strerror(EINVAL), strerror(retval));
+
+	// check EINVAL is returned when given CPU_time clock of calling thread
+	retval = clock_nanosleep(CLOCK_THREAD_CPUTIME_ID, 0, &ts, NULL);
+	TEST(retval == EINVAL,
+	     "Calling threads cpu clock id test failed: Expected %s, got %s\n",
+	     strerror(EINVAL), strerror(retval));
+
+	const int unknown_clock = 123;
+
+	// check EINVAL is returned when given unknown clock
+	retval = clock_nanosleep(unknown_clock, 0, &ts, NULL);
+	TEST(retval == EINVAL,
+	     "Unknown clock id test failed: Expected %s, got %s\n",
+	     strerror(EINVAL), strerror(retval));
+
+	// check ENOTSUP is returned when given an unsupported clock
+	retval = clock_nanosleep(CLOCK_MONOTONIC_COARSE, 0, &ts, NULL);
+	TEST(retval == ENOTSUP,
+	     "Unsupported clock test failed. Expected %s, got %s\n",
+	     strerror(ENOTSUP), strerror(retval));
+}
+
+static void test_interupted_sleep()
+{
+	// check EINTR is returned when sleep is interupted by a signal handler
+	struct sigaction sa;
+	memset(&sa, 0, sizeof(sa));
+	sa.sa_handler = dummy_signal_handler;
+	sigaction(SIGALRM, &sa, NULL);
+
+	timer_t timerid = NULL;
+	if (timer_create(CLOCK_MONOTONIC, NULL, &timerid) == -1) {
+		t_error("timer_create() failed. Errno: %s\n", strerror(errno));
+		return;
+	}
+
+	struct itimerspec its = {
+	    .it_value.tv_sec = 0,
+	    .it_value.tv_nsec = SLEEP_NANO,
+	};
+	if (timer_settime(timerid, 0, &its, NULL) == -1) {
+		t_error("timer_settime() failed. Errno: %s\n", strerror(errno));
+		timer_delete(timerid);
+		return;
+	}
+
+	struct timespec ts = {2, 0};
+	struct timespec rmtp = {0, 0};
+	int retval = clock_nanosleep(CLOCK_MONOTONIC, 0, &ts, &rmtp);
+
+	TEST(retval == EINTR, "Interupted sleep test failed: Expected %s, got %s\n",
+	     strerror(EINTR), strerror(retval));
+
+	// check that the remaining unslept time is returned into rmtp
+	TEST(rmtp.tv_sec > 0 || rmtp.tv_nsec > 0,
+	     "rmtp test failed: Expected value > 0, got rmpt.tv_sec = %lu, "
+	     "rmtp.tv_nsec = %lu\n",
+	     rmtp.tv_sec, rmtp.tv_nsec);
+
+	timer_delete(timerid);
+}
+
+int main(void)
+{
+	test_time_elapsed();
+	test_invalid_inputs();
+	test_interupted_sleep();
+	return t_status;
+}
-- 
2.34.1


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2024-12-04 21:43 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-11-07  4:39 [musl] [PATCH 1/3 libc-test] functional:time:clock_nanosleep test Gardner, Ryan P
2024-11-10 11:45 ` Szabolcs Nagy
2024-12-04  1:19   ` [musl] RE: [EXTERNAL] " Ward, Ryan C
2024-12-04 21:42     ` Szabolcs Nagy
2024-11-13 11:51 ` Szabolcs Nagy
  -- strict thread matches above, loose matches on Subject: below --
2024-11-15  5:16 Gardner, Ryan P
2024-11-05 22:44 Ryan Gardner
2024-11-06  7:38 ` Szabolcs Nagy

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).