> Hello, > > slightly OT, maybe... (specific to kernel, not Debian). > > On Wed, 13 Mar 2013 13:03:24 -0300 > "Joao Luis Meloni Assirati" <assir...@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. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/483611a14e6ca307f5f9503659304520.squir...@nonada.if.usp.br
