Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux

docs/zh_TW: add translations for zh_TW/filesystems

Create new translations for zh_TW/filesystems and link them to index.

Signed-off-by: Hu Haowen <src.res@email.cn>
Link: https://lore.kernel.org/r/20210821094059.64300-3-src.res@email.cn
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

authored by

Hu Haowen and committed by
Jonathan Corbet
bf608ebc ac8fa1bd

+843 -1
+224
Documentation/translations/zh_TW/filesystems/debugfs.rst
··· 1 + .. SPDX-License-Identifier: GPL-2.0 2 + 3 + .. include:: ../disclaimer-zh_TW.rst 4 + 5 + :Original: :doc:`../../../filesystems/debugfs` 6 + 7 + ======= 8 + Debugfs 9 + ======= 10 + 11 + 譯者 12 + :: 13 + 14 + 中文版維護者:羅楚成 Chucheng Luo <luochucheng@vivo.com> 15 + 中文版翻譯者:羅楚成 Chucheng Luo <luochucheng@vivo.com> 16 + 中文版校譯者: 羅楚成 Chucheng Luo <luochucheng@vivo.com> 17 + 繁體中文版校譯者: 胡皓文 Hu Haowen <src.res@email.cn> 18 + 19 + 20 + 21 + 版權所有2020 羅楚成 <luochucheng@vivo.com> 22 + 版權所有2021 胡皓文 Hu Haowen <src.res@email.cn> 23 + 24 + 25 + Debugfs是內核開發人員在用戶空間獲取信息的簡單方法。與/proc不同,proc只提供進程 26 + 信息。也不像sysfs,具有嚴格的「每個文件一個值「的規則。debugfs根本沒有規則,開發 27 + 人員可以在這裡放置他們想要的任何信息。debugfs文件系統也不能用作穩定的ABI接口。 28 + 從理論上講,debugfs導出文件的時候沒有任何約束。但是[1]實際情況並不總是那麼 29 + 簡單。即使是debugfs接口,也最好根據需要進行設計,並儘量保持接口不變。 30 + 31 + 32 + Debugfs通常使用以下命令安裝:: 33 + 34 + mount -t debugfs none /sys/kernel/debug 35 + 36 + (或等效的/etc/fstab行)。 37 + debugfs根目錄默認僅可由root用戶訪問。要更改對文件樹的訪問,請使用「 uid」,「 gid」 38 + 和「 mode」掛載選項。請注意,debugfs API僅按照GPL協議導出到模塊。 39 + 40 + 使用debugfs的代碼應包含<linux/debugfs.h>。然後,首先是創建至少一個目錄來保存 41 + 一組debugfs文件:: 42 + 43 + struct dentry *debugfs_create_dir(const char *name, struct dentry *parent); 44 + 45 + 如果成功,此調用將在指定的父目錄下創建一個名爲name的目錄。如果parent參數爲空, 46 + 則會在debugfs根目錄中創建。創建目錄成功時,返回值是一個指向dentry結構體的指針。 47 + 該dentry結構體的指針可用於在目錄中創建文件(以及最後將其清理乾淨)。ERR_PTR 48 + (-ERROR)返回值表明出錯。如果返回ERR_PTR(-ENODEV),則表明內核是在沒有debugfs 49 + 支持的情況下構建的,並且下述函數都不會起作用。 50 + 51 + 在debugfs目錄中創建文件的最通用方法是:: 52 + 53 + struct dentry *debugfs_create_file(const char *name, umode_t mode, 54 + struct dentry *parent, void *data, 55 + const struct file_operations *fops); 56 + 57 + 在這裡,name是要創建的文件的名稱,mode描述了訪問文件應具有的權限,parent指向 58 + 應該保存文件的目錄,data將存儲在產生的inode結構體的i_private欄位中,而fops是 59 + 一組文件操作函數,這些函數中實現文件操作的具體行爲。至少,read()和/或 60 + write()操作應提供;其他可以根據需要包括在內。同樣的,返回值將是指向創建文件 61 + 的dentry指針,錯誤時返回ERR_PTR(-ERROR),系統不支持debugfs時返回值爲ERR_PTR 62 + (-ENODEV)。創建一個初始大小的文件,可以使用以下函數代替:: 63 + 64 + struct dentry *debugfs_create_file_size(const char *name, umode_t mode, 65 + struct dentry *parent, void *data, 66 + const struct file_operations *fops, 67 + loff_t file_size); 68 + 69 + file_size是初始文件大小。其他參數跟函數debugfs_create_file的相同。 70 + 71 + 在許多情況下,沒必要自己去創建一組文件操作;對於一些簡單的情況,debugfs代碼提供 72 + 了許多幫助函數。包含單個整數值的文件可以使用以下任何一項創建:: 73 + 74 + void debugfs_create_u8(const char *name, umode_t mode, 75 + struct dentry *parent, u8 *value); 76 + void debugfs_create_u16(const char *name, umode_t mode, 77 + struct dentry *parent, u16 *value); 78 + struct dentry *debugfs_create_u32(const char *name, umode_t mode, 79 + struct dentry *parent, u32 *value); 80 + void debugfs_create_u64(const char *name, umode_t mode, 81 + struct dentry *parent, u64 *value); 82 + 83 + 這些文件支持讀取和寫入給定值。如果某個文件不支持寫入,只需根據需要設置mode 84 + 參數位。這些文件中的值以十進位表示;如果需要使用十六進位,可以使用以下函數 85 + 替代:: 86 + 87 + void debugfs_create_x8(const char *name, umode_t mode, 88 + struct dentry *parent, u8 *value); 89 + void debugfs_create_x16(const char *name, umode_t mode, 90 + struct dentry *parent, u16 *value); 91 + void debugfs_create_x32(const char *name, umode_t mode, 92 + struct dentry *parent, u32 *value); 93 + void debugfs_create_x64(const char *name, umode_t mode, 94 + struct dentry *parent, u64 *value); 95 + 96 + 這些功能只有在開發人員知道導出值的大小的時候才有用。某些數據類型在不同的架構上 97 + 有不同的寬度,這樣會使情況變得有些複雜。在這種特殊情況下可以使用以下函數:: 98 + 99 + void debugfs_create_size_t(const char *name, umode_t mode, 100 + struct dentry *parent, size_t *value); 101 + 102 + 不出所料,此函數將創建一個debugfs文件來表示類型爲size_t的變量。 103 + 104 + 同樣地,也有導出無符號長整型變量的函數,分別以十進位和十六進位表示如下:: 105 + 106 + struct dentry *debugfs_create_ulong(const char *name, umode_t mode, 107 + struct dentry *parent, 108 + unsigned long *value); 109 + void debugfs_create_xul(const char *name, umode_t mode, 110 + struct dentry *parent, unsigned long *value); 111 + 112 + 布爾值可以通過以下方式放置在debugfs中:: 113 + 114 + struct dentry *debugfs_create_bool(const char *name, umode_t mode, 115 + struct dentry *parent, bool *value); 116 + 117 + 118 + 讀取結果文件將產生Y(對於非零值)或N,後跟換行符寫入的時候,它只接受大寫或小寫 119 + 值或1或0。任何其他輸入將被忽略。 120 + 121 + 同樣,atomic_t類型的值也可以放置在debugfs中:: 122 + 123 + void debugfs_create_atomic_t(const char *name, umode_t mode, 124 + struct dentry *parent, atomic_t *value) 125 + 126 + 讀取此文件將獲得atomic_t值,寫入此文件將設置atomic_t值。 127 + 128 + 另一個選擇是通過以下結構體和函數導出一個任意二進位數據塊:: 129 + 130 + struct debugfs_blob_wrapper { 131 + void *data; 132 + unsigned long size; 133 + }; 134 + 135 + struct dentry *debugfs_create_blob(const char *name, umode_t mode, 136 + struct dentry *parent, 137 + struct debugfs_blob_wrapper *blob); 138 + 139 + 讀取此文件將返回由指針指向debugfs_blob_wrapper結構體的數據。一些驅動使用「blobs」 140 + 作爲一種返回幾行(靜態)格式化文本的簡單方法。這個函數可用於導出二進位信息,但 141 + 似乎在主線中沒有任何代碼這樣做。請注意,使用debugfs_create_blob()命令創建的 142 + 所有文件是只讀的。 143 + 144 + 如果您要轉儲一個寄存器塊(在開發過程中經常會這麼做,但是這樣的調試代碼很少上傳 145 + 到主線中。Debugfs提供兩個函數:一個用於創建僅寄存器文件,另一個把一個寄存器塊 146 + 插入一個順序文件中:: 147 + 148 + struct debugfs_reg32 { 149 + char *name; 150 + unsigned long offset; 151 + }; 152 + 153 + struct debugfs_regset32 { 154 + struct debugfs_reg32 *regs; 155 + int nregs; 156 + void __iomem *base; 157 + }; 158 + 159 + struct dentry *debugfs_create_regset32(const char *name, umode_t mode, 160 + struct dentry *parent, 161 + struct debugfs_regset32 *regset); 162 + 163 + void debugfs_print_regs32(struct seq_file *s, struct debugfs_reg32 *regs, 164 + int nregs, void __iomem *base, char *prefix); 165 + 166 + 「base」參數可能爲0,但您可能需要使用__stringify構建reg32數組,實際上有許多寄存器 167 + 名稱(宏)是寄存器塊在基址上的字節偏移量。 168 + 169 + 如果要在debugfs中轉儲u32數組,可以使用以下函數創建文件:: 170 + 171 + void debugfs_create_u32_array(const char *name, umode_t mode, 172 + struct dentry *parent, 173 + u32 *array, u32 elements); 174 + 175 + 「array」參數提供數據,而「elements」參數爲數組中元素的數量。注意:數組創建後,數組 176 + 大小無法更改。 177 + 178 + 有一個函數來創建與設備相關的seq_file:: 179 + 180 + struct dentry *debugfs_create_devm_seqfile(struct device *dev, 181 + const char *name, 182 + struct dentry *parent, 183 + int (*read_fn)(struct seq_file *s, 184 + void *data)); 185 + 186 + 「dev」參數是與此debugfs文件相關的設備,並且「read_fn」是一個函數指針,這個函數在 187 + 列印seq_file內容的時候被回調。 188 + 189 + 還有一些其他的面向目錄的函數:: 190 + 191 + struct dentry *debugfs_rename(struct dentry *old_dir, 192 + struct dentry *old_dentry, 193 + struct dentry *new_dir, 194 + const char *new_name); 195 + 196 + struct dentry *debugfs_create_symlink(const char *name, 197 + struct dentry *parent, 198 + const char *target); 199 + 200 + 調用debugfs_rename()將爲現有的debugfs文件重命名,可能同時切換目錄。 new_name 201 + 函數調用之前不能存在;返回值爲old_dentry,其中包含更新的信息。可以使用 202 + debugfs_create_symlink()創建符號連結。 203 + 204 + 所有debugfs用戶必須考慮的一件事是: 205 + 206 + debugfs不會自動清除在其中創建的任何目錄。如果一個模塊在不顯式刪除debugfs目錄的 207 + 情況下卸載模塊,結果將會遺留很多野指針,從而導致系統不穩定。因此,所有debugfs 208 + 用戶-至少是那些可以作爲模塊構建的用戶-必須做模塊卸載的時候準備刪除在此創建的 209 + 所有文件和目錄。一份文件可以通過以下方式刪除:: 210 + 211 + void debugfs_remove(struct dentry *dentry); 212 + 213 + dentry值可以爲NULL或錯誤值,在這種情況下,不會有任何文件被刪除。 214 + 215 + 很久以前,內核開發者使用debugfs時需要記錄他們創建的每個dentry指針,以便最後所有 216 + 文件都可以被清理掉。但是,現在debugfs用戶能調用以下函數遞歸清除之前創建的文件:: 217 + 218 + void debugfs_remove_recursive(struct dentry *dentry); 219 + 220 + 如果將對應頂層目錄的dentry傳遞給以上函數,則該目錄下的整個層次結構將會被刪除。 221 + 222 + 注釋: 223 + [1] http://lwn.net/Articles/309298/ 224 +
+31
Documentation/translations/zh_TW/filesystems/index.rst
··· 1 + .. SPDX-License-Identifier: GPL-2.0 2 + 3 + .. include:: ../disclaimer-zh_TW.rst 4 + 5 + :Original: :ref:`Documentation/filesystems/index.rst <filesystems_index>` 6 + :Translator: Wang Wenhu <wenhu.wang@vivo.com> 7 + Hu Haowen <src.res@email.cn> 8 + 9 + .. _tw_filesystems_index: 10 + 11 + ======================== 12 + Linux Kernel中的文件系統 13 + ======================== 14 + 15 + 這份正在開發的手冊或許在未來某個輝煌的日子裡以易懂的形式將Linux虛擬\ 16 + 文件系統(VFS)層以及基於其上的各種文件系統如何工作呈現給大家。當前\ 17 + 可以看到下面的內容。 18 + 19 + 文件系統 20 + ======== 21 + 22 + 文件系統實現文檔。 23 + 24 + .. toctree:: 25 + :maxdepth: 2 26 + 27 + virtiofs 28 + debugfs 29 + tmpfs 30 + 31 +
+377
Documentation/translations/zh_TW/filesystems/sysfs.txt
··· 1 + SPDX-License-Identifier: GPL-2.0 2 + 3 + Chinese translated version of Documentation/filesystems/sysfs.rst 4 + 5 + If you have any comment or update to the content, please contact the 6 + original document maintainer directly. However, if you have a problem 7 + communicating in English you can also ask the Chinese maintainer for 8 + help. Contact the Chinese maintainer if this translation is outdated 9 + or if there is a problem with the translation. 10 + 11 + Maintainer: Patrick Mochel <mochel@osdl.org> 12 + Mike Murphy <mamurph@cs.clemson.edu> 13 + Chinese maintainer: Fu Wei <tekkamanninja@gmail.com> 14 + --------------------------------------------------------------------- 15 + Documentation/filesystems/sysfs.rst 的中文翻譯 16 + 17 + 如果想評論或更新本文的內容,請直接聯繫原文檔的維護者。如果你使用英文 18 + 交流有困難的話,也可以向中文版維護者求助。如果本翻譯更新不及時或者翻 19 + 譯存在問題,請聯繫中文版維護者。 20 + 英文版維護者: Patrick Mochel <mochel@osdl.org> 21 + Mike Murphy <mamurph@cs.clemson.edu> 22 + 中文版維護者: 傅煒 Fu Wei <tekkamanninja@gmail.com> 23 + 中文版翻譯者: 傅煒 Fu Wei <tekkamanninja@gmail.com> 24 + 中文版校譯者: 傅煒 Fu Wei <tekkamanninja@gmail.com> 25 + 繁體中文版校譯者:胡皓文 Hu Haowen <src.res@email.cn> 26 + 27 + 28 + 以下爲正文 29 + --------------------------------------------------------------------- 30 + sysfs - 用於導出內核對象(kobject)的文件系統 31 + 32 + Patrick Mochel <mochel@osdl.org> 33 + Mike Murphy <mamurph@cs.clemson.edu> 34 + 35 + 修訂: 16 August 2011 36 + 原始版本: 10 January 2003 37 + 38 + 39 + sysfs 簡介: 40 + ~~~~~~~~~~ 41 + 42 + sysfs 是一個最初基於 ramfs 且位於內存的文件系統。它提供導出內核 43 + 數據結構及其屬性,以及它們之間的關聯到用戶空間的方法。 44 + 45 + sysfs 始終與 kobject 的底層結構緊密相關。請閱讀 46 + Documentation/core-api/kobject.rst 文檔以獲得更多關於 kobject 接口的 47 + 信息。 48 + 49 + 50 + 使用 sysfs 51 + ~~~~~~~~~~~ 52 + 53 + 只要內核配置中定義了 CONFIG_SYSFS ,sysfs 總是被編譯進內核。你可 54 + 通過以下命令掛載它: 55 + 56 + mount -t sysfs sysfs /sys 57 + 58 + 59 + 創建目錄 60 + ~~~~~~~~ 61 + 62 + 任何 kobject 在系統中註冊,就會有一個目錄在 sysfs 中被創建。這個 63 + 目錄是作爲該 kobject 的父對象所在目錄的子目錄創建的,以準確地傳遞 64 + 內核的對象層次到用戶空間。sysfs 中的頂層目錄代表著內核對象層次的 65 + 共同祖先;例如:某些對象屬於某個子系統。 66 + 67 + Sysfs 在與其目錄關聯的 kernfs_node 對象中內部保存一個指向實現 68 + 目錄的 kobject 的指針。以前,這個 kobject 指針被 sysfs 直接用於 69 + kobject 文件打開和關閉的引用計數。而現在的 sysfs 實現中,kobject 70 + 引用計數只能通過 sysfs_schedule_callback() 函數直接修改。 71 + 72 + 73 + 屬性 74 + ~~~~ 75 + 76 + kobject 的屬性可在文件系統中以普通文件的形式導出。Sysfs 爲屬性定義 77 + 了面向文件 I/O 操作的方法,以提供對內核屬性的讀寫。 78 + 79 + 80 + 屬性應爲 ASCII 碼文本文件。以一個文件只存儲一個屬性值爲宜。但一個 81 + 文件只包含一個屬性值可能影響效率,所以一個包含相同數據類型的屬性值 82 + 數組也被廣泛地接受。 83 + 84 + 混合類型、表達多行數據以及一些怪異的數據格式會遭到強烈反對。這樣做是 85 + 很丟臉的,而且其代碼會在未通知作者的情況下被重寫。 86 + 87 + 88 + 一個簡單的屬性結構定義如下: 89 + 90 + struct attribute { 91 + char * name; 92 + struct module *owner; 93 + umode_t mode; 94 + }; 95 + 96 + 97 + int sysfs_create_file(struct kobject * kobj, const struct attribute * attr); 98 + void sysfs_remove_file(struct kobject * kobj, const struct attribute * attr); 99 + 100 + 101 + 一個單獨的屬性結構並不包含讀寫其屬性值的方法。子系統最好爲增刪特定 102 + 對象類型的屬性定義自己的屬性結構體和封裝函數。 103 + 104 + 例如:驅動程序模型定義的 device_attribute 結構體如下: 105 + 106 + struct device_attribute { 107 + struct attribute attr; 108 + ssize_t (*show)(struct device *dev, struct device_attribute *attr, 109 + char *buf); 110 + ssize_t (*store)(struct device *dev, struct device_attribute *attr, 111 + const char *buf, size_t count); 112 + }; 113 + 114 + int device_create_file(struct device *, const struct device_attribute *); 115 + void device_remove_file(struct device *, const struct device_attribute *); 116 + 117 + 爲了定義設備屬性,同時定義了一下輔助宏: 118 + 119 + #define DEVICE_ATTR(_name, _mode, _show, _store) \ 120 + struct device_attribute dev_attr_##_name = __ATTR(_name, _mode, _show, _store) 121 + 122 + 例如:聲明 123 + 124 + static DEVICE_ATTR(foo, S_IWUSR | S_IRUGO, show_foo, store_foo); 125 + 126 + 等同於如下代碼: 127 + 128 + static struct device_attribute dev_attr_foo = { 129 + .attr = { 130 + .name = "foo", 131 + .mode = S_IWUSR | S_IRUGO, 132 + .show = show_foo, 133 + .store = store_foo, 134 + }, 135 + }; 136 + 137 + 138 + 子系統特有的回調函數 139 + ~~~~~~~~~~~~~~~~~~~ 140 + 141 + 當一個子系統定義一個新的屬性類型時,必須實現一系列的 sysfs 操作, 142 + 以幫助讀寫調用實現屬性所有者的顯示和儲存方法。 143 + 144 + struct sysfs_ops { 145 + ssize_t (*show)(struct kobject *, struct attribute *, char *); 146 + ssize_t (*store)(struct kobject *, struct attribute *, const char *, size_t); 147 + }; 148 + 149 + [子系統應已經定義了一個 struct kobj_type 結構體作爲這個類型的 150 + 描述符,並在此保存 sysfs_ops 的指針。更多的信息參見 kobject 的 151 + 文檔] 152 + 153 + sysfs 會爲這個類型調用適當的方法。當一個文件被讀寫時,這個方法會 154 + 將一般的kobject 和 attribute 結構體指針轉換爲適當的指針類型後 155 + 調用相關聯的函數。 156 + 157 + 158 + 示例: 159 + 160 + #define to_dev_attr(_attr) container_of(_attr, struct device_attribute, attr) 161 + 162 + static ssize_t dev_attr_show(struct kobject *kobj, struct attribute *attr, 163 + char *buf) 164 + { 165 + struct device_attribute *dev_attr = to_dev_attr(attr); 166 + struct device *dev = kobj_to_dev(kobj); 167 + ssize_t ret = -EIO; 168 + 169 + if (dev_attr->show) 170 + ret = dev_attr->show(dev, dev_attr, buf); 171 + if (ret >= (ssize_t)PAGE_SIZE) { 172 + printk("dev_attr_show: %pS returned bad count\n", 173 + dev_attr->show); 174 + } 175 + return ret; 176 + } 177 + 178 + 179 + 180 + 讀寫屬性數據 181 + ~~~~~~~~~~~~ 182 + 183 + 在聲明屬性時,必須指定 show() 或 store() 方法,以實現屬性的 184 + 讀或寫。這些方法的類型應該和以下的設備屬性定義一樣簡單。 185 + 186 + ssize_t (*show)(struct device *dev, struct device_attribute *attr, char *buf); 187 + ssize_t (*store)(struct device *dev, struct device_attribute *attr, 188 + const char *buf, size_t count); 189 + 190 + 也就是說,他們應只以一個處理對象、一個屬性和一個緩衝指針作爲參數。 191 + 192 + sysfs 會分配一個大小爲 (PAGE_SIZE) 的緩衝區並傳遞給這個方法。 193 + Sysfs 將會爲每次讀寫操作調用一次這個方法。這使得這些方法在執行時 194 + 會出現以下的行爲: 195 + 196 + - 在讀方面(read(2)),show() 方法應該填充整個緩衝區。回想屬性 197 + 應只導出了一個屬性值或是一個同類型屬性值的數組,所以這個代價將 198 + 不會不太高。 199 + 200 + 這使得用戶空間可以局部地讀和任意的向前搜索整個文件。如果用戶空間 201 + 向後搜索到零或使用『0』偏移執行一個pread(2)操作,show()方法將 202 + 再次被調用,以重新填充緩存。 203 + 204 + - 在寫方面(write(2)),sysfs 希望在第一次寫操作時得到整個緩衝區。 205 + 之後 Sysfs 傳遞整個緩衝區給 store() 方法。 206 + 207 + 當要寫 sysfs 文件時,用戶空間進程應首先讀取整個文件,修該想要 208 + 改變的值,然後回寫整個緩衝區。 209 + 210 + 在讀寫屬性值時,屬性方法的執行應操作相同的緩衝區。 211 + 212 + 註記: 213 + 214 + - 寫操作導致的 show() 方法重載,會忽略當前文件位置。 215 + 216 + - 緩衝區應總是 PAGE_SIZE 大小。對於i386,這個值爲4096。 217 + 218 + - show() 方法應該返回寫入緩衝區的字節數,也就是 scnprintf()的 219 + 返回值。 220 + 221 + - show() 方法在將格式化返回值返回用戶空間的時候,禁止使用snprintf()。 222 + 如果可以保證不會發生緩衝區溢出,可以使用sprintf(),否則必須使用 223 + scnprintf()。 224 + 225 + - store() 應返回緩衝區的已用字節數。如果整個緩存都已填滿,只需返回 226 + count 參數。 227 + 228 + - show() 或 store() 可以返回錯誤值。當得到一個非法值,必須返回一個 229 + 錯誤值。 230 + 231 + - 一個傳遞給方法的對象將會通過 sysfs 調用對象內嵌的引用計數固定在 232 + 內存中。儘管如此,對象代表的物理實體(如設備)可能已不存在。如有必要, 233 + 應該實現一個檢測機制。 234 + 235 + 一個簡單的(未經實驗證實的)設備屬性實現如下: 236 + 237 + static ssize_t show_name(struct device *dev, struct device_attribute *attr, 238 + char *buf) 239 + { 240 + return scnprintf(buf, PAGE_SIZE, "%s\n", dev->name); 241 + } 242 + 243 + static ssize_t store_name(struct device *dev, struct device_attribute *attr, 244 + const char *buf, size_t count) 245 + { 246 + snprintf(dev->name, sizeof(dev->name), "%.*s", 247 + (int)min(count, sizeof(dev->name) - 1), buf); 248 + return count; 249 + } 250 + 251 + static DEVICE_ATTR(name, S_IRUGO, show_name, store_name); 252 + 253 + 254 + (注意:真正的實現不允許用戶空間設置設備名。) 255 + 256 + 頂層目錄布局 257 + ~~~~~~~~~~~~ 258 + 259 + sysfs 目錄的安排顯示了內核數據結構之間的關係。 260 + 261 + 頂層 sysfs 目錄如下: 262 + 263 + block/ 264 + bus/ 265 + class/ 266 + dev/ 267 + devices/ 268 + firmware/ 269 + net/ 270 + fs/ 271 + 272 + devices/ 包含了一個設備樹的文件系統表示。他直接映射了內部的內核 273 + 設備樹,反映了設備的層次結構。 274 + 275 + bus/ 包含了內核中各種總線類型的平面目錄布局。每個總線目錄包含兩個 276 + 子目錄: 277 + 278 + devices/ 279 + drivers/ 280 + 281 + devices/ 包含了系統中出現的每個設備的符號連結,他們指向 root/ 下的 282 + 設備目錄。 283 + 284 + drivers/ 包含了每個已爲特定總線上的設備而掛載的驅動程序的目錄(這裡 285 + 假定驅動沒有跨越多個總線類型)。 286 + 287 + fs/ 包含了一個爲文件系統設立的目錄。現在每個想要導出屬性的文件系統必須 288 + 在 fs/ 下創建自己的層次結構(參見Documentation/filesystems/fuse.rst)。 289 + 290 + dev/ 包含兩個子目錄: char/ 和 block/。在這兩個子目錄中,有以 291 + <major>:<minor> 格式命名的符號連結。這些符號連結指向 sysfs 目錄 292 + 中相應的設備。/sys/dev 提供一個通過一個 stat(2) 操作結果,查找 293 + 設備 sysfs 接口快捷的方法。 294 + 295 + 更多有關 driver-model 的特性信息可以在 Documentation/driver-api/driver-model/ 296 + 中找到。 297 + 298 + 299 + TODO: 完成這一節。 300 + 301 + 302 + 當前接口 303 + ~~~~~~~~ 304 + 305 + 以下的接口層普遍存在於當前的sysfs中: 306 + 307 + - 設備 (include/linux/device.h) 308 + ---------------------------------- 309 + 結構體: 310 + 311 + struct device_attribute { 312 + struct attribute attr; 313 + ssize_t (*show)(struct device *dev, struct device_attribute *attr, 314 + char *buf); 315 + ssize_t (*store)(struct device *dev, struct device_attribute *attr, 316 + const char *buf, size_t count); 317 + }; 318 + 319 + 聲明: 320 + 321 + DEVICE_ATTR(_name, _mode, _show, _store); 322 + 323 + 增/刪屬性: 324 + 325 + int device_create_file(struct device *dev, const struct device_attribute * attr); 326 + void device_remove_file(struct device *dev, const struct device_attribute * attr); 327 + 328 + 329 + - 總線驅動程序 (include/linux/device.h) 330 + -------------------------------------- 331 + 結構體: 332 + 333 + struct bus_attribute { 334 + struct attribute attr; 335 + ssize_t (*show)(struct bus_type *, char * buf); 336 + ssize_t (*store)(struct bus_type *, const char * buf, size_t count); 337 + }; 338 + 339 + 聲明: 340 + 341 + BUS_ATTR(_name, _mode, _show, _store) 342 + 343 + 增/刪屬性: 344 + 345 + int bus_create_file(struct bus_type *, struct bus_attribute *); 346 + void bus_remove_file(struct bus_type *, struct bus_attribute *); 347 + 348 + 349 + - 設備驅動程序 (include/linux/device.h) 350 + ----------------------------------------- 351 + 352 + 結構體: 353 + 354 + struct driver_attribute { 355 + struct attribute attr; 356 + ssize_t (*show)(struct device_driver *, char * buf); 357 + ssize_t (*store)(struct device_driver *, const char * buf, 358 + size_t count); 359 + }; 360 + 361 + 聲明: 362 + 363 + DRIVER_ATTR(_name, _mode, _show, _store) 364 + 365 + 增/刪屬性: 366 + 367 + int driver_create_file(struct device_driver *, const struct driver_attribute *); 368 + void driver_remove_file(struct device_driver *, const struct driver_attribute *); 369 + 370 + 371 + 文檔 372 + ~~~~ 373 + 374 + sysfs 目錄結構以及其中包含的屬性定義了一個內核與用戶空間之間的 ABI。 375 + 對於任何 ABI,其自身的穩定和適當的文檔是非常重要的。所有新的 sysfs 376 + 屬性必須在 Documentation/ABI 中有文檔。詳見 Documentation/ABI/README。 377 +
+148
Documentation/translations/zh_TW/filesystems/tmpfs.rst
··· 1 + .. SPDX-License-Identifier: GPL-2.0 2 + 3 + .. include:: ../disclaimer-zh_TW.rst 4 + 5 + :Original: Documentation/filesystems/tmpfs.rst 6 + 7 + Translated by Wang Qing <wangqing@vivo.com> 8 + and Hu Haowen <src.res@email.cn> 9 + 10 + ===== 11 + Tmpfs 12 + ===== 13 + 14 + Tmpfs是一個將所有文件都保存在虛擬內存中的文件系統。 15 + 16 + tmpfs中的所有內容都是臨時的,也就是說沒有任何文件會在硬碟上創建。 17 + 如果卸載tmpfs實例,所有保存在其中的文件都會丟失。 18 + 19 + tmpfs將所有文件保存在內核緩存中,隨著文件內容增長或縮小可以將不需要的 20 + 頁面swap出去。它具有最大限制,可以通過「mount -o remount ...」調整。 21 + 22 + 和ramfs(創建tmpfs的模板)相比,tmpfs包含交換和限制檢查。和tmpfs相似的另 23 + 一個東西是RAM磁碟(/dev/ram*),可以在物理RAM中模擬固定大小的硬碟,並在 24 + 此之上創建一個普通的文件系統。Ramdisks無法swap,因此無法調整它們的大小。 25 + 26 + 由於tmpfs完全保存於頁面緩存和swap中,因此所有tmpfs頁面將在/proc/meminfo 27 + 中顯示爲「Shmem」,而在free(1)中顯示爲「Shared」。請注意,這些計數還包括 28 + 共享內存(shmem,請參閱ipcs(1))。獲得計數的最可靠方法是使用df(1)和du(1)。 29 + 30 + tmpfs具有以下用途: 31 + 32 + 1) 內核總有一個無法看到的內部掛載,用於共享匿名映射和SYSV共享內存。 33 + 34 + 掛載不依賴於CONFIG_TMPFS。如果CONFIG_TMPFS未設置,tmpfs對用戶不可見。 35 + 但是內部機制始終存在。 36 + 37 + 2) glibc 2.2及更高版本期望將tmpfs掛載在/dev/shm上以用於POSIX共享內存 38 + (shm_open,shm_unlink)。添加內容到/etc/fstab應注意如下: 39 + 40 + tmpfs /dev/shm tmpfs defaults 0 0 41 + 42 + 使用時需要記住創建掛載tmpfs的目錄。 43 + 44 + SYSV共享內存無需掛載,內部已默認支持。(在2.3內核版本中,必須掛載 45 + tmpfs的前身(shm fs)才能使用SYSV共享內存) 46 + 47 + 3) 很多人(包括我)都覺的在/tmp和/var/tmp上掛載非常方便,並具有較大的 48 + swap分區。目前循環掛載tmpfs可以正常工作,所以大多數發布都應當可以 49 + 使用mkinitrd通過/tmp訪問/tmp。 50 + 51 + 4) 也許還有更多我不知道的地方:-) 52 + 53 + 54 + tmpfs有三個用於調整大小的掛載選項: 55 + 56 + ========= =========================================================== 57 + size tmpfs實例分配的字節數限制。默認值是不swap時物理RAM的一半。 58 + 如果tmpfs實例過大,機器將死鎖,因爲OOM處理將無法釋放該內存。 59 + nr_blocks 與size相同,但以PAGE_SIZE爲單位。 60 + nr_inodes tmpfs實例的最大inode個數。默認值是物理內存頁數的一半,或者 61 + (有高端內存的機器)低端內存RAM的頁數,二者以較低者為準。 62 + ========= =========================================================== 63 + 64 + 這些參數接受後綴k,m或g表示千,兆和千兆字節,可以在remount時更改。 65 + size參數也接受後綴%用來限制tmpfs實例占用物理RAM的百分比: 66 + 未指定size或nr_blocks時,默認值爲size=50% 67 + 68 + 如果nr_blocks=0(或size=0),block個數將不受限制;如果nr_inodes=0, 69 + inode個數將不受限制。這樣掛載通常是不明智的,因爲它允許任何具有寫權限的 70 + 用戶通過訪問tmpfs耗盡機器上的所有內存;但同時這樣做也會增強在多個CPU的 71 + 場景下的訪問。 72 + 73 + tmpfs具有爲所有文件設置NUMA內存分配策略掛載選項(如果啓用了CONFIG_NUMA), 74 + 可以通過「mount -o remount ...」調整 75 + 76 + ======================== ========================= 77 + mpol=default 採用進程分配策略 78 + (請參閱 set_mempolicy(2)) 79 + mpol=prefer:Node 傾向從給定的節點分配 80 + mpol=bind:NodeList 只允許從指定的鍊表分配 81 + mpol=interleave 傾向於依次從每個節點分配 82 + mpol=interleave:NodeList 依次從每個節點分配 83 + mpol=local 優先本地節點分配內存 84 + ======================== ========================= 85 + 86 + NodeList格式是以逗號分隔的十進位數字表示大小和範圍,最大和最小範圍是用- 87 + 分隔符的十進位數來表示。例如,mpol=bind0-3,5,7,9-15 88 + 89 + 帶有有效NodeList的內存策略將按指定格式保存,在創建文件時使用。當任務在該 90 + 文件系統上創建文件時,會使用到掛載時的內存策略NodeList選項,如果設置的話, 91 + 由調用任務的cpuset[請參見Documentation/admin-guide/cgroup-v1/cpusets.rst] 92 + 以及下面列出的可選標誌約束。如果NodeLists爲設置爲空集,則文件的內存策略將 93 + 恢復爲「默認」策略。 94 + 95 + NUMA內存分配策略有可選標誌,可以用於模式結合。在掛載tmpfs時指定這些可選 96 + 標誌可以在NodeList之前生效。 97 + Documentation/admin-guide/mm/numa_memory_policy.rst列出所有可用的內存 98 + 分配策略模式標誌及其對內存策略。 99 + 100 + :: 101 + 102 + =static 相當於 MPOL_F_STATIC_NODES 103 + =relative 相當於 MPOL_F_RELATIVE_NODES 104 + 105 + 例如,mpol=bind=staticNodeList相當於MPOL_BIND|MPOL_F_STATIC_NODES的分配策略 106 + 107 + 請注意,如果內核不支持NUMA,那麼使用mpol選項掛載tmpfs將會失敗;nodelist指定不 108 + 在線的節點也會失敗。如果您的系統依賴於此,但內核會運行不帶NUMA功能(也許是安全 109 + revocery內核),或者具有較少的節點在線,建議從自動模式中省略mpol選項掛載選項。 110 + 可以在以後通過「mount -o remount,mpol=Policy:NodeList MountPoint」添加到掛載點。 111 + 112 + 要指定初始根目錄,可以使用如下掛載選項: 113 + 114 + ==== ==================== 115 + 模式 權限用八進位數字表示 116 + uid 用戶ID 117 + gid 組ID 118 + ==== ==================== 119 + 120 + 這些選項對remount沒有任何影響。您可以通過chmod(1),chown(1)和chgrp(1)的更改 121 + 已經掛載的參數。 122 + 123 + tmpfs具有選擇32位還是64位inode的掛載選項: 124 + 125 + ======= ============= 126 + inode64 使用64位inode 127 + inode32 使用32位inode 128 + ======= ============= 129 + 130 + 在32位內核上,默認是inode32,掛載時指定inode64會被拒絕。 131 + 在64位內核上,默認配置是CONFIG_TMPFS_INODE64。inode64避免了單個設備上可能有多個 132 + 具有相同inode編號的文件;比如32位應用程式使用glibc如果長期訪問tmpfs,一旦達到33 133 + 位inode編號,就有EOVERFLOW失敗的危險,無法打開大於2GiB的文件,並返回EINVAL。 134 + 135 + 所以'mount -t tmpfs -o size=10G,nr_inodes=10k,mode=700 tmpfs /mytmpfs'將在 136 + /mytmpfs上掛載tmpfs實例,分配只能由root用戶訪問的10GB RAM/SWAP,可以有10240個 137 + inode的實例。 138 + 139 + 140 + :作者: 141 + Christoph Rohland <cr@sap.com>, 1.12.01 142 + :更新: 143 + Hugh Dickins, 4 June 2007 144 + :更新: 145 + KOSAKI Motohiro, 16 Mar 2010 146 + :更新: 147 + Chris Down, 13 July 2020 148 +
+61
Documentation/translations/zh_TW/filesystems/virtiofs.rst
··· 1 + .. SPDX-License-Identifier: GPL-2.0 2 + 3 + .. include:: ../disclaimer-zh_TW.rst 4 + 5 + :Original: :ref:`Documentation/filesystems/virtiofs.rst <virtiofs_index>` 6 + 7 + 譯者 8 + :: 9 + 10 + 中文版維護者: 王文虎 Wang Wenhu <wenhu.wang@vivo.com> 11 + 中文版翻譯者: 王文虎 Wang Wenhu <wenhu.wang@vivo.com> 12 + 中文版校譯者: 王文虎 Wang Wenhu <wenhu.wang@vivo.com> 13 + 中文版校譯者: 王文虎 Wang Wenhu <wenhu.wang@vivo.com> 14 + 繁體中文版校譯者:胡皓文 Hu Haowen <src.res@email.cn> 15 + 16 + =========================================== 17 + virtiofs: virtio-fs 主機<->客機共享文件系統 18 + =========================================== 19 + 20 + - Copyright (C) 2020 Vivo Communication Technology Co. Ltd. 21 + 22 + 介紹 23 + ==== 24 + Linux的virtiofs文件系統實現了一個半虛擬化VIRTIO類型「virtio-fs」設備的驅動,通過該\ 25 + 類型設備實現客機<->主機文件系統共享。它允許客機掛載一個已經導出到主機的目錄。 26 + 27 + 客機通常需要訪問主機或者遠程系統上的文件。使用場景包括:在新客機安裝時讓文件對其\ 28 + 可見;從主機上的根文件系統啓動;對無狀態或臨時客機提供持久存儲和在客機之間共享目錄。 29 + 30 + 儘管在某些任務可能通過使用已有的網絡文件系統完成,但是卻需要非常難以自動化的配置\ 31 + 步驟,且將存儲網絡暴露給客機。而virtio-fs設備通過提供不經過網絡的文件系統訪問文件\ 32 + 的設計方式解決了這些問題。 33 + 34 + 另外,virto-fs設備發揮了主客機共存的優點提高了性能,並且提供了網絡文件系統所不具備 35 + 的一些語義功能。 36 + 37 + 用法 38 + ==== 39 + 以``myfs``標籤將文件系統掛載到``/mnt``: 40 + 41 + .. code-block:: sh 42 + 43 + guest# mount -t virtiofs myfs /mnt 44 + 45 + 請查閱 https://virtio-fs.gitlab.io/ 了解配置QEMU和virtiofsd守護程序的詳細信息。 46 + 47 + 內幕 48 + ==== 49 + 由於virtio-fs設備將FUSE協議用於文件系統請求,因此Linux的virtiofs文件系統與FUSE文\ 50 + 件系統客戶端緊密集成在一起。客機充當FUSE客戶端而主機充當FUSE伺服器,內核與用戶空\ 51 + 間之間的/dev/fuse接口由virtio-fs設備接口代替。 52 + 53 + FUSE請求被置於虛擬隊列中由主機處理。主機填充緩衝區中的響應部分,而客機處理請求的完成部分。 54 + 55 + 將/dev/fuse映射到虛擬隊列需要解決/dev/fuse和虛擬隊列之間語義上的差異。每次讀取\ 56 + /dev/fuse設備時,FUSE客戶端都可以選擇要傳輸的請求,從而可以使某些請求優先於其他\ 57 + 請求。虛擬隊列有其隊列語義,無法更改已入隊請求的順序。在虛擬隊列已滿的情況下尤 58 + 其關鍵,因爲此時不可能加入高優先級的請求。爲了解決此差異,virtio-fs設備採用「hiprio」\ 59 + (高優先級)虛擬隊列,專門用於有別於普通請求的高優先級請求。 60 + 61 +
+2 -1
Documentation/translations/zh_TW/index.rst
··· 91 91 92 92 .. toctree:: 93 93 :maxdepth: 2 94 + 94 95 cpu-freq/index 96 + filesystems/index 95 97 96 98 TODOList: 97 99 ··· 128 126 * security/index 129 127 * sound/index 130 128 * crypto/index 131 - * filesystems/index 132 129 * vm/index 133 130 * bpf/index 134 131 * usb/index