3 ms·

> he has conflated single-step in situ debugging (which does in fact suffer from limited utility in the context of an OS kernel) with debugging writ large. Whe

> he has conflated single-step in situ debugging (which does in fact suffer from limited utility in the context of an OS kernel) with debugging writ large. Where does he do this? The quote is only about single-step debugging. > So as he rejected in situ debugging, he also implicitly rejected postmortem debugging and dynamic instrumentation Do you have any evidence of this? It seems to me that dump traces and kernel probes have been an important part of Linux for many years.

AstralStorm 9y ago
Not to mention relocatable kernel and kexec crash dump analysis.
bcantrill 9y ago
No, the quote is not only about single-step debugging; his next sentence is: "I do not think that extra visibility into the system is necessarily a good thing." And if that still leaves too much ambiguity for you as to his thinking, read the rest of the screed -- and then remember how we got here: because it took someone two painful days to configure something that is considered core functionality on many other systems.
- richardwhiuk 9y ago
  It's a lot easier to configure using the modern API - the author is intentionally choosing an API which doesn't give much feedback....
  - xenophonf 9y ago
    That's true, but the author has solid reasons for doing so: > I want my application to work on OS X and Linux, so I’m targeting PF_KEYv2 instead of OS-specific APIs.
    - makomk 9y ago
      If the reason he's using a horribly unfriendly and difficult to debug API is because it's cross-platform and the more developer-friendly replacement is Linux only, then the fact that the API is so hostile certainly isn't proof - as bcantrill was claiming - that Linux is somehow going out of its way to be hostile to developers compared to competing OSes.
      - alambert 9y ago
        PF_KEYv2's difficult interface definitely isn't a Linux issue. But PF_KEYv2's limited error reporting means that understanding what's going wrong requires kernel debugging. The difficulty of kernel debugging is a Linux issue. ("I do not condone single-stepping through code to find the bug.") [1] https://news.ycombinator.com/item?id=15953644 https://news.ycombinator.com/item?id=15953644

AstralStorm 9y ago

Not to mention relocatable kernel and kexec crash dump analysis.

bcantrill 9y ago

No, the quote is not only about single-step debugging; his next sentence is: "I do not think that extra visibility into the system is necessarily a good thing." And if that still leaves too much ambiguity for you as to his thinking, read the rest of the screed -- and then remember how we got here: because it took someone two painful days to configure something that is considered core functionality on many other systems.

richardwhiuk 9y ago
It's a lot easier to configure using the modern API - the author is intentionally choosing an API which doesn't give much feedback....
- xenophonf 9y ago
  That's true, but the author has solid reasons for doing so: > I want my application to work on OS X and Linux, so I’m targeting PF_KEYv2 instead of OS-specific APIs.
  - makomk 9y ago
    If the reason he's using a horribly unfriendly and difficult to debug API is because it's cross-platform and the more developer-friendly replacement is Linux only, then the fact that the API is so hostile certainly isn't proof - as bcantrill was claiming - that Linux is somehow going out of its way to be hostile to developers compared to competing OSes.
    - alambert 9y ago
      PF_KEYv2's difficult interface definitely isn't a Linux issue. But PF_KEYv2's limited error reporting means that understanding what's going wrong requires kernel debugging. The difficulty of kernel debugging is a Linux issue. ("I do not condone single-stepping through code to find the bug.") [1] https://news.ycombinator.com/item?id=15953644 https://news.ycombinator.com/item?id=15953644