1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
|
Device-mapper to libdevmapper protocol
1) Device mapper device in a POV of LVM it is an Logical Volume.
Logical Volume is virtual block device is made from logical blocks.
These blocks are mapped to real device blocks with algorithm called
target.
Functions available to dm device:
create, remove, list, status of device.
2) device mapper target is function which defines how are Logical blocks
mapped to physical. There are many targets linear, stripe, mirror etc.
Functions available to dm device:
list available targets. They can be added with module in linux.
3) dm table.
Every device-mapper device consists from one or more tables.
Table specifies start, length of logical blocks and target which is used
to map them to physical blocks.
{start} {length} {target} | {device} {target parameters}
after | are target specific parameters listed.
Functions available to dm device:
load, unload, table_status.
List of available ioct calls
DM_VERSION
DM_REMOVE_ALL
DM_LIST_DEVICES
DM_DEV_CREATE
DM_DEV_REMOVE
DM_DEV_RENAME
DM_DEV_SUSPEND
DM_DEV_STATUS
DM_DEV_WAIT
DM_TABLE_LOAD
DM_TABLE_CLEAR
DM_TABLE_DEPS
DM_TABLE_STATUS
DM_LIST_VERSIONS
DM_TARGET_MSG
DM_DEV_SET_GEOMETRY
1) DM_VERSION
in: struct dm-ioctl
out: struct dm-ioctl
Function:
sends libdevmapper ioctl protocol version to kernel and ask for kernel version.
If major and minor numbers are good we can continue.
2) DM_REMOVE_ALL
in: none
out: none
Function:
This ioctl will remove all DM devices/tables from DM driver.
3) DM_LIST_DEVICES
in: none
out: List of structures describing all devices created in driver.
Function:
List all devices created in driver. (linux use struct dm_name_list)
Implementation:
Kernel driver will place list of struct dm_name_list behind
struct dm_ioctl in userspace. Kernel driver will list through
the all devices and copyout info about them.
4) DM_DEV_CREATE
in: struct dm-ioctl(name/uuid)
out: none
Function:
Create device in dm driver, with specified name/uuid(uuid is preferred).
(linux use struct dm_name_list)
5) DM_DEV_REMOVE
in: struct dm-ioctl(name/uuid)
out: none
Function:
Remove device from dm driver list, also remove device tables.
6) DM_DEV_RENAME
in: struct dm-ioctl(name/uuid) and string found after dm-ioctl struct in buffer
out: none
Function:
Rename device from name to string.
Implementation:
Kernel driver will find device with name from struct dm_ioctl-name/uuid.
Change name of selected device to string found behind struct dm_ioctl header
in userspace buffer.
7) DM_DEV_SUSPEND
in: dm-ioctl(name/uuid)
out: none
Function:
Suspend all io's on device, after this ioctl. Already started io's will be done.
Newer can't be started.
8) DM_DEV_STATUS
in: dm-ioctl(name/uuid)
out: dm-ioctl (minor,open_count,target_count)
Function:
Return status info about selected device
Implementation:
Kernel driver will find device with name from struct dm_ioctl-name/uuid.
Change values minor,open_count,target_count in dm_ioctl struct for
selected device.
9) DM_DEV_WAIT
in: dm-ioctl(name/uuid)
out: none
Function:
Wait for device event to happen.
10) DM_TABLE_LOAD
in: dm-ioctl(name/uuid),table specification
out: none
Function:
Load table to selected device. Table is loaded to unused slot and than switched.
(linux use struct dm_target_spec)
Implementation:
Kernel driver will find device with name from struct dm_ioctl-name/uuid.
Table is added to the inactive slot. Every device can have more than one
table loaded. Tables are stored in SLIST. This ioctl also open physical
device specified in table and add it to dm_device specific pdev list.
11) DM_TABLE_CLEAR
in: dm-ioctl(name/uuid)
out: none
Function:
Remove table from unused slot.
12) DM_TABLE_DEPS
in: dm-ioctl(name/uuid)
out: list of dependencies devices
Function:
Return set of device dependencies e.g. mirror device for mirror target etc..
13) DM_TABLE_STATUS
in: dm-ioctl(name/uuid)
out: list of used tables from selected devices (linux use struct dm_target_spec)
Function:
List all tables in active slot in device with name name/uuid.
Implementation:
Kernel driver will find device with name from struct dm_ioctl-name/uuid.
DM driver will copyout dm_target_spec structures behind struct dm_ioctl.
14) DM_LIST_VERSIONS
in: none
out: list of all targets in device-mapper driver (linux use struct dm_target_versions)
Function:
List all available targets to libdevmapper.
Implementation:
Kernel driver will copy out known target versions.
15) DM_TARGET_MSG
in: message to driver (linux use struct dm_target_msg)
out: none
Function:
Send message to kernel driver target.
16) DM_DEV_SET_GEOMETRY
Function:
Set geometry of device-mapper driver.
NetBSD device-mapper driver implementation
device-mapper devices -> devs dm_dev.c
This entity is created with DM_DEV_CREATE ioctl, and stores info
about every device in device mapper driver. It has two slots for
active and inactive table, list of active physical devices added
to this device and list of upcalled devices (for targets which use
more than one physical device e.g. mirror, snapshot etc..).
device-mapper physical devices -> pdevs dm_pdev.c
This structure contains opened device VNODES. Because I physical
device can be found in more than one table loaded to different
dm devices. When device is destroyed I decrement all reference
counters for all added pdevs (I remove pdevs with ref_cnt == 0).
device-mapper tables -> table dm_table.c, dm_ioctl.c
Table describe how is dm device made. What blocks are mapped with
what target. In our implementation every table contains pointer to
target specific config data. These config_data are allocated in
DM_TABLE_LOAD function with target_init routine. Every table
contains pointer to used target.
device-mapper targets -> target dm_target.c
Target describes mapping of logical blocks to physical. It has
function pointers to function which does init, strategy, destroy,
upcall functions.
P.S I want to thank reinod@ for great help and guidance :).
Design of new device-mapper ioctl interface
Basic architecture of device-mapper -> libdevmapper ioctl interface is this.
Libdevmapper allocate buffer with size of data_size. At the start of this buffer
dm-ioctl structure is placed. any additional information from/to kernel are placed
behind end (start of data part is pointed with data_start var.) of dm-ioctl struct.
Kernel driver then after ioctl call have to copyin data from userspace to kernel.
When kernel driver want to send data back to user space library it must copyout
data from kernel.
1) In Linux device-mapper ioctl interface implementation there are these ioctls.
DM_VERSION *
DM_REMOVE_ALL
DM_LIST_DEVICES *
DM_DEV_CREATE *
DM_DEV_REMOVE *
DM_DEV_RENAME *
DM_DEV_SUSPEND
DM_DEV_STATUS *
DM_DEV_WAIT
DM_TABLE_LOAD *
DM_TABLE_CLEAR *
DM_TABLE_DEPS
DM_TABLE_STATUS *
DM_LIST_VERSIONS *
DM_TARGET_MSG
DM_DEV_SET_GEOMETRY
* means implemented in current version of NetBSD device-mapper.
1a) struct dm_ioctl based ioctl calls
These ioctl calls communicate only with basic dm_ioctl structure.
DM_VERSION
DM_DEV_STATUS
DM_DEV_CREATE
Protocol structure:
struct dm_ioctl {
uint32_t version[3]; /* device-mapper kernel/userspace version */
uint32_t data_size; /* total size of data passed in
* including this struct */
uint32_t data_start; /* offset to start of data
* relative to start of this struct */
uint32_t target_count; /* in/out */ /* This should be set when DM_TABLE_STATUS is called */
int32_t open_count; /* device open count */
uint32_t flags; /* information flags */
uint32_t event_nr; /* event counters not implemented */
uint32_t padding;
uint64_t dev; /* dev_t */
char name[DM_NAME_LEN]; /* device name */
char uuid[DM_UUID_LEN]; /* unique identifier for
* the block device */
void *user_space_addr; /*this is needed for netbsd
because they differently
implement ioctl syscall*/
};
As SOC task I want to replace this structure with proplib dict. Proplib dict
basic structure should be:
Note: I don't need data_star, data_size and use_space_addr. They are needed
for current implementation.
<dict>
<key>version</key>
<string>...</string>
<key>target_count</key>
<integer></integer>
<key>open_count</key>
<integer></integer>
<key>flags</key>
<integer></integer>
<key>event_nr</key>
<integer></integer>
<key>dev</key>
<integer></integer>
<key>name</key>
<string>...</string>
<key>uuid</key>
<string>...</string>
<dict>
<!-- ioctl specific data -->
</dict>
</dict>
1b) DM_LIST_VERSIONS ioctl
This ioctl is used to get list of supported targets from kernel. Target
define mapping of Logical blocks to physical blocks on real device.
There are linear, zero, error, mirror, snapshot, multipath etc... targets.
For every target kernel driver should copyout this structure to userspace.
Protocol structure:
struct dm_target_versions {
uint32_t next;
uint32_t version[3];
char name[0];
};
Because I need more than one dm_target_version I will need one major proplib
dictionary to store children dictionaries with target data.
<dict>
<dict ID="id">
<key>version</key>
<string>...</string>
<key>name</key>
<string>...</string>
</dict>
</dict>
2a) DM_LIST_DEVICES
This ioctl is used to list all devices defined in kernel driver.
Protocol structure:
struct dm_name_list {
uint64_t dev;
uint32_t next; /* offset to the next record from
the _start_ of this */
char name[0];
};
Again because I can have more than one device in kernel driver I need one parent
dictionary and more children dictionaries.
<dict>
<dict ID="id">
<key>dev</key>
<integer>...</integer>
<key>name</key>
<string>...</string>
</dict>
</dict>
2b) DM_DEV_RENAME
This ioctl is called when libdevmapper want to rename device-mapper device.
Libdevmapper library appends null terminated string to dm_ioctl struct in
userspace..
<dict>
<key>name</key>
<string>...</string>
</dict>
2c) DM_DEV_CREATE, DM_DEV_REMOVE, DM_DEV_STATUS
Modify only dm_ioctl structure so I don't need to specify new structures.
3a) DM_TABLE_LOAD, DM_TABLE_STATUS
DM_TABLE_LOAD ioctl loads table to device. DM_TABLE_STATUS send info about
every table for selected device to userspace. Table is different for every
target basic table structure is this
{start} {length} {target} {additional information}
e.g.
0 100 zero
0 100 linear /dev/wdba 384
Protocol structure:
struct dm_target_spec {
uint64_t sector_start;
uint64_t length;
int32_t status; /* used when reading from kernel only */
uint32_t next;
char target_type[DM_MAX_TYPE_NAME];
/*
* Parameter string starts immediately after this object.
* Be careful to add padding after string to ensure correct
* alignment of subsequent dm_target_spec.
*/
};
<dict>
<key>sector_start</key>
<integer>...</integer>
<key>length</key>
<integer>...</integer>
<key>target_type</key>
<string>...</string>
<key>additional info</key>
<string>...</string>
</dict>
|