Try/catch for modules?

Bernd Petrovitsch bernd at petrovitsch.priv.at
Fri Oct 18 12:18:50 EDT 2019


On 18/10/2019 18:11, Martin Galvan wrote:
> El vie., 18 oct. 2019 a las 13:05, Bernd Petrovitsch
> (<bernd at petrovitsch.priv.at>) escribió:
>> You actually want speed in the kernel and not necessarily extra effort
>> for "try" and "catch" which is - sooner or later - never really used.

Just brainstorming (as I'm not a guru on the inner workings): I don't
know if it's possible to hook into the relevant IRQs etc. to catch a
"kernel-space seg-fault" ....

>> And the "safety net" reduces the motivation to actually fix pointer bugs ....
> 
> I don't think I was clear. My intent is that if a pointer bug isn't
> fixed, my module will fail gracefully and go through the catch block

If the module fails "gracefully" other powers may decide that you
should just paper over the bug and make you work on other stuff.
Of course it doesn't inhibit any bug fix per se but ....

> instead of panicking the whole system. I don't see how this would stop

Hmm, depending on the driver/module, one could use UML or
VBox/VMware/... for testing - and the panic shows the exact place
(or at least should;-).
If it's a driver for real hardware, I hope you have a separate system
to test;-)

> me from fixing the bug itself; if anything, it could even help me
> debug it.

MfG,
	Bernd
-- 
"I dislike type abstraction if it has no real reason. And saving
on typing is not a good reason - if your typing speed is the main
issue when you're coding, you're doing something seriously wrong."
    - Linus Torvalds
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 2472 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20191018/fb4f9342/attachment.bin>


More information about the Kernelnewbies mailing list