| |||||||||||||
The embedded Linux nightmare - an epilogueThe embedded Linux nightmare - an epiloguePosted May 3, 2007 6:44 UTC (Thu) by drag (subscriber, #31333)In reply to: The embedded Linux nightmare - an epilogue by roelofs Parent article: The embedded Linux nightmare - an epilogue
How much of what you described above can be blamed on just stumbling along new bugs by introducing new software versions versus maybe just not having the ability to quickly diagnose bugs in the first place?
Say if this project described on the following article is successfull?:
So if that makes it much easier to dectect and isolate bugs (say make it more obvious were in the hardware->application toolchain the bug is occuring) would it have a positive affect on embedded developers to be able to track closer to mainline kernel?
Could it it be that lack of good debugging tools for Linux is going to hold people back from using newer Linux versions?
Or is it that what you have now is good enough for embedded developers and such things probably aren't going to make anybody's job any easier?
(Log in to post comments)
The embedded Linux nightmare - an epilogue Posted May 4, 2007 3:50 UTC (Fri) by roelofs (guest, #2599) [Link] How much of what you described above can be blamed on just stumbling along [upon?] new bugs by introducing new software versions versus maybe just not having the ability to quickly diagnose bugs in the first place?Well, it was certainly true that, given the size of the problem space, we were more than a bit understaffed. And the Chronicle debugger (thanks for the link, btw--I hadn't gotten to this week's Development page yet), had it existed back then, probably would have helped, at least if we could have run it from the host system. But insofar as it runs on top of Valgrind, it appears to be limited to apps and libraries, and the really hard, time-consuming bugs were the ones in the kernel and hardware. Could it it be that lack of good debugging tools for Linux is going to hold people back from using newer Linux versions? Or is it that what you have now is good enough for embedded developers and such things probably aren't going to make anybody's job any easier? I'm no longer doing embedded work (quite the opposite, in fact!), but I don't know anyone who would claim the existing tools are "good enough." That is, they're sufficient to get most things done, but it's clear they could be much, much better. In fact, most reasonably unbiased developers with whom I've spoken seem to agree that development tools are one of the principal areas where Microsoft still holds a significant lead over the FLOSS community, and I fully believe them. After all, MS has been working on their toolchain and using it to woo developers (their own approach to World Domination) for a quarter-century, and even when they were spread the thinnest, they supported only three or four CPU architectures--and that for only a few years. GCC and gdb are truly marvels of portability, and it's really nice not to have to learn a new set of commands on every platform, but that very portability has been a huge drag on the pace of development, both in optimization and in debugging (and, no doubt, other areas). That said, I continue to use GCC and gdb every day, both at work and at home. And as much as I love to eke the last little bit of performance out of my code, I'm far more excited about the possibility of major strides on the debugging end of things--especially for massively multithreaded applications. The sooner, the better... Greg
|
|||||||||||||