标签: linux-kernel

通常对于 arm 系统，设备树向内核 (Linux) 提供硬件信息。这些设备树作为编译并加载到内核的 dts（设备树源）文件存在。问题是我无权访问这样的dts文件，甚至无法访问dtb文件。

我可以访问/sys和/proc在机器上，我想问一下这是否允许我“猜测正确的值”以在 dts 中使用？

如果这个问题的答案还取决于是否首先使用了设备树接口（即 adtb被创建并提供给内核），而不是一些更多的黑客攻击，那么潜在的答案也可以突出另一个方面“我们只是从 vanilla 转移并修补内核以解决我们内核的设备信息问题“-解决方案？

我对用户空间和初始化系统（无论是经典的 init sysV /upstart/systemd）如何在系统关闭时工作有一个粗略的想法。（本质上有“停止！”、“请真正停止”、“过程我需要杀死你才能停止”和等待......事情正在进行中的顺序）。

无论如何，我非常不知道系统关闭在内核中是如何工作的（肯定还有很多事情要做）？

我试图查看内核文档https://www.kernel.org/doc/htmldocs/，甚至使用NSA 的 pal 搜索工具让我先了解它是如何工作的。

我还搜索了 SE U+L 并没有发现任何东西（我是否忽略了它？）

无论如何，这个问题虽然可能有点挑战性，但值得在这个问答网络中得到答案，因为我认为更多的人有兴趣了解关闭时 linux 内核中发生的情况。

可能还有更改以链接到一些更详细的解释。

答案可能包括使用了哪些系统调用和哪些内核信号？

https://github.com/torvalds/linux/blob/b3a3a9c441e2c8f6b6760de9331023a7906a4ac6/arch/x86/kernel/reboot.c 似乎是与重启相关的 x86 使用文件（已经接近关闭，嗯？）

也许在这里找到的片段http://lxr.free-electrons.com/source/kernel/reboot.c#L176 可以用来解释

