据我所知，实时进程意味着进程会在需要时立即获得 CPU。内核通过其内部调度机制负责此任务。
另一方面，进程亲和性意味着进程将获得一个专用的 CPU，并且不会由内核调度程序管理。所以，如果我理解正确的话，它甚至比实时进程更好。这就像为 Arduino 编程，但只是使用更快的 CPU。此外，据我了解，对于进程亲和性，我们至少需要一个双核 CPU，并且我们必须为操作系统本身留出至少一个 CPU。因此，借助进程亲和性，为 Arduino 编写的程序可以移植到 Linux 主板（如 Raspberry Pi Zero 2 W，它具有四核 CPU），并且可以享受微控制器的所有优势，但 CPU 更快。
我的理解正确吗？
我正在尝试破解Linux内核并添加/修改了一些头文件include/linux。但是，当我使用以下命令生成补丁文件时diff：
diff -uprN -X linux/Documentation/dontdiff \
linux-5.15 linux-srctree > patch.p1
我发现更改include/linux未包含在内patch.p1。然后我查看dontdiff文件并找到以下几行（大约 158 行），这意味着它include/linux从补丁文件中排除。
*lex.*.c
linux
logo_*.c
那么为什么要dontdiff包含linux？如何保存对补丁文件中标题的更改include/linux？非常感谢。
我正在调查将两个依赖于同一共享对象的进程容器化对内存的影响。我的主要问题是共享对象是否会在内存中加载两次。
这个问题之前已经有人问过了，但是答案并不完整，而且与我的实验相矛盾。我将引用我已经遇到的情况：
共享库的加载和 RAM 的使用--> 对 .so 使用 -fPIC
docker 容器是否共享从同一层但不同映像映射的文件内存的 RAM？ --> 是的，但取决于您的设置。您可以通过检查已加载共享对象的设备和 inode id 来证明这一点。没有指示要使用什么设置。
https://stackoverflow.com/questions/35863608/shared-library-in-containers --> 是的，取决于您的存储驱动程序。aufs、overlay 或 overlay2 存储驱动程序支持此功能。
https://stackoverflow.com/questions/63145223/about-loading-dynamic-library-in-container --> 每个容器都是自己的执行单元。不发生共享。与前文相矛盾。
我使用了以下设置：
存储驱动程序：Overlay
下面您可以看到来自 grep glib /proc/PID/maps 的信息。PID 是容器内可执行文件的进程。
| /proc/17/maps:7efd3b630000-7efd41980000 | r-xp | 00000000 | 00:a2 | 16802420 | /app/libglib.so |
| /proc/17/maps:7efd41980000-7efd41b7f000 | ---p | 06350000 | 00:a2 | 16802420 | /app/libglib.so |
| /proc/17/maps:7efd41b7f000-7efd41b80000 | r--p | 0634f000 | 00:a2 | 16802420 | /app/libglib.so |
| /proc/17/maps:7efd41b80000-7efd41b81000 | rw-p | 06350000 | 00:a2 | 16802420 | /app/libglib.so |
| /proc/39/maps:7fca97208000-7fca9d558000 | r-xp | 00000000 | 00:bb | 16802420 | /app/libglib.so |
| /proc/39/maps:7fca9d558000-7fca9d757000 | ---p | 06350000 | 00:bb | 16802420 | /app/libglib.so |
| /proc/39/maps:7fca9d757000-7fca9d758000 | r--p | 0634f000 | 00:bb | 16802420 | /app/libglib.so |
| /proc/39/maps:7fca9d758000-7fca9d759000 | rw-p | 06350000 | 00:bb | 16802420 | /app/libglib.so |
如果我正确地解释了结果，那么两个进程将查看完全不同的文件（设备 ID 不同），因此共享对象将在内存中加载两次（似乎与我使用 free 命令看到的一致）。
根据我在网上找到的信息，这种情况不应该发生。
我有以下问题：
提前致谢！
我不需要插入nouveau或安装专有驱动程序的“帮助”。问题是关于nvidiafb.谢谢。
我在 Linux 6.9-rc2 上使用 nvidia GT710 GPU。我想nvidiafb为我的旧 GPU 使用简单的驱动程序。在该系统上，我只需要帧缓冲区，不需要其他任何东西（没有 DRI）。但nvidiafb不起作用，它崩溃了。
# modprobe nvidiafb
Killed
#
nvidiafb: Device ID: 10de1287
Console: switching to colour dummy device 80x25
nvidiafb 0000:03:00.0: vgaarb: deactivate vga console
nvidiafb: CRTC0 analog not found
nvidiafb: CRTC1 analog not found
nvidiafb: Unable to detect display type...
...Using default of CRT
nvidiafb: Unable to detect which CRTCNumber...
...Defaulting to CRTCNumber 0
nvidiafb: Using CRT on CRTC 0
fbcon: NV28 (fb0) is primary device
divide error: 0000 [#1] PREEMPT_RT SMP
CPU: 0 PID: 194915 Comm: modprobe Tainted: G OE 6.9.0-rc2-home-rt+ #3 Hardware name: OEM X79G/X79G, BIOS 4.6.5 08/02/2022
RIP: 0010:nvGetClocks+0x18f/0x290 [nvidiafb]
Code: 0f 84 91 00 00 00 3d 30 03 00 00 0f 84 86 00 00 00 41 8b 89 04 05 00 00 0f b6 c5 44 0f b6 c9 c1 e9 10 0f af c2 31 d2 83 e1 0f <41> f7 f1 d3 e8 89 06 48 8b 87 a8 12 00 00 8b 88 00 05 00 00 0f b6
RSP: 0018:ffffa681b17e74e0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff921541eb4518 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffa681b17e7520 RDI: ffff921541eb4420
RBP: ffffa681b17e74e8 R08: ffffa681b17e7524 R09: 0000000000000000 R10: ffff921541eb4420 R11: 00000000002e18c8 R12: 0000000000000020 R13: 0000000000000008 R14: 0000000000000008 R15: 0000000000000068
FS: 00007fa3af639c40(0000) GS:ffff922406200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f2f8401f000 CR3: 00000010275bc001 CR4: 00000000001706f0
Call Trace:
<TASK>
? show_regs+0x6b/0x80
? __die_body+0x24/0x70
? die+0x42/0x70
? do_trap+0xde/0x100
? do_error_trap+0x73/0xa0
? nvGetClocks+0x18f/0x290 [nvidiafb]
? exc_divide_error+0x3f/0x60
? nvGetClocks+0x18f/0x290 [nvidiafb]
? asm_exc_divide_error+0x1f/0x30
? nvGetClocks+0x18f/0x290 [nvidiafb]
NVCalcStateExt+0x1da/0x9b0 [nvidiafb]
? set_inverse_trans_unicode+0xd0/0x100
? kmalloc_trace+0xac/0x280
nvidiafb_set_par+0x4a3/0xa40 [nvidiafb]
fbcon_init+0x2af/0x600
visual_init+0xf2/0x190
do_bind_con_driver+0x1d2/0x4a0
do_take_over_console+0x144/0x240
? vprintk_default+0x21/0x30
do_fbcon_takeover+0x78/0x130
do_fb_registered+0x139/0x270
fbcon_fb_registered+0x3b/0x90
? fb_add_videomode+0x81/0xf0
register_framebuffer+0x20a/0x300
nvidiafb_probe+0x6a4/0xad0 [nvidiafb]
? rt_spin_unlock+0x1c/0x50
local_pci_probe+0x4f/0xb0
pci_device_probe+0xcc/0x280
really_probe+0xff/0x390
__driver_probe_device+0x8a/0x170
driver_probe_device+0x23/0xb0
__driver_attach+0xc9/0x190
? __pfx___driver_attach+0x10/0x10
bus_for_each_dev+0x80/0xd0
driver_attach+0x22/0x30
bus_add_driver+0x123/0x230
driver_register+0x68/0x130
? __pfx_nvidiafb_init+0x10/0x10 [nvidiafb]
__pci_register_driver+0x6e/0x80
nvidiafb_init+0x37/0x50 [nvidiafb]
do_one_initcall+0x4c/0x310
? do_init_module+0x28/0x270
? kmalloc_trace+0xac/0x280
do_init_module+0x6a/0x270
load_module+0x221b/0x22e0
init_module_from_file+0x9c/0xe0
? init_module_from_file+0x9c/0xe0
idempotent_init_module+0x173/0x230
__x64_sys_finit_module+0x61/0xc0
do_syscall_64+0x79/0x120
? ksys_mmap_pgoff+0x11c/0x260
? syscall_exit_to_user_mode+0x87/0x1c0
? do_syscall_64+0x85/0x120
? do_syscall_64+0x85/0x120
entry_SYSCALL_64_after_hwframe+0x71/0x79
RIP: 0033:0x7fa3af75988d
Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 b5 0f 00 f7 d8 64 89 01 48 RSP: 002b:00007ffe8864c978 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 RAX: ffffffffffffffda RBX: 0000563b56dcbf80 RCX: 00007fa3af75988d RDX: 0000000000000000 RSI: 0000563b56dbacd2 RDI: 0000000000000005 RBP: 0000000000040000 R08: 0000000000000000 R09: 0000000000000002 R10: 0000000000000005 R11: 0000000000000246 R12: 0000563b56dbacd2 R13: 0000563b56dcc1b0 R14: 0000563b56dcc950 R15: 0000563b56dc5110
</TASK> Modules linked in: nvidiafb(+) vgastate fb_ddc vmnet(OE) vmw_vsock_vmci_transport vsock vmw_vmci vmmon(OE) ip6t_REJECT nf_reject_ipv6 ip6t_rt ipt_REJECT nf_reject_ipv4 xt_recent nft_limit xt_limit xt_addrtype xt_tcpudp xt_pkttype nft_chain_nat xt_MASQUERADE xt_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nft_compat nf_tables nfnetlink binfmt_misc intel_rapl_msr intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel snd_hda_codec_realtek snd_hda_codec_generic snd_hda_scodec_component snd_hda_codec_hdmi nls_iso8859_1 snd_hda_intel snd_intel_dspcfg input_leds snd_intel_sdw_acpi kvm joydev snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq rapl snd_seq_device intel_cstate snd_timer serio_raw pcspkr snd ioatdma soundcore dca mac_hid sch_fq_codel dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua parport_pc ppdev lp parport efi_pstore ip_tables x_tables autofs4 btrfs raid10 raid456 async_raid6_recov async_memcpy
async_pq async_xor async_tx raid1 raid0 gpu_sched drm_gpuvm drm_exec mxm_wmi video wmi i2c_algo_bit drm_ttm_helper ttm drm_display_helper cec rc_core drm_kms_helper cdc_ether usbnet drm hid_generic psmouse r8152 usbhid crct10dif_pclmul crc32_pclmul uas ghash_clmulni_intel sha512_ssse3 usb_storage hid sha256_ssse3 ahci sha1_ssse3 mii r8169 i2c_i801 libahci lpc_ich i2c_smbus realtek aesni_intel crypto_simd cryptd
---[ end trace 0000000000000000 ]---
RIP: 0010:nvGetClocks+0x18f/0x290 [nvidiafb]
Code: 0f 84 91 00 00 00 3d 30 03 00 00 0f 84 86 00 00 00 41 8b 89 04 05 00 00 0f b6 c5 44 0f b6 c9 c1 e9 10 0f af c2 31 d2 83 e1 0f <41> f7 f1 d3 e8 89 06 48 8b 87 a8 12 00 00 8b 88 00 05 00 00 0f b6
RSP: 0018:ffffa681b17e74e0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff921541eb4518 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffa681b17e7520 RDI: ffff921541eb4420
RBP: ffffa681b17e74e8 R08: ffffa681b17e7524 R09: 0000000000000000
R10: ffff921541eb4420 R11: 00000000002e18c8 R12: 0000000000000020
R13: 0000000000000008 R14: 0000000000000008 R15: 0000000000000068
FS: 00007fa3af639c40(0000) GS:ffff922406200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f2f8401f000 CR3: 00000010275bc001 CR4: 00000000001706f0
note: modprobe[194915] exited with preempt_count 2
到底是什么问题导致它无法与我的 GPU 一起正常工作？处的划分nvGetClocks+0x18f/0x290位于video/fbdev/nvidia/nv_hw.c，可能在这里（第 213 行）。对于这个特定的 GPU（而不是其他较旧的 GPU），除法的除数部分如何最终为零？
谢谢。
使用lshw查询我的 WiFi USB 适配器显示以下内容：
$ lshw -C network
*-network
description: Wireless interface
physical id: 12
bus info: usb@3:7
logical name: ...
serial: ...
capabilities: ethernet physical wireless
configuration: broadcast=yes driver=rtw_8822bu driverversion=6.5.0-28-generic firmware=N/A ip=... link=yes multicast=yes wireless=IEEE 802.11
适配器工作正常。然而，我很困惑driver=rtw_8822bu。据我所知，我的系统上没有调用内核模型rtw_8822bu.ko，相反，我有rtw88_8822bu.ko，
/usr/lib/modules/6.5.0-28-generic/kernel/drivers/net/wireless/realtek/rtw88/rtw88_8822bu.ko
它还显示使用lsmod：
$ lsmod | grep rtw
rtw88_8822bu 12288 0
rtw88_usb 24576 1 rtw88_8822bu
rtw88_8822b 229376 1 rtw88_8822bu
rtw88_core 356352 2 rtw88_usb,rtw88_8822b
mac80211 1720320 3 rtw88_core,rtw88_usb,rtl8xxxu
cfg80211 1323008 3 rtw88_core,mac80211,rtl8xxxu
问：为什么系统中的内核模块命名时会lshw显示。以前的名字是从哪里来的？driver=rtw_8822burtw88_8822bu
在虚拟机Kali中，我分配了4G内存，像这样；
但有一个问题。我在来宾上安装了自建内核来破解内存。
# uname -a
Linux 15ud490-gx76k 6.8.4+ #8 SMP PREEMPT_DYNAMIC Sat Apt 6 15:49:20 KST 2024 x86_64 x86_64 x86_64 GNU/Linux
我想看到内存结束的区域，如下所示。
它说内存的大小是16*0x336000字节。然后我用结果推断内存大小（在主机上）。
$ python3
Python 3.10.12 (main, Nov 20 2023, 15:14:05) [GCC 11.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 16*0x07fff0
8388352
>>> 16*0x07fff0/1024/1024
7.999755859375
>>> 16*0x335ff0/1024/1024
51.374755859375
>>> 16*0x336000/1024/1024
51.375
>>> 521000/1024/1024
0.49686431884765625
>>> (1024*1024*4+521000+3288)*1024/1024/1024/1024 # Convert into gigabytes
4.5
我给了 guest 内存 4G，但根据上面的情况，它有 4.5GiB。交换是1G所以这是废话。
0.5G内存的来源在哪里？？？？
根据我对 mmap() 的研究，我了解到 mmap 仅当通过页面错误触及虚拟内存地址时才使用请求分页将数据复制到内核页面缓存。
如果我们正在读取大于页面缓存的文件，则页面缓存中的一些陈旧页面将必须被换出回收。所以我的问题是，页表是否会更新以将相应的虚拟内存地址映射到缓存中旧的过时页面的地址（现在包含新数据）？这是怎么发生的？这是 mmap() 系统调用的一部分吗？
我的设备内存较差。过夜运行 memtest 显示所有故障地址都在该0x7d0000000 - 0x7f0000000范围内。我计划更换 RAM，但在那之前，我已经禁用了它周围的 2GB 块memmap=：
# cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.5.0-25-generic root=UUID=5277c53f-b2cd-4301-8fdf-0b2119430870 ro memmap=2G$0x0000000790000000 quiet splash vt.handoff=7
这些命令行选项似乎确实得到了内核的认可：
[ 0.000000] user-defined physical RAM map:
[ 0.000000] user: [mem 0x0000000000000000-0x000000000009efff] usable
[ 0.000000] user: [mem 0x000000000009f000-0x00000000000fffff] reserved
[ 0.000000] user: [mem 0x0000000000100000-0x0000000019e6a017] usable
[ 0.000000] user: [mem 0x0000000019e6a018-0x0000000019e7ae57] usable
[ 0.000000] user: [mem 0x0000000019e7ae58-0x000000002cb82fff] usable
[ 0.000000] user: [mem 0x000000002cb83000-0x000000002ed2ffff] reserved
[ 0.000000] user: [mem 0x000000002ed30000-0x000000002edacfff] ACPI data
[ 0.000000] user: [mem 0x000000002edad000-0x000000002f29bfff] ACPI NVS
[ 0.000000] user: [mem 0x000000002f29c000-0x000000002fd0efff] reserved
[ 0.000000] user: [mem 0x000000002fd0f000-0x000000002fd0ffff] usable
[ 0.000000] user: [mem 0x000000002fd10000-0x000000003cffffff] reserved
[ 0.000000] user: [mem 0x00000000e0000000-0x00000000efffffff] reserved
[ 0.000000] user: [mem 0x00000000fe000000-0x00000000fe010fff] reserved
[ 0.000000] user: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
[ 0.000000] user: [mem 0x00000000fed00000-0x00000000fed03fff] reserved
[ 0.000000] user: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
[ 0.000000] user: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
[ 0.000000] user: [mem 0x0000000100000000-0x000000078fffffff] usable
[ 0.000000] user: [mem 0x0000000790000000-0x000000080fffffff] reserved
[ 0.000000] user: [mem 0x0000000810000000-0x00000008beffffff] usable
但是，我仍然遇到段错误，表面上是在保留的地址范围内：
Mar 09 20:47:40 srv0 kernel: udisksd[656]: segfault at 7fe974786218 ip 00007fe974786218 sp 00007ffcd10d1848 error 7 in libbd_swap.so.3.0.0[7fe974785000+2000] likely on CPU 7 (core 3, socket 0)
根据此页面，我应该将其解释为 udiskd 尝试写入保留地址0x7fe974786218（错误 7）。乍一看，该0x7f地址似乎与 memtest 发现的坏 RAM 相符，但相差了几个数量级，因为它指向 140 TB 的值。我的机器有32GB。
如果不是内存地址，该segfault at X值代表什么？
我想编写一个小型的 Linux 驱动程序扩展。更具体地说：我想将主机和 M.2-nvme-ssd 之间的所有通信写入用户空间文件中。不过 nvme 驱动程序相当大，我很难确定从哪里开始。
我的一位同事对 SD 卡做了类似的事情。他在主机收到卡的响应并即将结束操作后跟踪IO（函数是sdhci_request_done）。跟踪显示带有操作码、数据和时间戳的请求和响应。像这样的事情将是我的目标。
我发现了跟踪 IO 的程序，但它们在用户空间中运行。这是一个问题，因为我可能会直接从驱动程序向卡发送消息。
所以我的问题是：我在哪里进入主机驱动程序来获取数据，而不延迟操作或分配太多内存。或者是否有一个驱动程序功能可以做到这一点？