TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Why Does My eBPF Program Work on One Kernel but Fail on Another?

108 点作者 musha68k21 天前

6 条评论

musicale20 天前
Contempt for stable kernel data structures and APIs (and forget about any sort of kernel ABI) might make things easier for certain kernel developers, but it offloads a constant maintenance burden onto many other people, such as eBPF, driver, and kernel extension developers.<p>This sort of asymmetry is why system modules, and platforms in general, should absorb pain in order to benefit their many clients, rather than doing the opposite.<p>Could be worse though - some platforms (cough, iOS) are happy to break <i>user</i> apps every year and offload a constant maintenance burden onto many thousands of app developers, when a more stable ABI would save developers (and users) billions of dollars in aggregate.
评论 #43772704 未加载
评论 #43780699 未加载
评论 #43779872 未加载
kazinator20 天前
&quot;struct tcphdr&quot; follows the wire format dictated by the TCP protocol. It positively has not changed between 5.3 and 5.4, and cannot. It would make no sense, since it would violate RFCs and fail to interoperate.<p><a href="https:&#x2F;&#x2F;elixir.bootlin.com&#x2F;linux&#x2F;v5.3&#x2F;source&#x2F;include&#x2F;uapi&#x2F;linux&#x2F;tcp.h#L25" rel="nofollow">https:&#x2F;&#x2F;elixir.bootlin.com&#x2F;linux&#x2F;v5.3&#x2F;source&#x2F;include&#x2F;uapi&#x2F;li...</a><p><a href="https:&#x2F;&#x2F;elixir.bootlin.com&#x2F;linux&#x2F;v5.4&#x2F;source&#x2F;include&#x2F;uapi&#x2F;linux&#x2F;tcp.h#L25" rel="nofollow">https:&#x2F;&#x2F;elixir.bootlin.com&#x2F;linux&#x2F;v5.4&#x2F;source&#x2F;include&#x2F;uapi&#x2F;li...</a>
linuxftw21 天前
This is all covered in the eBPF documentation. CORE was introduced over 6 years ago.
评论 #43772009 未加载
Upvoter3321 天前
There&#x27;s some research on this topic, e.g., <a href="https:&#x2F;&#x2F;depsurf.github.io" rel="nofollow">https:&#x2F;&#x2F;depsurf.github.io</a>
jeffrallen21 天前
Feels like yet another example of &quot;essential complexity driven by too much churn in infrastructural code&quot;.<p>I wonder why no one needs to write this article about dtrace probes? Is it because they are less used? Less capable? More stable? Better engineered?<p>Probably all of the above, alas.
评论 #43771115 未加载
评论 #43776186 未加载
jstrong20 天前
wow that sounds like a PITA to deal with