Allow finer selection of io

[Firstyear]

Motivation

#3520

Allow fine-grained selection of enabled drivers.

Solution

Use multiple booleans and add more options.

This is a very rough patch, and probably will cause some issues or hit edge cases that I don't understand or forsee, so any advice would be really appreciated!

[ipetkov]

One bit of tension with exposing additional enable_foo flags is that we either leak implementation details to the caller (e.g. enable_process requires enable_signal which requires enable_io), or alternatively if we decide enabling one feature automatically enables its dependencies we can find ourselves in a situation where we can't turn off features without a breaking change (e.g. if we ever change process to use pidfd or something and it stops turning on enable_signal it could break someone's application). This is why we originally chose to lump io/signal/process behind enable_io.

My initial recommendation would be to make the PR as conservative as possible, since we can easily add more flags in the future (but can't take any away). For example, maybe we should only add a flag for process since it is the one that performs eager registration...

cc @carllerche if you have any advice for public API additions

[Firstyear]

We could add a flag for only process, but then how would that look as enabling io? I think we can't really change enable_io to mean "just net/io". So having only "enable_io" and "enable_process" doesn't really fix the issue, since I need "io without process". Maybe just "enable_minimal_io" which does only the base io and no signal/no process? And we retain the current enable_io as enabling both signal and process.

I agree that being conservative is the right move, there is a lot that could go wrong I think.

[Darksonn]

Yeah, if anything, I agree with only adding process for now.

[Firstyear]

When you say "adding process" what do you mean? What do you think the enable api calls should be?

[Darksonn]

I meant adding only enable_process, but not enable_signal.

[Firstyear]

I meant adding only enable_process, but not enable_signal.

That won't solve the problem that I have - I need a way to enable_io but without enabling process or signal. So what would an "enable io but without process and without signal" be called?

[Darksonn]

Right. I guess in that case we would need a function like enable_minimal_io I guess.

[Firstyear]

@Darksonn This is a rebase and clean up of the changes for this. I still have enable signal as an exposed feature here, but I can also remove that if wanted.

[Darksonn]

What are your thoughts @ipetkov, @carllerche?

[carllerche]

Commenting in the issue first.

[Darksonn]

Looking over the discussion here and in the issue, I think a better approach would be to ensure that if the process/signal drivers are unused, then they do not register any global state. Luckily, that was already implemented in #3743. Thank you for the PR.