第176话
177 {
第178话
第179话
第180话
第181话
第182话
183 pr_emerg（“断电\n”）；
184 kmsg_dump(KMSG_DUMP_POWEROFF);
第185话
第186话
第187话

我正在尝试使用 QEMU (kmv) 模拟 EFI 环境；使用 archboot 在 EFI 模式下启动 virtualbox 需要 15 分钟。

使用传统 BIOS 模式，我可以使用以下命令启动：

root@citsnmaiko-deb:/home/maiko/uefi/ovmf# qemu-system-x86_64 -kernel  ../bzImage -initrd ../rootfs.gz -append "rw root=/dev/ram0  ramdisk_size=40960"

它适用于我的自定义内核和文件系统。

file ../bzImage 
../bzImage: Linux kernel x86 boot executable bzImage, version 3.6.1 (root@citsnmaiko-deb) #4 , RO-rootFS, swap_dev 0x3, Normal VGA

它也有 EFI 支持。

我正在尝试对从此处下载的 EFI 文件执行相同操作

wget http://ufpr.dl.sourceforge.net/project/edk2/OVMF/OVMF-X64-r11337-alpha.zip -P ovmf
cd ovmf/
unzip -x OVMF-X64-r11337-alpha.zip
# rename the files for QEMU find them
mv OVMF.fd bios.bin
mv CirrusLogic5446.rom vgabios-cirrus.bin
# start QEMU
root@citsnmaiko-deb:/home/maiko/uefi/ovmf# …

有没有办法知道内核是否是在激活某个选项（即CONFIG_PROC_EVENTS=y）的情况下编译的，而不必拉出内核源代码包并查看配置文件？

我cpupower在 ArchLinux 上挣扎。我想将州长设置为ondemand，甚至设置为conservative。

首先，如果我这样做$ sudo cpupower frequency-info --governors，我只会得到performance powersave.

所以我寻找这样的可用模块

ls -1 /lib/modules/`uname -r`/kernel/drivers/cpufreq/

......我明白了

acpi-cpufreq.ko.gz
amd_freq_sensitivity.ko.gz
cpufreq_conservative.ko.gz
cpufreq_powersave.ko.gz
cpufreq_stats.ko.gz
cpufreq_userspace.ko.gz
p4-clockmod.ko.gz
pcc-cpufreq.ko.gz
powernow-k8.ko.gz
speedstep-lib.ko.gz

因此，首先似乎没有“按需”模块可用。我想念什么？

然后我尝试启用至少保守：

$ sudo modprobe cpufreq_conservative

然后我检查模块是否实际加载

$ lsmod | grep cpufreq

并检查它现在是否可用

$ sudo cpupower frequency-info --governors

但不幸的是，我仍然得到相同的结果：performance powersave只有，并且如果我尝试启用保守的

$ sudo cpupower frequency-set -g conservative

它说该模块不可用。

所以基本上我有两个问题：

1. 我需要安装什么才能拥有按需模块
2. 我怎样才能启用它？

我在笔记本电脑的屏幕亮度控制上遇到了问题，我通过将acpi_osi=linux和acpi_backlight=vendor参数添加到文件中来修复它grub.cfg。我想知道这些参数是什么意思以及它们为什么起作用。

经典情况：我跑得不好rm，之后立即意识到我删除了错误的文件。（没什么重要的，我最近的备份还算可以，但还是很烦人。）

知道如果我想使用extundelete或此类工具恢复文件，进一步的磁盘活动是我的敌人，我立即关闭了机器的物理电源（即，使用电源按钮，而不是使用halt或任何此类命令）。这是一台没有运行重要任务或任何打开的笔记本电脑，所以这是一个可以接受的操作。（顺便说一下，从那时起我了解到在这种情况下要做的第一件事是首先估计丢失的文件是否仍然可以被进程打开https://unix.stackexchange.com/a/101247 --如果是，您应该通过这种方式恢复它们，而不是关闭机器。）

尽管如此，一旦机器断电，我想了一会儿，并认为这些文件不值得花时间启动实时系统进行适当的取证。所以我重新启动了机器。然后我发现我的文件仍然位于磁盘上：rm在我关闭电源之前还没有传播到磁盘。我跳了一小段舞，感谢系统管理员之神出人意料的宽恕。

我现在的问题是要了解这是如何可能的，以及rm实际传播到磁盘之前的典型延迟是多少。我知道磁盘 IO 不会立即刷新，而是在内存中停留了一段时间，但我认为磁盘日志会很快确保挂起的操作不会完全丢失。https://unix.stackexchange.com/a/78766似乎暗示了一种单独的机制来刷新脏页和刷新日志操作，但没有提供足够的细节来说明日志将如何参与 arm以及之前的预期延迟操作被刷新。

更多细节：数据位于 LUKS 卷内的 ext4 分区中，在启动机器备份时，我看到以下内容syslog：

Sep 24 10:24:58 gamma kernel: [   11.457007] EXT4-fs (dm-0): 1 orphan inode deleted
Sep 24 10:24:58 gamma kernel: [   11.458393] EXT4-fs (dm-0): recovery complete
Sep 24 10:24:58 gamma kernel: [   11.482475] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)

但我不相信它与rm.

另一个问题是是否有办法告诉内核不要执行任何挂起的磁盘操作（而是将它们转储到某处），而不是关闭机器电源。（当然，不执行挂起的操作听起来很危险，但这就是在关闭机器电源时会发生的情况，并且在某些情况下它可以拯救您。）当然，这将是“更干净”，也很有趣例如，对于物理断电不是一个简单选择的远程服务器。

我目前正在尝试遵循Hardening Debian for the Desktop Using Grsecurity指南，以便在我的 Kali Linux 桌面上安装带有 Grsecurity 的 4.5.7 内核。

