On 7/25/21 6:15 PM, Valdis Klētnieks wrote:
The *proper* thing to do is, instead of deciding to return -EHIT_A_BUG, do a
WARN(), or BUG(), so that the dmesg has something that's at least potentially
useful. Then use that information to fix the issue.
The question is, after the WARN_ON, what co
Pls see if this helps
https://linux-kernel-labs.github.io/refs/heads/master/labs/memory_mapping.html
-Raghu
On Sun, Jul 25, 2021, 10:16 PM wrote:
> Hi, all,
>
>
>
> I’m testing a simple character driver on qemu arm64 virtual machine.
>
> I have uint64_t args[32] array and I pass args to the io
Hi, all,
I'm testing a simple character driver on qemu arm64 virtual machine.
I have uint64_t args[32] array and I pass args to the ioctl data.
By the way args[2] contains the address of test_val which is set to 77. I
want to change this value to 78 in the driver using kernel virtual address
On Sun, 25 Jul 2021 13:07:21 -0500, Ian Pilcher said:
> Is there any sort of convention around what to return in the case of an
> error in the logic of the code itself, something that will make it as
> obvious as possible that the problem is a bug.
In general, there's no good way to signal such i
Hi all!
On 25/07/2021 20:07, Ian Pilcher wrote:
[...]
> For kernel code, I can use pr_err, dump_stack, WARN_ON, etc. to report
> the issue in the log, but I often also need to return some sort of error
> code (negative errno value).
This value goes up to userspace (otherwise it makes no real sens
On 7/25/21 1:59 PM, Bernd Petrovitsch wrote:
This value goes up to userspace (otherwise it makes no real sense to use
errno-values).
Yes. I know that.
That depends on the situation/sys-call/
You habe to choose the value (the list and short explanation is in `man
errno`) which leads the u
In user space, I use assertions to check (and document) the assumptions
built in to my code - this value won't ever be negative, this int will
only ever by one of these 3 values, etc.
For kernel code, I can use pr_err, dump_stack, WARN_ON, etc. to report
the issue in the log, but I often also nee
