# 2025q1 Homework5 (assessment)
contribute by < [dingsen-Greenhorn](https://github.com/dingsen-Greenhorn) >
{%hackmd NrmQUGbRQWemgwPfhzXj6g %}
## 因為自動飲料機而延畢的那一年
看完 〈[因為自動飲料機而延畢的那一年](https://www.opasschang.com/docs/the-story-of-auto-beverage-machine-23)〉,我對於整篇文章最大的感觸
>資工系的學生不會寫程式，機械系的學生不會做機械，現在又多一條電工系的學生不會焊電路。
>
解決真實世界的問題很難,回想一路以來自己所受到考試的訓練，心態上已經有點偏離學習的本質，只是再追求成績單上的分數，並且十分害怕失敗，對於文中主角的勇氣與毅力十分佩服，我想如果是我，恐怕無法如此窮理致知吧。
（這甚至是校訓，實在有愧阿！）
上禮拜與 Jserv meeting 完後回家思考很多，『誠實面對自己』我以為我已經有相當的認識了，直到看到學長這篇分享才感嘆自己太過天真了，實在需要時刻檢視自己的學習心態，回想我前六週，很誠實的說都只是再追上進度，有真的深刻了解系統軟體的該有的學習心態嘛？我可能還在 correct 這個最基本的要求上掙扎，我想我覺得自從與 Jserv meeting 完誠實面對現實後，才開始真正成長吧！
## 記錄教材心得與提問
在仔細閱讀教材時，發現可以改進，與幫助理解的更正。並且我已經在教材檔案中提出，紀錄如下。也期許自己在解決真實世界問題同時，小心警慎並專注細節，以下找出 7 處錯誤，並對於成果發表與貢獻而言，自認為還需努力，因此給予 7 分自評。
* 修正教材 <從 √2 的存在談開平方根的快速運算> 7 處錯誤。
[從 √2 的存在談開平方根的快速運算](https://hackmd.io/HUzAPdVVSACpsnaj5Omvgw?utm_source=suggest-edit-card&utm_medium=icon#Digit-by-digit-Method)。
* N 平方 -> N
* N = P0 -> N ~ P0
* M -> m
* qi~sqrt(x)
* convergence * 2
* 用使用 -> 使用
## 前六周練習與專題的相關技巧
### BAR（Base Address Register）
用來定義裝置所需的 MMIO/IO 空間大小與映射位置。
```
BAR: 透過讀寫 BARs 可以得知目標 function 需要的記憶體空間大小，並可藉其提供配置空間位址的資訊
BAR0: – Memory Register Base Address, lower 32-bits
BAR1: – Memory Register Base Address, upper 32-bits
```
BAR 分析步驟：
向 BAR 寫入全 1
讀出 BAR 的值
被保留（Read-only）的部分代表裝置實際所需空間大小
計算方式：
把讀出的值取反（bitwise NOT），加 1 → 即所需空間大小
這裡技巧與課堂 bitwise 操作中的 mask 有異曲同工
```
對齊（Alignment）
要將地址對齊到 4 KB（4096 bytes），常用 bitwise mask：
uintptr_t addr = 0x12345;
uintptr_t aligned = addr & ~(0xFFF); // 清除低 12 bits
這裡 ~0xFFF 就是一個 mask：保留高位，清除低位（強制對齊到 4 KB 邊界）。
```
## 期末專案討論
---
大概將[「Linux 核心設計」課程專題想法](https://hackmd.io/@sysprog/S18kgVDJex#%E3%80%8CLinux-%E6%A0%B8%E5%BF%83%E8%A8%AD%E8%A8%88%E3%80%8D%E8%AA%B2%E7%A8%8B%E5%B0%88%E9%A1%8C%E6%83%B3%E6%B3%95) 看過一輪，目前有初步
1.想法的是 [ PCI 配置空間(Configuration Space) 的存取程式碼重構](https://hackmd.io/@sysprog/S18kgVDJex#PCI-%E9%85%8D%E7%BD%AE%E7%A9%BA%E9%96%93Configuration-Space-%E7%9A%84%E5%AD%98%E5%8F%96%E7%A8%8B%E5%BC%8F%E7%A2%BC%E9%87%8D%E6%A7%8B)這個學長提供的想法，大略瀏覽過後，有幾個初步的想法。
2.[虛擬無線網路裝置驅動程式](https://hackmd.io/@sysprog/rJ-LF4nNC) 看到裡面的背景知識發現很適合我，我目前的研究主要就是天線選擇的演算法，看到去年學長的專案內背景知識，都是我所學過<無線通訊>網路層與<數位通訊>實體層中講解的基礎，像是調變的原理與計算 rate 與 BER 估算的方法等...,初步評估會比較快上手。
### 1. PCI 配置空間(Configuration Space
The two code implement interfaces for interacting with PCI devices in the Linux kernel: one through sysfs (`pci-sysfs.c`) and the other through procfs (`pci-proc.c`). Both serve similar purposes, such as providing access to PCI configuration space, resources, and device attributes, but they use different filesystem interfaces. Below, I analyze the potential for reconstructing these into a more unified or modular approach.
#### Analysis of Similarities and Differences
**Similarities:**
1. **Purpose**: Both provide user-space access to PCI device information, such as configuration space, resources, and attributes like vendor ID, device ID, and IRQs.
2. **Configuration Space Access**:
- `pci-sysfs.c` exposes configuration space via the `config` binary attribute, with `pci_read_config` and `pci_write_config` handling reads and writes.
- `pci-proc.c` exposes configuration space through procfs files, with `proc_bus_pci_read` and `proc_bus_pci_write` performing similar operations.
3. **Resource Exposure**:
- `pci-sysfs.c` exposes resources via `resource` attributes and individual `resourceN` files for BARs.
- `pci-proc.c` lists resources in the `/proc/bus/pci/devices` file.
4. **Permission Checks**:
- Both restrict access to configuration space based on `CAP_SYS_ADMIN` for non-standard regions and enforce `LOCKDOWN_PCI_ACCESS` for security.
5. **Initialization**:
- Both initialize their interfaces late in the boot process (`late_initcall` in sysfs, `device_initcall` in procfs) and iterate over PCI devices to set up files.
**Differences:**
1. **Interface**:
- Sysfs uses a structured, attribute-based interface with individual files for each attribute (e.g., `vendor`, `irq`, `resource`).
- Procfs uses a more traditional file-based interface, with configuration space exposed as files under `/proc/bus/pci/<bus>/<slot>.<func>` and a summary in `/proc/bus/pci/devices`.
2. **Configuration Space Handling**:
- Sysfs handles configuration space reads/writes in a binary attribute (`config`), with byte, word, and dword operations.
- Procfs performs similar operations but applies byte-order conversions (`cpu_to_le16`, `cpu_to_le32`) for user-space compatibility.
3. **Resource Access**:
- Sysfs provides detailed per-resource files (`resourceN`, `resourceN_wc`) and supports memory mapping (`mmap`) for resources.
- Procfs only lists resource details in `/proc/bus/pci/devices` without direct mapping support.
4. **Memory Mapping**:
- Sysfs supports `mmap` for legacy I/O, memory, and BARs (`pci_mmap_resource`, `pci_mmap_legacy_*`).
- Procfs supports `mmap` for resources but requires `HAVE_PCI_MMAP` and uses a custom `pci_filp_private` structure to track mapping state.
5. **Extensibility**:
- Sysfs is more extensible, with attribute groups for bridges, PCIe, reset methods, and architecture-specific attributes.
- Procfs is less flexible, primarily focused on configuration space and a device summary.
#### Potential for Reconstruction
Given the overlap in functionality, there is an opportunity to refactor the code to reduce duplication, improve maintainability, and potentially consolidate common logic. However, completely merging the two is challenging due to the distinct nature of sysfs (attribute-based, per-device) and procfs (file-based, bus-oriented). Instead, a modular approach can be adopted to share common logic while preserving the unique aspects of each interface.
#### Challenges and Considerations
1. **Interface Differences**: Sysfs and procfs have different paradigms (attribute-based vs. file-based), making full unification impractical. The modular approach respects these differences while sharing common logic.
2. **Performance**: The shared functions introduce minimal overhead (e.g., parameter passing), but the impact is negligible given the infrequency of PCI configuration access.
3. **Testing**: The refactored code must be thoroughly tested to ensure no regressions in sysfs or procfs behavior, especially for edge cases like CardBus devices or non-standard configuration spaces.
4. **Upstream Acceptance**: Changes to the Linux kernel require community review. The modular approach aligns with kernel coding practices, but the benefit of reduced duplication must be weighed against the complexity of refactoring existing code.
#### Conclusion
The proposed reconstruction modularizes common functionality into a shared `pci-config` module, reducing duplication while preserving the distinct sysfs and procfs interfaces. The modifications focus on configuration space access, resource handling, memory mapping, and initialization, providing a cleaner, more maintainable codebase without breaking user-space compatibility. The justification for each change emphasizes code reuse, consistency, and extensibility, making this approach suitable for long-term kernel maintenance.
### 2.虛擬無線網路裝置驅動程式
#### 初步想法
理解 vwifi 運作原理
使專案成功執行在最新版本的 Linux
實作封包傳遞機制
設計可調整調變
測試分析效能與改進
#### 過往開發紀錄
[2022-2023 willwillhi1 ](https://hackmd.io/@sysprog/rJD2joOSh)
[2024jychen0611](https://hackmd.io/@sysprog/rJ-LF4nNC)
Sign in with Wallet
Connect another wallet