我正在逐字跟踪该指令列表，除了我尝试将 Grsecurity 的测试补丁用于 4.5.7 内核并且我正在运行 Kali Linux 而不是直接的 Debian。

但是，每次我尝试编译内核时，都会在“CC certs/system_keyring.o”行之后收到此错误：

  CC      certs/system_keyring.o
make[2]: *** No rule to make target 'debian/certs/benh@debian.org.cert.pem', needed by 'certs/x509_certificate_list'.  Stop.
Makefile:951: recipe for target 'certs' failed
make[1]: *** [certs] Error 2
make[1]: Leaving directory '/home/jc/Downloads/linux-4.5.7'
debian/ruleset/targets/common.mk:295: recipe for target 'debian/stamp/build/kernel' failed
make: *** [debian/stamp/build/kernel] Error 2

正如我发现的那样，对于任何内核，即使我没有应用补丁或修改，我也会收到此错误，因此它与我用来编译内核的工具（显然是某种系统钥匙串）有关。有人可以告诉我如何修复我的操作系统并编译我的内核吗？

PS这是输出cat /proc/version：

Linux version 4.6.0-kali1-amd64 (devel@kali.org) (gcc version …

我注意到内核中有以下选项：CONFIG_DEVTMPFS

Device Drivers -> Generic Driver Options -> Maintain devtmpfs to mount at /dev

我看到它在 Debian 发行版内核中默认启用 3.2.0-4-amd64

我试图了解这个选项带来了什么不同。如果没有此选项，/dev则挂载为tmpfs，使用此选项，则挂载为devtmpfs。除此之外，我看不出有什么不同。

在help没有明确对我来说之一：

这会在启动初期创建一个 tmpfs/ramfs 文件系统实例。在此文件系统中，内核驱动程序核心维护设备节点及其默认名称和所有注册设备的权限，这些设备具有分配的主要/次要编号。

它提供了一个功能齐全的 /dev 目录，通常 udev 在上面运行，管理权限并添加有意义的符号链接。

在非常有限的环境中，它可能会在没有任何进一步帮助的情况下提供足够功能的 /dev。它还允许简单的救援系统，并可靠地处理动态的主要/次要号码。

有人可以解释使用CONFIG_DEVTMPFS与标准之间的区别/dev吗？

至少这对我来说并不新鲜，SATA 实际上“谈论”SCSI，因此为什么这些 SATA 设备在 Linux 中显示为 SCSI 设备。

之前有人问过一个相关的问题，例如为什么我的 SATA 设备会出现在 /proc/scsi/scsi 下？

然而，在我之前讨论过的地方没有提到的是 SATA 与 SCSI 的关系，以及它们的不同之处。

我认为它们在物理层上有所不同是理所当然的，因为它们不共享兼容的电缆。

但是，堆栈的更高位置呢？我知道 Linux 如何将现代内核上的 SATA 甚至 IDE 磁盘表示为 SCSI 到 SCSI 子系统。但是总线上使用的实际协议呢？

我也知道 ATAPI 是对 SCSI 的封装，但是常规的 ATA 呢？我注意到 SCSI 的一些特性，例如 NCQ、FUA、DPO 等（如果我没记错的话）已经从 SCSI 中采用了。但不清楚有多少 SCSI 命令集实际上是共享或相似的。

具有 ATA 规范的现代 SATA 设备是否实现了 SCSI 命令集的子集，但进行了封装（如在 ATAPI 中）？同一套？超集？或者可能只有选定的功能作为不完全相同的变体来实现？

我在哪里可以找到关于此的一些明确信息，尤其是它与 Linux 内核的关系？驱动程序开发的某种教程会很好，但即使只是一个没有完全跳过所有细节的概述也足够了。我知道我只能阅读实际的规范，但这又太详细了，很难找到你真正想要的东西，而且对我和大多数其他用户来说，在时间意义上是不现实的。