Re: [MiNT] Kernel modules idea

[Frank Naumann <fnaumann@boerde.de>]

Hello!

> > So, how about this: a kernel module corrupt memory, for example kmalloc 
> > internal data. On the next call of kfree() the kmalloc code see that the 
> > data structures are destroyed - what the can do now except halting the 
> > kernel?
>
> Nothing. But if user have AES and vconsoles (lets imagine we'll have 
> vconsoles in the future) and AES will do wrong kfree() do we have to halt 
> everything?

Yes, It's the best we can do. The kmalloc managed memory contain very 
critical data structures. You can't accept any failure here. If you accept 
failures things will going wrong even more worse.

> > Additionally if a kernel module have such a bad failure you will see this 
> > during development. Such bugs don't live very long. So the chance to 
> > encounter such a bug from which you can recover is very, very small.
>
> I'm sill young (25 actually) but I've never seen an aplication that had all 
> bugs spotted on developemnt/testing stage.

Yes, as I said better spent the time on the real bugs. Not on things you 
eliminate to 99,9% during development.

> What dependencies? Module dependencise? I do nto think we'll have much module 
> dependecies.

Uh, you have any idea about the resource and data flow between main kernel 
and xaaes module? Ok, let's oversee kmalloc'ed memory. You still have proc 
extension attachements, per process attached memory, open resources like 
filedescriptors, timeouts in any variants, running kernel threads, trap 
dispatcher, pending signal callouts and so on. Do you want to track all 
these? With what strategy do you want to free them without knowing how 
they are used?

> > So why add lot of new code (with lot of new bugs) to try to recover from a 
> > situation that most likely don't happen. And even if it happen the new 
> > bugs of the new code will stop you :-)
> >
> > > > 3) such fatal bugs you are able to detect are fixed in a short time
> > > >    (bugs you can detect are maybe wrong API usage or such simple 
> > > > things)
> > >
> > > Better safe the sorry.

Sure, better safe than sorry. That's why there are lot of assert's that 
do a very good job. So the kernel is safe and the kernel will not 
getting safer by the code you add. The kernel just get more bugs. In 
summary you don't improve anything.

And please keep also in mind, better spent time on really useful things 
instead things that are to 99% useless.

> Assert is one way path. No way to recover. That is proper if kenrel really 
> can't continue, but if there is a wey to recover - we shouldn try.

Not if you overcompensate the effect with new bugs and development time 
that you can more effective use for fixing bugs instead.

> > And you want to add lot of new code for a very trickily and sensitive 
> > recovering mechanism that isn't helpful in most cases.
>
> Better safe then sorry ;)

Please read again. For me it's not safer to introduce lot of new code with 
lot of new bugs to eventually recover from a very simple bug in very rare 
cases. Just think in summary: Adding 20 new bugs to eventually recover 
from a very rare bug isn't an improvement at all.

It's so simple, you don't fix a bug nor find new bugs. You only want to 
add code to recover from existing bugs. So in summary you only increase 
the number of bugs. This isn't safer or an improvement.

Btw. do you know the german slang:

Computers solve problems that we didn't have without them.

You try todo something similiar :-)


Regards,
Frank

--
ATARI FALCON 060 // MILAN 060
-----------------------------------------
e-Mail: fnaumann@freemint.de