小编The*_*eer的帖子

有人可以解释一下设备控制器的概念（硬盘控制器、NEC PD765 兼容控制器等）。

以下是解释可能需要的一些关键术语的定义。只是为了保持术语同步:)

内核- 为访问硬件设备提供抽象的软件

驱动程序- 由硬件制造商编写的低级程序，作为内核模块加载并为内核提供有关如何控制设备的知识

固件- 定义硬件内部逻辑的硬件特定程序。内核通常与它们无关，除了在每次启动时将固件上传到设备的情况，在这种情况下内核会上传

设备控制器安装在哪里，它是否位于主板上的设备本身？

驱动程序是否为内核提供了与控制器的接口，而不是直接与设备本身的接口？

控制器背后的想法是否能够使用相同的驱动程序控制来自不同制造商的设备？

当定时器中断发生时，ISR 被调用来服务该中断。

是否可以假设每个计时器中断都以调用调度程序结束，下一个进程应该继续运行？

可以概括地说每个中断都必须以调度程序调用结束吗？

的输出 cat /sys/devices/system/clocksource/clocksource0/available_clocksource列出了可用的硬件时钟。

我已经改变了时钟，没有任何明显的区别。 sudo /bin/sh -c 'echo acpi_pm > current_clocksource'

更改硬件时钟的实际含义是什么？有没有办法检查可用时钟的分辨率（或其他一些可见的变化）？

假设我想观察从文件名到硬盘上的簇的流程是如何进行的。

我得到 I 文件的索引节点号（映射到目录数据中）：

1863 autorun.inf

所以，现在我知道我必须寻找编号的索引节点1863，它将包含指向硬盘上数据的指针。

inode 数据位于哪里以及操作系统如何知道在哪里可以找到它？

这是一个可以更好地解释的示例：

我从图片中选择了音频驱动程序，我想浏览它的源代码。我如何从这里到达源文件的路径？

我试图了解 shell 脚本是如何工作的。该教程指出脚本应按以下方式运行：

source oe-init-build-env rpi-build

通常在做这种研究时我会做sh -x oe-init-build-env rpi-build。然而，这种方法在这里不是最佳方法，因为它会在新的 shell 中运行脚本。

有没有办法用源代码运行脚本并将sh标志传递给它？

我正在尝试获取envshell 变量中的输出并打印它。

#!/bin/sh
ENV_BEFORE=$(env)
printf $ENV_BEFORE

结果，env输出中的单个变量被打印出来。

当使用echo代替printf所有输出时，将打印输出，但没有换行符。

我在这里缺少什么？

我正在制作这个测试脚本来帮助我反向工程负责设置开发环境的脚本。

剧本：

#env-changes
#!/bin/bash
TESTED_SCRIPT=$1
shift
ENV_BEFORE=$(env | sort)
. $TESTED_SCRIPT
ENV_AFTER=$(env | sort)
diff <(printf '%s\n' "$ENV_BEFORE") <(printf '%s\n' "$ENV_AFTER")

虚拟环境脚本：

#!/bin/bash
export I_AM_NEW=hello

用法：

$ ./env-changes dummy-env-script.sh 
21a22
> I_AM_NEW=hello

目前它仅适用于bash. 关于如何使其更符合 POSIX 的建议？

我正在探索跟踪特定板的内核 defconfig 发生的更改的方法。我所指的更改要么是通过 menuconfig 选择一个新选项并保留它，要么移动到引入新选项的新内核。

我的想法是在提交更改之前删除注释并对 defconfig 进行排序：

make ARCH=arm board_defconfig
make ARCH=arm menuconfig       # Changes introduced here and saved to .config
make ARCH=arm savedefconfig    # This creates the defconfig file
grep -v '^#' defconfig > tmp
sort tmp > tmp_sorted
uniq tmp_sorted > defconfig
cp savedefconfig arch/arm/configs/board_defconfig

menuconfig但是有一个非常一致的添加注释行的习惯。例如：

# CONFIG_IOMMU_SUPPORT is not set
# CONFIG_RTC_INTF_PROC is not set
# CONFIG_IOMMU_SUPPORT is not set

如果我真的被允许删除它们，这让我有第二个想法。

这些注释行是否有使它们不安全删除的目的？

我正在尝试调试有关 dns 解析的一些问题，并且正在尝试nslookup（现已弃用）和dig.

但是，我在一个systemd用于配置/etc/resolv.conf.

~$ cat /etc/resolv.conf 
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.

nameserver 127.0.0.53

这似乎dig毫无用处，因为它所做的只是指向127.0.0.53我机器上的 systemd 构造的 dns 服务器。

~$ dig www.google.com

; <<>> DiG 9.10.3-P4-Ubuntu <<>> www.google.com
;; global options: …