Date:Sat, 8 Feb 2020 16:47:42 +0100
From:Kamil Rytarowski
Message-ID:
| We are allowed to fix this in the kernel for everybody:
Indeed we are. And if you want to change things that way, that's fine.
It turns out this one wasn't the actual problem in this
> Date: Sat, 8 Feb 2020 06:19:43 -0800 (PST)
> From: Paul Goyette
>
> If this is a device on which you can use ioctl() to configure, why is
> it not stored under sys/dev and why is it not included in kernel config
> with pseudo-device directive (and corresponding files.kern changes)?
There's no
On 06.02.2020 20:51, Robert Elz wrote:
> Module Name: src
> Committed By: kre
> Date: Thu Feb 6 19:51:59 UTC 2020
>
> Modified Files:
> src/bin/sh: main.c
>
> Log Message:
> If we are invoked with SIGCHLD ignored, we fail badly, as we assume
> that we can always wait(2) for our
On Sat, 8 Feb 2020, Martin Husemann wrote:
On Sat, Feb 08, 2020 at 06:19:43AM -0800, Paul Goyette wrote:
The module should be MODULE_CLASS_DRIVER. And there should be a
sys/module/fault/Makefile to build the module, along with changes to
sys/module/Makefile (to descend into the fault
On Sat, Feb 08, 2020 at 06:19:43AM -0800, Paul Goyette wrote:
> The module should be MODULE_CLASS_DRIVER. And there should be a
> sys/module/fault/Makefile to build the module, along with changes to
> sys/module/Makefile (to descend into the fault directory) and to
>
If this is a device on which you can use ioctl() to configure, why is
it not stored under sys/dev and why is it not included in kernel config
with pseudo-device directive (and corresponding files.kern changes)?
The module should be MODULE_CLASS_DRIVER. And there should be a
[I am not subscribed to this list, so if you want to answer, make sure to CC me]
In order to explore error branches, and to test the kernel's ability to cope
with failures, it is often necessary to hard-trigger such failures.
Here is an implementation [1] for fault(4), a driver that allows to
