首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

linux中backport printk和front printk的区别

在Linux内核中,"backport printk"和"front printk"都是用于记录内核消息和调试信息的机制,但它们的工作方式和使用场景有一些区别。..."backport printk"是一种在内核中记录消息和调试信息的机制,可以将这些信息输出到控制台、串口、网络等目标。它通常用于在内核启动过程中的早期阶段,或者在没有其他可用的调试机制时使用。"...backport printk"不依赖于其他内核模块或机制,因此可以在不同的环境中使用。 相比之下,"front printk"是一种将打印消息转发到用户空间的机制。...总结来说,"backport printk"主要用于早期的内核启动阶段和没有其他调试机制的情况下,而"front printk"主要用于记录内核崩溃和错误时的信息,并将其转发到pstore机制中。

13340
您找到你想要的搜索结果了吗?
是的
没有找到

如何优雅地编译kernel

redhat会选择一个内核版本构建自己的发行版,发行版除了内核还包括众多内核之上的软件如bash/gcc/glibc/systemd/开发库等等,redhat的策略是长期维护,只backport和bugfix...升级小版本,并且保证任何backport和bugfix不影响原来的使用场景,比如升级内核小版本原来自己开发的内核模块代码不用修改,但在主线linux内核升级估计就得修改代码,再比如原来生产环境有一些脚本和配置文件...3.10.0,但是云计算用到了众多linux内核组件如kvm/bcache/bonding/openvswitch/virtio/mdev/ebpf,很多功能在centos 7内核中没有,内核差异巨大很难backport...回来,并且centos 7源中qemu/libvirt版本过低,要用的很多功能也没有,不得不升级到centos 8,centos 8自带内核4.18.0,并且redhat backport了大量功能。...虽然维护时间长点但并不会有大的作为了,基本就是小bugfix,不能满足我们对新功能的需求,所以我们只能选择centos 8,搭乘redhat的免费末班车到终点站,后面的路只能自力更生,像redhat那样自己backport

99500

如何优雅地编译kernel

redhat会选择一个内核版本构建自己的发行版,发行版除了内核还包括众多内核之上的软件如bash/gcc/glibc/systemd/开发库等等,redhat的策略是长期维护,只backport和bugfix...升级小版本,并且保证任何backport和bugfix不影响原来的使用场景,比如升级内核小版本原来自己开发的内核模块代码不用修改,但在主线linux内核升级估计就得修改代码,再比如原来生产环境有一些脚本和配置文件...3.10.0,但是云计算用到了众多linux内核组件如kvm/bcache/bonding/openvswitch/virtio/mdev/ebpf,很多功能在centos 7内核中没有,内核差异巨大很难backport...回来,并且centos 7源中qemu/libvirt版本过低,要用的很多功能也没有,不得不升级到centos 8,centos 8自带内核4.18.0,并且redhat backport了大量功能。...虽然维护时间长点但并不会有大的作为了,基本就是小bugfix,不能满足我们对新功能的需求,所以我们只能选择centos 8,搭乘redhat的免费末班车到终点站,后面的路只能自力更生,像redhat那样自己backport

1.2K10

Linux 开发过程那么麻烦,是否值得?

Backport:鉴于其规模和重要性,分支一直是 Linux 的常态。即使是现在(2020 年),一些发行版也可能是在它们视为 LTS 的版本上加上自己的补丁。...许多现代线上公司不需要保持产品线的兼容性,通常不存在 Backport 的问题。他们只关心交付即可。但是如果涉及到 Backport,事情就变得比较复杂了。...若要将风险降至最低,可以只 Backport 大变更的某些部分,大家通常都这么做。假设,一个 2,000 行的代码变更中有 5 行修复了一个 bug。...你是愿意基于一个大变更来做 Backport 呢,还是愿意基于一个文档非常完善、描述得很充分、做过合理拆分的补丁来做 Backport 呢?...作为一个做过无数次 Backport 的人,我很清楚我的选择是什么。 Backport 还是不 Backport 呢,它有好处,但也伴随着阶梯式的成本。

41340

红帽:我们为什么要改变RHEL源码的发布策略?

当我们讨论发行版的上游和下游时,有一些专业术语需要解释,如"Backport"(反向移植) 和"Test"。在这里,"Backport"是一个特殊的术语,意思是将上游的某些补丁反向移植到下游的版本中。...如果没有发行版厂商去做 backport,实际上没有人会做这个工作。...所以在支持年限以及 backport 的力度上,发行版厂商具有明显优势。 关于上游社区,比如 Linux 接收到一个新的补丁,我会将其加入 backport。...再举例说明,当你需要在一个版本差距很大的旧版本上进行 backport 时,由于许多结构体都已经发生变化,保证 backport 的正确性会变得非常困难。...如果你没有"upstream first",那么也就不存在"backport"。

30710
领券