Create timer reqs

[parphane]

Imported files from #75
Fixes changes per #75 comments
Updated terminology, simplified requirements and updated requirements ID
Closes #65

[woodmatthews]

I have reviewed, but wanted to check which portion of the code these requirements are intended to map to. I used timer.c in the kernel section - https://github.com/zephyrproject-rtos/zephyr/blob/5c7c3980eb0600a058d4355e3d101078f88d26dc/kernel/timer.c#L189

I understand all of the requirements as written and agree with them, but wanted to check that the list is complete. timer.c also references multithreading and has code comments for safety which I don't see in this PR.

[parphane]

I have reviewed, but wanted to check which portion of the code these requirements are intended to map to. I used timer.c in the kernel section - https://github.com/zephyrproject-rtos/zephyr/blob/5c7c3980eb0600a058d4355e3d101078f88d26dc/kernel/timer.c#L189

I understand all of the requirements as written and agree with them, but wanted to check that the list is complete. timer.c also references multithreading and has code comments for safety which I don't see in this PR.

The requirements were written of https://docs.zephyrproject.org/apidoc/latest/group__timer__apis.html (which will be used/modified in future as unit/component design reqs)
Anything not documented there would be an omission to be fixed.

I haven't reviewed all the code re safety/user space/multithreading.
Of what I saw though:

• Functions for user space are adding a mem access right/sanity check through K_OOPS, which I would classify as a design choice (result of architectural process then documented in a unit/component design) for these threads trying to access timers may not belong to their user space.
• For Multithreading, I would assume the same. There would be a requirements for zephyr to support multithreading, and then the impacts/needs are thought at the architectural level and implemented in units/components
• Re potential omission, I believe the specific behavior for user space shall be documented, in the docs. Else we will have functional coverage gap. Likewise for multithreading specific behavior, else we will have branch coverage gap

I may be missing part of your remark though as I do not have the tech. knowledge

[woodmatthews]

Thank you. I will then mark this PR reviewed and approve.

[woodmatthews]

I am not an approving reviewer for this task so it does not look like I can move this past the current status.

[parphane]

@woodmatthews I just added you as reviewer.
I will also need to perform an update for the new SDOC section format before merging.
Per #92

[woodmatthews]

I have reviewed this PR and compared with the API documentation.

[woodmatthews]

Approvals are in for 88, 89, and 90. Matt

…

________________________________ From: Stéphane PARENTI ***@***.***> Sent: Tuesday, July 29, 2025 9:55 AM To: zephyrproject-rtos/reqmgmt ***@***.***> Cc: Wood, Matthew (US-DF) ***@***.***>; Mention ***@***.***> Subject: Re: [zephyrproject-rtos/reqmgmt] Create timer reqs (PR #88) [https://avatars.githubusercontent.com/u/5610045?s=20&v=4]parphane left a comment (zephyrproject-rtos/reqmgmt#88)<#88 (comment)> @woodmatthews<https://github.com/woodmatthews> I just added you as reviewer — Reply to this email directly, view it on GitHub<#88 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BMEL4UKLIBKHQWBC2LVHZQD3K54NDAVCNFSM6AAAAAB7WPDH2SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTCMZSGY2DOOBUGE>. You are receiving this because you were mentioned.Message ID: ***@***.***>