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