On Wed, Nov 23, 2011 at 10:09 AM, Alan McKinnon <alan.mckin...@gmail.com> wrote: > Lets grant that the VirtualBox modules are not up to LKML standards. > That's fine, very little out of the tree is. I'm willing to bet that > the majority of the issues are silly bugs involving pointer arithmetic > (the usual cause of these things) and could be fixed up with minimal > effort. > > Either way I don't think a sweeping condemnation of the entire product > is the right way to go.
I read that entire thread back when it was highlighted on /. 1) The vbox driver is buggy. 2) The vbox driver is buggy in ways that cause crashes which are difficult to debug and correctly attribute, which appears to be discerned by statistical means. 3) The vbox driver upstream won't send their code to the kernel where it could be cleaned up and kept in step with the rest of the kernel, because it would restrict them from updating their API in future versions. 4) The vbox driver functions as a wildcard when kernel devs are trying to deal with bug reports in other areas of the code; just like heap and stack corruption in userland apps are a royal PITA to deal with, so are the same in kernelspace. The vbox driver is known to cause these problems, so they don't want to deal with it. Now, it looks like things may be in line to get better; the thread got the attention of the vbox maintainers, and they started working on ways to get flagged bug reports sent their way. That'll improve the feedback they get. The code will probably improve as a result. That said, drivers which cause random memory corruption are *not* ones I want loaded into my kernel. Discussions around things like the vbox kernel give me second thoughts about sweet dreams of mmapping persistent storage block devices contiguously in a large address space; I'd suddenly rather keep the window target small. I've got nothing against proprietary drivers if they're good. I've generally had good luck with both NVidia and ATI, for example. NVidia, especially, has been quick to respond to issues by their user communities > Oh, I forgot something in the first paragraph. In my experience on this > machine we can add Firefox, OpenOffice.org and LibreOffice to the same > list of unstable software. Apples and oranges. FF, OO and LO don't crash the entire system when they go up. Protected memory FTW. Kernelspace stuff must be held to a higher standard; they run in ring 0. (Forgive the x86-specific terminology, but it should be analogous for any protected-memory platform) -- :wq
