我的任务是在嵌入式设备上将 Linux 作为操作系统运行。
目标具有 x86 处理器和 8 GB CompactFlash 设备用于存储。
我已经设法使用 buildroot 创建内核映像和交叉编译工具。我已将 CF 设备分区为一个小的 FAT 分区，其中包含内核映像以及syslinux引导配置和一个ext3文件系统，我已将 buildroot 生成的根文件系统解压缩到其中。
syslinux通过将根目录设置为我的 buildroot 文件系统所在的 CF ext3 分区，系统启动成功。
我的问题集中在面对立即（和频繁）断电时对稳健性的需求，因为断电后设备成功启动至关重要。我读过将根文件系统挂载为只读是确保数据完整性的一种方式。这是我继续的明智方式吗？
我还阅读了有关将根文件系统加载到 RAM 中以实现相同目的的可能性，但目前还不知道如何执行此操作。
是否有实现这一目标的首选方法，如果有，我继续前进的最佳方法是什么？
我有一个嵌入式设置，使用 initramfs 作为根文件系统，但使用安装在紧凑型闪存 IDE 驱动器上的自定义 ext3 分区。因为面对断电时的数据完整性是整个设置中最重要的因素，所以我使用了以下选项进行挂载（以下是我的/etc/fstab文件中的条目
<file system> <mount pt> <type> <options> <dump><pass>
/dev/sda2 /data ext3 auto,exec,relatime,sync,barrier=1 0 2
我通过在互联网上阅读这些选项获得了这些选项。我担心的是，/proc/mounts给出以下内容：
/dev/sda2 /data ext3 rw,sync,relatime,errors=continue,user_xattr,acl,
barrier=1,data=writeback 0 0
我从阅读中了解到，我想data=journal为我的挂载使用选项，因为这提供了最好的数据损坏保护。但是，从特定 ext3 选项的手册页中，mount它对写回选项进行了以下说明：
不保留数据排序 - 数据可能会在其元数据提交到日志后写入主文件系统。
据传这是最高吞吐量的选择。它保证内部文件系统的完整性，但是它可以允许旧数据在崩溃和日志恢复后出现在文件中。
我对此感到非常困惑 - 手册页似乎表明为了文件系统完整性，我想指定data=writeback选项，mount但我发现的大多数其他参考文献（包括一些关于嵌入式 linux 的已出版书籍）建议我应该使用data=journal. 我使用的最佳方法是什么？写入速度根本不是问题——数据完整性才是问题。
我运行一个小的uClibc和busybox一个x86设备上基于嵌入式系统。我正在使用 initramfs，但我还在ext3IDE 模式下的紧凑型闪存设备上安装了一个自定义目录，我用它来存储由自定义编写的 C++ 应用程序创建的持久测量日志记录数据。我选择了ext3文件系统，因为在我读过的几本书（Karim Yaghmour 的《构建嵌入式 Linux 系统》和Christopher Hallinan 的《嵌入式 Linux 入门》）中，在 IDE 模式下使用 CF 驱动器时，建议使用它来防止断电。这一点尤为重要，数据至关重要。
但是，由于我之前的问题混淆了如果在文件写入过程中发生断电，如何恢复损坏的 ext3 文件中的一些评论，看来实际上该文件系统并没有提供针对因电源造成的数据损坏的安全保证损失。所以我想知道是否
ext3实际上是这个设置的最佳选择？initramfs.cpio文件是否也有损坏的风险？我已经看到并阅读了这个相关问题的答案：日志文件系统是否保证在断电后不会损坏？，但它并没有完全涵盖一些让我感到困惑的事情。
我意识到我问了很多问题，但似乎尽管阅读了很多材料，但我从根本上无法理解断电时我的数据所面临的风险。
在工作中，我们有一些由 DOS 软件控制的嵌入式设备。我的任务是评估 Linux 作为下一代硬件上 DOS 的替代操作系统的使用。我的研究使我得出结论，DOS 只是一种完全不同类型的操作系统，如果您愿意，它可以让您做有潜在危险的事情。根据我的理解，如果您希望直接访问硬件，则必须编写自定义驱动程序。为了满足老板的好奇心，我需要知道以下几点：是否有可能直接从用户空间访问硬件？
我的猜测是否定的，但我想请教那些比我知识渊博的人的意见。
我得到了供应商提供的最小 linux 安装。从对上一个问题的回答中，我发现可以在有或没有模块支持的情况下构建内核。我有一个需要附加的 CANBUS 设备，它带有 .ko 文件形式的驱动程序。我希望能够使用提供的安装脚本安装这些，但首先我需要知道我的内核是否使用模块支持构建 - 我是否可以从命令行检测到这一点？
当我运行lsmod它时，它什么都不返回，所以我知道目前没有 .ko 文件 - 但这是否意味着内核不允许我安装 .ko 文件？
为了回答我的进程被杀死但我无法理解内核通知，我被指出了一些关于 Linux 上安全注意密钥 (SAK) 的文档。我有一个使用 buildroot 生成的嵌入式系统，它使用busybox了 busybox init 系统。我无法找到rc.local或rc.sysinit在我的系统上的任何地方。我在网上查看过，但找不到任何文档（除了上面的链接），可以告诉我如何确定我的系统的 SAK 是什么。谁能告诉我如何获取这些信息以及是否可以关闭 SAK？由于我的系统是嵌入式的并且与互联网隔离，因此我并不太担心安全漏洞或黑客攻击。SAK 似乎突然弹出并杀死了我的主要嵌入式应用程序，这是完全不可接受的，因此如果我可以将其关闭，它将更好地满足我的需求（即使这意味着我必须重新配置和构建我的内核）
我有一个使用 buildroot 和 initramfs 构建的嵌入式系统设置。它在紧凑型闪存设备上运行，我在其中创建了单独的 ext3 分区来安装/etc/和/var目录以及自定义目录来存储数据。我不完全确定这是否是一个好主意，但我需要访问系统日志输出，并且还需要能够修改文件，/etc因为它们需要在此处配置静态 IP 地址。一旦该/etc/network/interfaces文件已被修改，设置IP，我在没有进一步需要手动编辑任何东西/etc，所以我在想，如果让这个以只读方式挂载当设备在现场是一个好主意，或者是否有可能是我系统上的其他应用程序需要写入任何文件/etc? 我运行的是一个相当小的系统，实际上只有 dropbear 和 busybox 正在运行（以及我控制设备的自定义控制器应用程序）。我在各种论坛和网站上环顾四周，这个想法似乎并没有太大争议，但我的知识相当有限。我意识到我可以尝试将它安装为只读，但似乎事情可能会悄无声息地崩溃，所以这是一个坏主意吗？？
我有一个在嵌入式 x86 设置上运行的自定义应用程序（使用 buildroot 和 uClibc 构建）。该应用程序一直运行良好，但今天早上当我返回工作时，我发现我的进程已被终止，并且我的终端上出现以下输出
SAK: killed process 1008 (CX_SC3): fd#4 opened to the tty
SAK: killed process 1009 (CX_SC3): fd#4 opened to the tty
SAK: killed process 1011 (CX_SC3): fd#4 opened to the tty
SAK: killed process 1012 (CX_SC3): fd#4 opened to the tty
现在CX_SC3是我的进程 - 它有多个线程，其中一个打开/dev/ttyS0以通过无线电调制解调器发送消息。串口的 fd 编号为 4。我不明白的是
opened to the tty部分是什么意思？根据一些研究，这表明这与发送到我用来启动程序的 tty 的中断字符有关。哪些事件可能导致以下输出？我的嵌入式设置非常小，使用busybox和运行vsftpd …
我最近一直在使用一些用于嵌入式设置的交叉工具来创建内核模块。
将来能够识别这些模块所针对的内核版本对我很有帮助。我在网上找不到关于这方面的信息，所以我开始认为这可能是不可能的。
所以我的问题是是否有任何命令行实用程序可以确定编译 *.ko 文件所针对的内核版本标头？
我正在尝试开发一个在嵌入式 linux 安装上运行的应用程序。它带有比我的开发机器上的旧版本的 libc。如果我要在我的开发机器上创建一个 chroot 环境，从我的嵌入式设备复制库，使 chroot 环境镜像设备，然后构建应用程序，在设备上运行是否安全？我的开发机器和设备都是 x86 32 位，所以我认为我不需要交叉编译。
此外，我编写的应用程序是否需要链接到其他库（设备上不存在的库），我是否可以安全地在 chroot 中的开发机器上构建这些库，然后将它们复制到设备以进行应用程序部署？
从我对这个主题所做的所有阅读来看，似乎我可以确保所有内容正确链接在一起的唯一方法是在设备上实际构建应用程序，但这不是一个选项，因为它是最小安装并且没有自带gcc安装。