Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement sigtimedwait for use by suckless init #1320

Open
wants to merge 48 commits into
base: master
Choose a base branch
from

Conversation

cahirwpz
Copy link
Owner

@cahirwpz cahirwpz commented Jul 26, 2022

Implement sigtimedwait system call.

@cahirwpz cahirwpz added the WiP not ready for code review label Jul 26, 2022
@cahirwpz
Copy link
Owner Author

cahirwpz commented Jan 1, 2023

@panantoni01 Please extract sinit to another PR according to new method of importing external software. Please take into account etc/ directory as well as stub of sigtimedwait syscall. Just leave implementation of sys_sigtimedwait and its userspace tests to @korbiniak.

sys/kern/signal.c Outdated Show resolved Hide resolved
Copy link
Collaborator

@franciscozdo franciscozdo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly minor changes or questions, because I am not an expert in signals.

I am also wondering what are the files etc/rc.init and etc/rc.shutdown. I think they are not needed by any of changes in this PR.

sys/kern/syscalls.c Outdated Show resolved Hide resolved
include/sys/syscallargs.h Outdated Show resolved Hide resolved
td->td_flags |= (timeout > 0) ? TDF_SLPTIMED : TDF_SLPINTR;
td->td_flags |= TDF_SLPINTR;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not familiar with sleepq, but was there a reason why we chose TDF_SLPINTR only when we hadn't got a timeout? You have changed the semantics here and I cant tell if it is correct.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I did change the semantics as I think it was a bug that TDF_SLPINTR was not set. See discussion here: https://discord.com/channels/951841212267130950/1054133625731424337

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I agree with that, but I also think that @cahirwpz should take a look at that.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it has to do with possible deficiencies in sleepq API. ATM we have two wait functions - with and without timeout. IMO there should be wait and wait_intr with optional timeout. That should let us express all use cases for putting a thread to sleep.

Please note that non-interruptible wait should probably be only used by the code that does not interface user-space directly - i.e. the code that does not understand the concept of a signal or need not be burdened with complexity of extra error handling (ETIMEDOUT). Examples would be waking up a thread from interrupt or "fast" device drivers code. On contrary the interruptible wait should be used in "slow" device drivers code (where read or write may be interrupted) and all syscalls that can tolerate being interrupted.

Perhaps what I wrote above should be redacted and put somewhere into sleepq.h.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To answer the question - the change is ok, since function is documented as follows:

/*! \brief Performs interruptible sleep with timeout.
 *
 * Timed sleep is also interruptible. [...]
 */

sys/kern/signal.c Outdated Show resolved Hide resolved
sys/kern/signal.c Outdated Show resolved Hide resolved
sys/kern/signal.c Outdated Show resolved Hide resolved
@franciscozdo franciscozdo added review please review this PR and removed WiP not ready for code review labels Jan 18, 2023
bin/utest/signal.c Outdated Show resolved Hide resolved
/* ======= signal_sigtimedwait_timeout ======= */
static int sigusr2_handled = 0;

void sigtimedwait_timeout_sigusr2_handler(int signo) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why don't you name it sigusr2_handler?

Copy link
Collaborator

@korbiniak korbiniak Jan 19, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This way I know that some particular test will be the only user of this function.
Suppose someone in the future would like to use the sigusr2 for testing, then they'd need to create a new function, how would they name it then? They could reuse this function, but I advise against that. If one would like to change the behavior of the handler for some particular test they'd need to create a new function and give it some other name anyway.

EDIT: Maybe it's an overkill, I don't know, wdyt?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggested it because I see that in other signal tests we name functions that looks like that always in the same way. These functions are used in multiple tests and I think there is nothing wrong in that (they are used identically so why we would like to duplicate code?).

If you would like to add some functionality to such function then it is a reason to make function with unique name (and leave the old one unchanged because we expect some specific behavior from it).

@cahirwpz @pwit81 I think that we can think about making such function a standard. They are used pretty often and maybe we don't have to invent new functions for just handling one signal for every written test?

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@franciscozdo @korbiniak It's definitely a good idea to factor it out.

I'd do it by extending our current utest.h interface by adding:

  • void signal_count(int signo) - registers a generic handler for signo signal,
  • int signal_counter(int signo) - returns a number of times signal signo was delivered.

If you have a better idea how to name those functions then feel free to do so.

bin/utest/signal.c Outdated Show resolved Hide resolved
bin/utest/signal.c Outdated Show resolved Hide resolved
bin/utest/signal.c Outdated Show resolved Hide resolved
sys/kern/signal.c Outdated Show resolved Hide resolved
sys/kern/syscalls.c Outdated Show resolved Hide resolved
Copy link
Collaborator

@pj1031999 pj1031999 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is a purpose of /etc/rc.init /etc/rc.shutdown? How it is related to sigtimedwait or /dev/tty?

bin/utest/signal.c Outdated Show resolved Hide resolved
bin/utest/signal.c Show resolved Hide resolved
bin/utest/signal.c Outdated Show resolved Hide resolved
bin/utest/signal.c Outdated Show resolved Hide resolved
bin/utest/signal.c Outdated Show resolved Hide resolved
bin/utest/signal.c Outdated Show resolved Hide resolved
sys/kern/syscalls.c Outdated Show resolved Hide resolved
sys/kern/sleepq.c Outdated Show resolved Hide resolved
sys/kern/signal.c Show resolved Hide resolved
sys/kern/signal.c Show resolved Hide resolved
include/sys/signal.h Outdated Show resolved Hide resolved
@cahirwpz
Copy link
Owner Author

@korbiniak I'd like to take over the PR and finish the work. WDYT?

@cahirwpz cahirwpz changed the title Add kernel support for running /sbin/init correctly Implement sigtimedwait for use by suckless init Jun 15, 2023
cahirwpz added a commit that referenced this pull request Jul 28, 2023
franciscozdo pushed a commit that referenced this pull request Aug 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
review please review this PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants