Re: Kernel stability relation to HW-specific code?
> Hello,
>
> slightly OT, maybe... (specific to kernel, not Debian).
>
> On Wed, 13 Mar 2013 13:03:24 -0300
> "Joao Luis Meloni Assirati" <assirati@nonada.if.usp.br> wrote:
>> Squeeze is now more than 2 years old and in this period I
>> installed and administered dozens of debian computers. I had
>> the oportunity to see lots of crashes not caused by hardware
>> failure, almost all of them related to video or wifi drivers,
>> i.e. still related to hardware. I don't recall to find any
>> "purely algorithmic" kernel crash or panic in the last few
>> years.
>
> Just curious: How would one draw a line between error "related
> to hardware" and "purely algorithmic"?
By kernel logs or experimentation and reproduction. The Linux
"algorithmic" errors usually leave nice error messages before the system
freeze (BUG_ON etc).
> I'm no kernel expert, but as I understand it, it's basically a
> layer between applications and hardware. From that point of
> view, error in kernel not related to hardware seems to me as a
> rare (if not impossible) thing...
No, the kernel has very complex algorithms to deal with process and memory
management, filesystems, networking etc. Run -rc1 kernels and you will
eventually find bugs in such subsystems. The kernel sure is a layer as you
said, but it is also an abstraction layer so that you don't have to
implement basic and common features.
> I don't mean to bicker, I'm just wondering if it would make any
> sense to divide kernel code that is more closely related to
> hardware (like drivers) and more generic code, in attempt to
> measure stability of these parts separately.
There are the so called microkernels that work this way. Linux is not a
microkernel (it is a monolithic kernel). This is a very long discussion
that periodically comes back (see Linus - Tanenbaum debate if you really
want learn about it).
João Luis.
Reply to: