@@ -51,15 +51,27 @@ configfs tree is always there, whether mounted on /config or not.
51
51
An item is created via mkdir(2). The item's attributes will also
52
52
appear at this time. readdir(3) can determine what the attributes are,
53
53
read(2) can query their default values, and write(2) can store new
54
- values. Like sysfs, attributes should be ASCII text files, preferably
55
- with only one value per file. The same efficiency caveats from sysfs
56
- apply. Don't mix more than one attribute in one attribute file.
57
-
58
- Like sysfs, configfs expects write(2) to store the entire buffer at
59
- once. When writing to configfs attributes, userspace processes should
60
- first read the entire file, modify the portions they wish to change, and
61
- then write the entire buffer back. Attribute files have a maximum size
62
- of one page (PAGE_SIZE, 4096 on i386).
54
+ values. Don't mix more than one attribute in one attribute file.
55
+
56
+ There are two types of configfs attributes:
57
+
58
+ * Normal attributes, which similar to sysfs attributes, are small ASCII text
59
+ files, with a maximum size of one page (PAGE_SIZE, 4096 on i386). Preferably
60
+ only one value per file should be used, and the same caveats from sysfs apply.
61
+ Configfs expects write(2) to store the entire buffer at once. When writing to
62
+ normal configfs attributes, userspace processes should first read the entire
63
+ file, modify the portions they wish to change, and then write the entire
64
+ buffer back.
65
+
66
+ * Binary attributes, which are somewhat similar to sysfs binary attributes,
67
+ but with a few slight changes to semantics. The PAGE_SIZE limitation does not
68
+ apply, but the whole binary item must fit in single kernel vmalloc'ed buffer.
69
+ The write(2) calls from user space are buffered, and the attributes'
70
+ write_bin_attribute method will be invoked on the final close, therefore it is
71
+ imperative for user-space to check the return code of close(2) in order to
72
+ verify that the operation finished successfully.
73
+ To avoid a malicious user OOMing the kernel, there's a per-binary attribute
74
+ maximum buffer value.
63
75
64
76
When an item needs to be destroyed, remove it with rmdir(2). An
65
77
item cannot be destroyed if any other item has a link to it (via
@@ -171,6 +183,7 @@ among other things. For that, it needs a type.
171
183
struct configfs_item_operations *ct_item_ops;
172
184
struct configfs_group_operations *ct_group_ops;
173
185
struct configfs_attribute **ct_attrs;
186
+ struct configfs_bin_attribute **ct_bin_attrs;
174
187
};
175
188
176
189
The most basic function of a config_item_type is to define what
@@ -201,6 +214,32 @@ be called whenever userspace asks for a read(2) on the attribute. If an
201
214
attribute is writable and provides a ->store method, that method will be
202
215
be called whenever userspace asks for a write(2) on the attribute.
203
216
217
+ [struct configfs_bin_attribute]
218
+
219
+ struct configfs_attribute {
220
+ struct configfs_attribute cb_attr;
221
+ void *cb_private;
222
+ size_t cb_max_size;
223
+ };
224
+
225
+ The binary attribute is used when the one needs to use binary blob to
226
+ appear as the contents of a file in the item's configfs directory.
227
+ To do so add the binary attribute to the NULL-terminated array
228
+ config_item_type->ct_bin_attrs, and the item appears in configfs, the
229
+ attribute file will appear with the configfs_bin_attribute->cb_attr.ca_name
230
+ filename. configfs_bin_attribute->cb_attr.ca_mode specifies the file
231
+ permissions.
232
+ The cb_private member is provided for use by the driver, while the
233
+ cb_max_size member specifies the maximum amount of vmalloc buffer
234
+ to be used.
235
+
236
+ If binary attribute is readable and the config_item provides a
237
+ ct_item_ops->read_bin_attribute() method, that method will be called
238
+ whenever userspace asks for a read(2) on the attribute. The converse
239
+ will happen for write(2). The reads/writes are bufferred so only a
240
+ single read/write will occur; the attributes' need not concern itself
241
+ with it.
242
+
204
243
[struct config_group]
205
244
206
245
A config_item cannot live in a vacuum. The only way one can be created
0 commit comments