1nbdkit-plugin(3) NBDKIT nbdkit-plugin(3)
2
6 nbdkit-plugin - how to write nbdkit plugins
7
9 #define NBDKIT_API_VERSION 2
10 #include <nbdkit-plugin.h>
12 #define THREAD_MODEL NBDKIT_THREAD_MODEL_SERIALIZE_ALL_REQUESTS
14 static void *
16 myplugin_open (void)
17 {
18 /* create a handle ... */
19 return handle;
20 }
21 static struct nbdkit_plugin plugin = {
23 .name = "myplugin",
24 .open = myplugin_open,
25 .get_size = myplugin_get_size,
26 .pread = myplugin_pread,
27 .pwrite = myplugin_pwrite,
28 /* etc */
29 };
30 NBDKIT_REGISTER_PLUGIN(plugin)
32 When this has been compiled to a shared library, do:
34 nbdkit [--args ...] ./myplugin.so [key=value ...]
36 When debugging, use the -fv options:
38 nbdkit -fv ./myplugin.so [key=value ...]
40
42 An nbdkit plugin is a new source device which can be served using the
43 Network Block Device (NBD) protocol. This manual page describes how to
44 create an nbdkit plugin in C.
45 To see example plugins:
47 https://github.com/libguestfs/nbdkit/tree/master/plugins
48 Plugins written in C have an ABI guarantee: a plugin compiled against
50 an older version of nbdkit will still work correctly when loaded with a
51 newer nbdkit. We also try (but cannot guarantee) to support plugins
52 compiled against a newer version of nbdkit when loaded with an older
53 nbdkit, although the plugin may have reduced functionality if it
54 depends on features only provided by newer nbdkit.
55 For plugins written in C, we also provide an API guarantee: a plugin
57 written against an older header will still compile unmodified with a
58 newer nbdkit.
59 The API guarantee does not always apply to plugins written in other
61 (non-C) languages which may have to adapt to changes when recompiled
62 against a newer nbdkit.
63 To write plugins in other languages, see: nbdkit-lua-plugin(3),
65 nbdkit-ocaml-plugin(3), nbdkit-perl-plugin(3), nbdkit-python-plugin(3),
66 nbdkit-ruby-plugin(3), nbdkit-rust-plugin(3), nbdkit-sh-plugin(3),
67 nbdkit-tcl-plugin(3) .
68
70 Plugins must choose which API version they want to use, by defining
71 NBDKIT_API_VERSION to a positive integer prior to including
72 "nbdkit-plugin.h" (or any other nbdkit header). The default version is
73 1 for backwards-compatibility with nbdkit v1.1.26 and earlier; however,
74 it is recommended that new plugins be written to the maximum version
75 (currently 2) as it enables more features and better interaction with
76 nbdkit filters. Therefore, the rest of this document only covers the
77 version 2 interface. A newer nbdkit will always support plugins
78 written in C which were compiled against any prior API version.
79
81 All plugins should start by including this header file, after
82 optionally choosing an API version.
83
85 All plugins must define a thread model. See "THREADS" below for
86 details. It is generally safe to use:
87 #define THREAD_MODEL NBDKIT_THREAD_MODEL_SERIALIZE_ALL_REQUESTS
89
91 All plugins must define and register one "struct nbdkit_plugin", which
92 contains the name of the plugin and pointers to callback functions.
93 static struct nbdkit_plugin plugin = {
95 .name = "myplugin",
96 .longname = "My Plugin",
97 .description = "This is my great plugin for nbdkit",
98 .open = myplugin_open,
99 .get_size = myplugin_get_size,
100 .pread = myplugin_pread,
101 .pwrite = myplugin_pwrite,
102 /* etc */
103 };
104 NBDKIT_REGISTER_PLUGIN(plugin)
106 The ".name" field is the name of the plugin.
108 The callbacks are described below (see "CALLBACKS"). Only ".name",
110 ".open", ".get_size" and ".pread" are required. All other callbacks
111 can be omitted. However almost all plugins should have a ".close"
112 callback. Most real-world plugins will also want to declare some of
113 the other callbacks.
114 The nbdkit server calls the callbacks in the following order over the
116 lifetime of the plugin:
117 ".load"
119 is called once just after the plugin is loaded into memory.
120 ".config" and ".config_complete"
122 ".config" is called zero or more times during command line parsing.
123 ".config_complete" is called once after all configuration
124 information has been passed to the plugin (but not during "nbdkit
125 --dump-plugin").
126 Both are called after loading the plugin but before any connections
128 are accepted.
129 ".thread_model"
131 In normal operation, ".thread_model" is called once after
132 ".config_complete" has validated all configuration information, and
133 before any connections are accepted. However, during "nbdkit
134 --dump-plugin", it is called after any ".config" calls but without
135 ".config_complete" (so a plugin which determines the results from a
136 script must be prepared for a missing script).
137 ".open"
139 A new client has connected and finished the NBD handshake. TLS
140 negotiation (if required) has been completed successfully.
141 ".can_write", ".get_size" and other option negotiation callbacks
143 These are called during option negotiation with the client, but
144 before any data is served. These callbacks may return different
145 values across different ".open" calls, but within a single
146 connection, they are called at most once and cached by nbdkit for
147 that connection.
148 ".pread", ".pwrite" and other data serving callbacks
150 After option negotiation has finished, these may be called to serve
151 data. Depending on the thread model chosen, they might be called
152 in parallel from multiple threads. The data serving callbacks
153 include a flags argument; the results of the negotiation callbacks
154 influence whether particular flags will ever be passed to a data
155 callback.
156 ".close"
158 The client has disconnected.
159 ".open" ... ".close"
161 The sequence ".open" ... ".close" can be called repeatedly over the
162 lifetime of the plugin, and can be called in parallel (depending on
163 the thread model).
164 ".unload"
166 is called once just before the plugin is unloaded from memory.
167
169 The following flags are defined by nbdkit, and used in various data
170 serving callbacks as follows:
171 "NBDKIT_FLAG_MAY_TRIM"
173 This flag is used by the ".zero" callback; there is no way to
174 disable this flag, although a plugin that does not support trims as
175 a way to write zeroes may ignore the flag without violating
176 expected semantics.
177 "NBDKIT_FLAG_FUA"
179 This flag represents Forced Unit Access semantics. It is used by
180 the ".pwrite", ".zero", and ".trim" callbacks to indicate that the
181 plugin must not return a result until the action has landed in
182 persistent storage. This flag will not be sent to the plugin
183 unless ".can_fua" is provided and returns "NBDKIT_FUA_NATIVE".
184 The following defines are valid as successful return values for
186 ".can_fua":
187 "NBDKIT_FUA_NONE"
189 Forced Unit Access is not supported; the client must manually
190 request a flush after writes have completed. The "NBDKIT_FLAG_FUA"
191 flag will not be passed to the plugin's write callbacks.
192 "NBDKIT_FUA_EMULATE"
194 The client may request Forced Unit Access, but it is implemented by
195 emulation, where nbdkit calls ".flush" after a write operation;
196 this is semantically correct, but may hurt performance as it tends
197 to flush more data than just what the client requested. The
198 "NBDKIT_FLAG_FUA" flag will not be passed to the plugin's write
199 callbacks.
200 "NBDKIT_FUA_NATIVE"
202 The client may request Forced Unit Access, which results in the
203 "NBDKIT_FLAG_FUA" flag being passed to the plugin's write callbacks
204 (".pwrite", ".trim", and ".zero"). When the flag is set, these
205 callbacks must not return success until the client's request has
206 landed in persistent storage.
207 The following defines are valid as successful return values for
209 ".can_cache":
210 "NBDKIT_CACHE_NONE"
212 The server does not advertise caching support, and rejects any
213 client-requested caching. Any ".cache" callback is ignored.
214 "NBDKIT_CACHE_EMULATE"
216 The nbdkit server advertises cache support to the client, where the
217 client may request that the server cache a region of the export to
218 potentially speed up future read and/or write operations on that
219 region. The nbdkit server implements the caching by calling
220 ".pread" and ignoring the results. This option exists to ease the
221 implementation of a common form of caching; any ".cache" callback
222 is ignored.
223 "NBDKIT_CACHE_NATIVE"
225 The nbdkit server advertises cache support to the client, where the
226 client may request that the server cache a region of the export to
227 potentially speed up future read and/or write operations on that
228 region. The nbdkit server calls the ".cache" callback to perform
229 the caching; if that callback is missing, the client's cache
230 request succeeds without doing anything.
231
233 If there is an error in the plugin, the plugin should call
234 "nbdkit_error" to report an error message; additionally, if the
235 callback is involved in serving data, the plugin should call
236 "nbdkit_set_error" to influence the error code that will be sent to the
237 client. These two functions can be called in either order. Then, the
238 callback should return the appropriate error indication, eg. "NULL" or
239 "-1".
240 If the call to "nbdkit_set_error" is omitted while serving data, then
242 the global variable "errno" may be used. For plugins which have
243 ".errno_is_preserved != 0" the core code will use "errno". In plugins
244 written in non-C languages, we usually cannot trust that "errno" will
245 not be overwritten when returning from that language to C. In that
246 case, either the plugin must call "nbdkit_set_error" or hard-coded
247 "EIO" is used.
248 "nbdkit_error" has the following prototype and works like printf(3):
250 void nbdkit_error (const char *fs, ...);
252 void nbdkit_verror (const char *fs, va_list args);
253 For convenience, "nbdkit_error" preserves the value of "errno", and
255 also supports the glibc extension of a single %m in a format string
256 expanding to "strerror(errno)", even on platforms that don't support
257 that natively.
258 "nbdkit_set_error" can be called at any time, but only has an impact
260 during callbacks for serving data, and only when the callback returns
261 an indication of failure. It has the following prototype:
262 void nbdkit_set_error (int err);
264
266 ".name"
267 const char *name;
268 This field (a string) is required, and must contain only ASCII
270 alphanumeric characters and be unique amongst all plugins.
271 ".version"
273 const char *version;
274 Plugins may optionally set a version string which is displayed in help
276 and debugging output.
277 ".longname"
279 const char *longname;
280 An optional free text name of the plugin. This field is used in error
282 messages.
283 ".description"
285 const char *description;
286 An optional multi-line description of the plugin.
288 ".load"
290 void load (void);
291 This is called once just after the plugin is loaded into memory. You
293 can use this to perform any global initialization needed by the plugin.
294 ".unload"
296 void unload (void);
297 This may be called once just before the plugin is unloaded from memory.
299 Note that it's not guaranteed that ".unload" will always be called (eg.
300 the server might be killed or segfault), so you should try to make the
301 plugin as robust as possible by not requiring cleanup. See also
302 "SHUTDOWN" below.
303 ".dump_plugin"
305 void dump_plugin (void);
306 This optional callback is called when the "nbdkit plugin --dump-plugin"
308 command is used. It should print any additional informative
309 "key=value" fields to stdout as needed. Prefixing the keys with the
310 name of the plugin will avoid conflicts.
311 ".config"
313 int config (const char *key, const char *value);
314 On the nbdkit command line, after the plugin filename, come an optional
316 list of "key=value" arguments. These are passed to the plugin through
317 this callback when the plugin is first loaded and before any
318 connections are accepted.
319 This callback may be called zero or more times.
321 Both "key" and "value" parameters will be non-NULL. The strings are
323 owned by nbdkit but will remain valid for the lifetime of the plugin,
324 so the plugin does not need to copy them.
325 The key will be a non-empty string beginning with an ASCII alphabetic
327 character ("A-Z" "a-z"). The rest of the key must contain only ASCII
328 alphanumeric plus period, underscore or dash characters ("A-Z" "a-z"
329 "0-9" "." "_" "-"). The value may be an arbitrary string, including an
330 empty string.
331 The names of "key"s accepted by plugins is up to the plugin, but you
333 should probably look at other plugins and follow the same conventions.
334 If the value is a relative path, then note that the server changes
336 directory when it starts up. See "FILENAMES AND PATHS" above.
337 If the ".config" callback is not provided by the plugin, and the user
339 tries to specify any "key=value" arguments, then nbdkit will exit with
340 an error.
341 If there is an error, ".config" should call "nbdkit_error" with an
343 error message and return "-1".
344 ".magic_config_key"
346 const char *magic_config_key;
347 This optional string can be used to set a "magic" key used when parsing
349 plugin parameters. It affects how "bare parameters" (those which do
350 not contain an "=" character) are parsed on the command line.
351 If "magic_config_key != NULL" then any bare parameters are passed to
353 the ".config" method as: "config (magic_config_key, argv[i]);".
354 If "magic_config_key" is not set then we behave as in nbdkit < 1.7: If
356 the first parameter on the command line is bare then it is passed to
357 the ".config" method as: "config ("script", value);". Any other bare
358 parameters give errors.
359 ".config_complete"
361 int config_complete (void);
362 This optional callback is called after all the configuration has been
364 passed to the plugin. It is a good place to do checks, for example
365 that the user has passed the required parameters to the plugin.
366 If there is an error, ".config_complete" should call "nbdkit_error"
368 with an error message and return "-1".
369 ".config_help"
371 const char *config_help;
372 This optional multi-line help message should summarize any "key=value"
374 parameters that it takes. It does not need to repeat what already
375 appears in ".description".
376 If the plugin doesn't take any config parameters you should probably
378 omit this.
379 ".thread_model"
381 int thread_model (void)
382 This optional callback is called after all the configuration has been
384 passed to the plugin. It can be used to force a stricter thread model
385 based on configuration, compared to "THREAD_MODEL". See "THREADS"
386 below for details. Attempts to request a looser (more parallel) model
387 are silently ignored.
388 If there is an error, ".thread_model" should call "nbdkit_error" with
390 an error message and return "-1".
391 ".open"
393 void *open (int readonly);
394 This is called when a new client connects to the nbdkit server. The
396 callback should allocate a handle and return it. This handle is passed
397 back to other callbacks and could be freed in the ".close" callback.
398 Note that the handle is completely opaque to nbdkit, but it must not be
400 NULL. If you don't need to use a handle, return
401 "NBDKIT_HANDLE_NOT_NEEDED" which is a static non-NULL pointer.
402 The "readonly" flag informs the plugin that the server was started with
404 the -r flag on the command line which forces connections to be read-
405 only. Note that the plugin may additionally force the connection to be
406 readonly (even if this flag is false) by returning false from the
407 ".can_write" callback. So if your plugin can only serve read-only, you
408 can ignore this parameter.
409 This callback is called after the NBD handshake has completed, which
411 includes TLS authentication (if required).
412 If there is an error, ".open" should call "nbdkit_error" with an error
414 message and return "NULL".
415 ".close"
417 void close (void *handle);
418 This is called when the client closes the connection. It should clean
420 up any per-connection resources.
421 Note there is no way in the NBD protocol to communicate close errors
423 back to the client, for example if your plugin calls close(2) and you
424 are checking for errors (as you should do). Therefore the best you can
425 do is to log the error on the server. Well-behaved NBD clients should
426 try to flush the connection before it is closed and check for errors,
427 but obviously this is outside the scope of nbdkit.
428 ".get_size"
430 int64_t get_size (void *handle);
431 This is called during the option negotiation phase of the protocol to
433 get the size (in bytes) of the block device being exported.
434 The returned size must be ≥ 0. If there is an error, ".get_size"
436 should call "nbdkit_error" with an error message and return "-1".
437 ".can_write"
439 int can_write (void *handle);
440 This is called during the option negotiation phase to find out if the
442 handle supports writes.
443 If there is an error, ".can_write" should call "nbdkit_error" with an
445 error message and return "-1".
446 This callback is not required. If omitted, then we return true iff a
448 ".pwrite" callback has been defined.
449 ".can_flush"
451 int can_flush (void *handle);
452 This is called during the option negotiation phase to find out if the
454 handle supports the flush-to-disk operation.
455 If there is an error, ".can_flush" should call "nbdkit_error" with an
457 error message and return "-1".
458 This callback is not required. If omitted, then we return true iff a
460 ".flush" callback has been defined.
461 ".is_rotational"
463 int is_rotational (void *handle);
464 This is called during the option negotiation phase to find out if the
466 backing disk is a rotational medium (like a traditional hard disk) or
467 not (like an SSD). If true, this may cause the client to reorder
468 requests to make them more efficient for a slow rotating disk.
469 If there is an error, ".is_rotational" should call "nbdkit_error" with
471 an error message and return "-1".
472 This callback is not required. If omitted, then we return false.
474 ".can_trim"
476 int can_trim (void *handle);
477 This is called during the option negotiation phase to find out if the
479 plugin supports the trim/discard operation for punching holes in the
480 backing storage.
481 If there is an error, ".can_trim" should call "nbdkit_error" with an
483 error message and return "-1".
484 This callback is not required. If omitted, then we return true iff a
486 ".trim" callback has been defined.
487 ".can_zero"
489 int can_zero (void *handle);
490 This is called during the option negotiation phase to find out if the
492 plugin wants the ".zero" callback to be utilized. Support for writing
493 zeroes is still advertised to the client (unless the
494 nbdkit-nozero-filter(1) is also used), so returning false merely serves
495 as a way to avoid complicating the ".zero" callback to have to fail
496 with "ENOTSUP" or "EOPNOTSUPP" on the connections where it will never
497 be more efficient than using ".pwrite" up front.
498 If there is an error, ".can_zero" should call "nbdkit_error" with an
500 error message and return "-1".
501 This callback is not required. If omitted, then for a normal zero
503 request, nbdkit always tries ".zero" first if it is present, and
504 gracefully falls back to ".pwrite" if ".zero" was absent or failed with
505 "ENOTSUP" or "EOPNOTSUPP".
506 ".can_fast_zero"
508 int can_fast_zero (void *handle);
509 This is called during the option negotiation phase to find out if the
511 plugin wants to advertise support for fast zero requests. If this
512 support is not advertised, a client cannot attempt fast zero requests,
513 and has no way to tell if writing zeroes offers any speedups compared
514 to using ".pwrite" (other than compressed network traffic). If support
515 is advertised, then ".zero" will have "NBDKIT_FLAG_FAST_ZERO" set when
516 the client has requested a fast zero, in which case the plugin must
517 fail with "ENOTSUP" or "EOPNOTSUPP" up front if the request would not
518 offer any benefits over ".pwrite". Advertising support for fast zero
519 requests does not require that writing zeroes be fast, only that the
520 result (whether success or failure) is fast, so this should be
521 advertised when feasible.
522 If there is an error, ".can_fast_zero" should call "nbdkit_error" with
524 an error message and return "-1".
525 This callback is not required. If omitted, then nbdkit returns true if
527 ".zero" is absent or ".can_zero" returns false (in those cases, nbdkit
528 fails all fast zero requests, as its fallback to ".pwrite" is not
529 inherently faster), otherwise false (since it cannot be determined in
530 advance if the plugin's ".zero" will properly honor the semantics of
531 "NBDKIT_FLAG_FAST_ZERO").
532 ".can_extents"
534 int can_extents (void *handle);
535 This is called during the option negotiation phase to find out if the
537 plugin supports detecting allocated (non-sparse) regions of the disk
538 with the ".extents" callback.
539 If there is an error, ".can_extents" should call "nbdkit_error" with an
541 error message and return "-1".
542 This callback is not required. If omitted, then we return true iff a
544 ".extents" callback has been defined.
545 ".can_fua"
547 int can_fua (void *handle);
548 This is called during the option negotiation phase to find out if the
550 plugin supports the Forced Unit Access (FUA) flag on write, zero, and
551 trim requests. If this returns "NBDKIT_FUA_NONE", FUA support is not
552 advertised to the client; if this returns "NBDKIT_FUA_EMULATE", the
553 ".flush" callback must work (even if ".can_flush" returns false), and
554 FUA support is emulated by calling ".flush" after any write operation;
555 if this returns "NBDKIT_FUA_NATIVE", then the ".pwrite", ".zero", and
556 ".trim" callbacks (if implemented) must handle the flag
557 "NBDKIT_FLAG_FUA", by not returning until that action has landed in
558 persistent storage.
559 If there is an error, ".can_fua" should call "nbdkit_error" with an
561 error message and return "-1".
562 This callback is not required unless a plugin wants to specifically
564 handle FUA requests. If omitted, nbdkit checks whether ".flush"
565 exists, and behaves as if this function returns "NBDKIT_FUA_NONE" or
566 "NBDKIT_FUA_EMULATE" as appropriate.
567 ".can_multi_conn"
569 int can_multi_conn (void *handle);
570 This is called during the option negotiation phase to find out if the
572 plugin is prepared to handle multiple connections from a single client.
573 If the plugin sets this to true then a client may try to open multiple
574 connections to the nbdkit server and spread requests across all
575 connections to maximize parallelism. If the plugin sets it to false
576 (which is the default) then well-behaved clients should only open a
577 single connection, although we cannot control what clients do in
578 practice.
579 Specifically it means that either the plugin does not cache requests at
581 all. Or if it does cache them then the effects of a ".flush" request
582 or setting "NBDKIT_FLAG_FUA" on a request must be visible across all
583 connections to the plugin before the plugin replies to that request.
584 Properly working clients should send the same export name for each of
586 these connections.
587 If you use Linux nbd-client(8) option -C num with num > 1 then Linux
589 checks this flag and will refuse to connect if ".can_multi_conn" is
590 false.
591 If there is an error, ".can_multi_conn" should call "nbdkit_error" with
593 an error message and return "-1".
594 This callback is not required. If omitted, then we return false.
596 ".can_cache"
598 int can_cache (void *handle);
599 This is called during the option negotiation phase to find out if the
601 plugin supports a cache operation. The nature of the caching is
602 unspecified (including whether there are limits on how much can be
603 cached at once, and whether writes to a cached region have write-
604 through or write-back semantics), but the command exists to let clients
605 issue a hint to the server that they will be accessing that region of
606 the export.
607 If this returns "NBDKIT_CACHE_NONE", cache support is not advertised to
609 the client; if this returns "NBDKIT_CACHE_EMULATE", caching is emulated
610 by the server calling ".pread" and ignoring the results; if this
611 returns "NBDKIT_CACHE_NATIVE", then the ".cache" callback will be used.
612 If there is an error, ".can_cache" should call "nbdkit_error" with an
613 error message and return "-1".
614 This callback is not required. If omitted, then we return
616 "NBDKIT_CACHE_NONE" if the ".cache" callback is missing, or
617 "NBDKIT_CACHE_NATIVE" if it is defined.
618 ".pread"
620 int pread (void *handle, void *buf, uint32_t count, uint64_t offset,
621 uint32_t flags);
622 During the data serving phase, nbdkit calls this callback to read data
624 from the backing store. "count" bytes starting at "offset" in the
625 backing store should be read and copied into "buf". nbdkit takes care
626 of all bounds- and sanity-checking, so the plugin does not need to
627 worry about that.
628 The parameter "flags" exists in case of future NBD protocol extensions;
630 at this time, it will be 0 on input.
631 The callback must read the whole "count" bytes if it can. The NBD
633 protocol doesn't allow partial reads (instead, these would be errors).
634 If the whole "count" bytes was read, the callback should return 0 to
635 indicate there was no error.
636 If there is an error (including a short read which couldn't be
638 recovered from), ".pread" should call "nbdkit_error" with an error
639 message, and "nbdkit_set_error" to record an appropriate error (unless
640 "errno" is sufficient), then return "-1".
641 ".pwrite"
643 int pwrite (void *handle, const void *buf, uint32_t count, uint64_t offset,
644 uint32_t flags);
645 During the data serving phase, nbdkit calls this callback to write data
647 to the backing store. "count" bytes starting at "offset" in the
648 backing store should be written using the data in "buf". nbdkit takes
649 care of all bounds- and sanity-checking, so the plugin does not need to
650 worry about that.
651 This function will not be called if ".can_write" returned false. The
653 parameter "flags" may include "NBDKIT_FLAG_FUA" on input based on the
654 result of ".can_fua".
655 The callback must write the whole "count" bytes if it can. The NBD
657 protocol doesn't allow partial writes (instead, these would be errors).
658 If the whole "count" bytes was written successfully, the callback
659 should return 0 to indicate there was no error.
660 If there is an error (including a short write which couldn't be
662 recovered from), ".pwrite" should call "nbdkit_error" with an error
663 message, and "nbdkit_set_error" to record an appropriate error (unless
664 "errno" is sufficient), then return "-1".
665 ".flush"
667 int flush (void *handle, uint32_t flags);
668 During the data serving phase, this callback is used to fdatasync(2)
670 the backing store, ie. to ensure it has been completely written to a
671 permanent medium. If that is not possible then you can omit this
672 callback.
673 This function will not be called directly by the client if ".can_flush"
675 returned false; however, it may still be called by nbdkit if ".can_fua"
676 returned "NBDKIT_FUA_EMULATE". The parameter "flags" exists in case of
677 future NBD protocol extensions; at this time, it will be 0 on input.
678 If there is an error, ".flush" should call "nbdkit_error" with an error
680 message, and "nbdkit_set_error" to record an appropriate error (unless
681 "errno" is sufficient), then return "-1".
682 ".trim"
684 int trim (void *handle, uint32_t count, uint64_t offset, uint32_t flags);
685 During the data serving phase, this callback is used to "punch holes"
687 in the backing store. If that is not possible then you can omit this
688 callback.
689 This function will not be called if ".can_trim" returned false. The
691 parameter "flags" may include "NBDKIT_FLAG_FUA" on input based on the
692 result of ".can_fua".
693 If there is an error, ".trim" should call "nbdkit_error" with an error
695 message, and "nbdkit_set_error" to record an appropriate error (unless
696 "errno" is sufficient), then return "-1".
697 ".zero"
699 int zero (void *handle, uint32_t count, uint64_t offset, uint32_t flags);
700 During the data serving phase, this callback is used to write "count"
702 bytes of zeroes at "offset" in the backing store.
703 This function will not be called if ".can_zero" returned false. On
705 input, the parameter "flags" may include "NBDKIT_FLAG_MAY_TRIM"
706 unconditionally, "NBDKIT_FLAG_FUA" based on the result of ".can_fua",
707 and "NBDKIT_FLAG_FAST_ZERO" based on the result of ".can_fast_zero".
708 If "NBDKIT_FLAG_MAY_TRIM" is requested, the operation can punch a hole
710 instead of writing actual zero bytes, but only if subsequent reads from
711 the hole read as zeroes.
712 If "NBDKIT_FLAG_FAST_ZERO" is requested, the plugin must decide up
714 front if the implementation is likely to be faster than a corresponding
715 ".pwrite"; if not, then it must immediately fail with "ENOTSUP" or
716 "EOPNOTSUPP" (whether by "nbdkit_set_error" or "errno") and preferably
717 without modifying the exported image. It is acceptable to always fail
718 a fast zero request (as a fast failure is better than attempting the
719 write only to find out after the fact that it was not fast after all).
720 Note that on Linux, support for "ioctl(BLKZEROOUT)" is insufficient for
721 determining whether a zero request to a block device will be fast
722 (because the kernel will perform a slow fallback when needed).
723 The callback must write the whole "count" bytes if it can. The NBD
725 protocol doesn't allow partial writes (instead, these would be errors).
726 If the whole "count" bytes was written successfully, the callback
727 should return 0 to indicate there was no error.
728 If there is an error, ".zero" should call "nbdkit_error" with an error
730 message, and "nbdkit_set_error" to record an appropriate error (unless
731 "errno" is sufficient), then return "-1".
732 If this callback is omitted, or if it fails with "ENOTSUP" or
734 "EOPNOTSUPP" (whether by "nbdkit_set_error" or "errno"), then ".pwrite"
735 will be used as an automatic fallback except when the client requested
736 a fast zero.
737 ".extents"
739 int extents (void *handle, uint32_t count, uint64_t offset,
740 uint32_t flags, struct nbdkit_extents *extents);
741 During the data serving phase, this callback is used to detect
743 allocated, sparse and zeroed regions of the disk.
744 This function will not be called if ".can_extents" returned false.
746 nbdkit's default behaviour in this case is to treat the whole virtual
747 disk as if it was allocated. Also, this function will not be called by
748 a client that does not request structured replies (the --no-sr option
749 of nbdkit can be used to test behavior when ".extents" is unavailable
750 to the client).
751 The callback should detect and return the list of extents overlapping
753 the range "[offset...offset+count-1]". The "extents" parameter points
754 to an opaque object which the callback should fill in by calling
755 "nbdkit_add_extent". See "Extents list" below.
756 If there is an error, ".extents" should call "nbdkit_error" with an
758 error message, and "nbdkit_set_error" to record an appropriate error
759 (unless "errno" is sufficient), then return "-1".
760 Extents list
762 The plugin "extents" callback is passed an opaque pointer "struct
764 nbdkit_extents *extents". This structure represents a list of
765 filesystem extents describing which areas of the disk are allocated,
766 which are sparse (“holes”), and, if supported, which are zeroes.
767 The "extents" callback should scan the disk starting at "offset" and
769 call "nbdkit_add_extent" for each extent found.
770 Extents overlapping the range "[offset...offset+count-1]" should be
772 returned if possible. However nbdkit ignores extents < offset so the
773 plugin may, if it is easier to implement, return all extent information
774 for the whole disk. The plugin may return extents beyond the end of
775 the range. It may also return extent information for less than the
776 whole range, but it must return at least one extent overlapping
777 "offset".
778 The extents must be added in ascending order, and must be contiguous.
780 The "flags" parameter of the ".extents" callback may contain the flag
782 "NBDKIT_FLAG_REQ_ONE". This means that the client is only requesting
783 information about the extent overlapping "offset". The plugin may
784 ignore this flag, or as an optimization it may return just a single
785 extent for "offset".
786 int nbdkit_add_extent (struct nbdkit_extents *extents,
788 uint64_t offset, uint64_t length, uint32_t type);
789 Add an extent covering "[offset...offset+length-1]" of one of the
791 following four types:
792 "type = 0"
794 A normal, allocated data extent.
795 "type = NBDKIT_EXTENT_HOLE|NBDKIT_EXTENT_ZERO"
797 An unallocated extent, a.k.a. a “hole”, which reads back as zeroes.
798 This is the normal type of hole applicable to most disks.
799 "type = NBDKIT_EXTENT_ZERO"
801 An allocated extent which is known to contain only zeroes.
802 "type = NBDKIT_EXTENT_HOLE"
804 An unallocated extent (hole) which does not read back as zeroes.
805 Note this should only be used in specialized circumstances such as
806 when writing a plugin for (or to emulate) certain SCSI drives which
807 do not guarantee that trimmed blocks read back as zeroes.
808 "nbdkit_extent_add" returns 0 on success or "-1" on failure. On
810 failure "nbdkit_error" and/or "nbdkit_set_error" has already been
811 called. "errno" will be set to a suitable value.
812 ".cache"
814 int cache (void *handle, uint32_t count, uint64_t offset, uint32_t flags);
815 During the data serving phase, this callback is used to give the plugin
817 a hint that the client intends to make further accesses to the given
818 region of the export. The nature of caching is not specified further
819 by the NBD specification (for example, a server may place limits on how
820 much may be cached at once, and there is no way to control if writes to
821 a cached area have write-through or write-back semantics). In fact,
822 the cache command can always fail and still be compliant, and success
823 might not guarantee a performance gain. If this callback is omitted,
824 then the results of ".can_cache" determine whether nbdkit will reject
825 cache requests, treat them as instant success, or emulate caching by
826 calling ".pread" over the same region and ignoring the results.
827 This function will not be called if ".can_cache" did not return
829 "NBDKIT_CACHE_NATIVE". The parameter "flags" exists in case of future
830 NBD protocol extensions; at this time, it will be 0 on input. A plugin
831 must fail this function if "flags" includes an unrecognized flag, as
832 that may indicate a requirement that the plugin comply must with a
833 specific caching semantic.
834 If there is an error, ".cache" should call "nbdkit_error" with an error
836 message, and "nbdkit_set_error" to record an appropriate error (unless
837 "errno" is sufficient), then return "-1".
838
840 The plugin struct also contains an integer field used as a boolean in C
841 code, but unlikely to be exposed in other language bindings:
842 ".errno_is_preserved"
844 This defaults to 0; if non-zero, nbdkit can reliably use the value
845 of "errno" when a callback reports failure, rather than the plugin
846 having to call "nbdkit_set_error".
847
849 Each nbdkit plugin must declare its maximum thread safety model by
850 defining the "THREAD_MODEL" macro. (This macro is used by
851 "NBDKIT_REGISTER_PLUGIN"). Additionally, a plugin may implement the
852 ".thread_model" callback, called right after ".config_complete" to make
853 a runtime decision on which thread model to use. The nbdkit server
854 chooses the most restrictive model between the plugin's "THREAD_MODEL",
855 the ".thread_model" if present, any restrictions requested by filters,
856 and any limitations imposed by the system (for example, a system
857 without atomic "FD_CLOEXEC" will serialize all requests, so as to avoid
858 nbdkit leaking a new file descriptor from one thread into a child
859 process created by another thread).
860 In "nbdkit --dump-plugin PLUGIN" output, the "max_thread_model" line
862 matches the "THREAD_MODEL" macro, and the "thread_model" line matches
863 what the system finally settled on after applying all restrictions.
864 The possible settings for "THREAD_MODEL" are defined below.
866 "#define THREAD_MODEL NBDKIT_THREAD_MODEL_SERIALIZE_CONNECTIONS"
868 Only a single handle can be open at any time, and all requests
869 happen from one thread.
870 Note this means only one client can connect to the server at any
872 time. If a second client tries to connect it will block waiting
873 for the first client to close the connection.
874 "#define THREAD_MODEL NBDKIT_THREAD_MODEL_SERIALIZE_ALL_REQUESTS"
876 This is a safe default for most plugins.
877 Multiple handles can be open at the same time, but requests are
879 serialized so that for the plugin as a whole only one
880 open/read/write/close (etc) request will be in progress at any
881 time.
882 This is a useful setting if the library you are using is not
884 thread-safe. However performance may not be good.
885 "#define THREAD_MODEL NBDKIT_THREAD_MODEL_SERIALIZE_REQUESTS"
887 Multiple handles can be open and multiple data requests can happen
888 in parallel. However only one request will happen per handle at a
889 time (but requests on different handles might happen concurrently).
890 "#define THREAD_MODEL NBDKIT_THREAD_MODEL_PARALLEL"
892 Multiple handles can be open and multiple data requests can happen
893 in parallel (even on the same handle). The server may reorder
894 replies, answering a later request before an earlier one.
895 All the libraries you use must be thread-safe and reentrant, and
897 any code that creates a file descriptor should atomically set
898 "FD_CLOEXEC" if you do not want it accidentally leaked to another
899 thread's child process. You may also need to provide mutexes for
900 fields in your connection handle.
901 If none of the above thread models are suitable, then use
903 "NBDKIT_THREAD_MODEL_PARALLEL" and implement your own locking using
904 "pthread_mutex_t" etc.
905
907 When nbdkit receives certain signals it will shut down (see "SIGNALS"
908 in nbdkit(1)). The server will wait for any currently running plugin
909 callbacks to finish and also call the ".unload" callback before
910 unloading the plugin.
911 Note that it's not guaranteed this can always happen (eg. the server
913 might be killed by "SIGKILL" or segfault).
914
916 Parsing numbers
917 There are several functions for parsing numbers. These all deal
918 correctly with overflow, out of range and parse errors, and you should
919 use them instead of unsafe functions like sscanf(3), atoi(3) and
920 similar.
921 int nbdkit_parse_int (const char *what, const char *str, int *r);
923 int nbdkit_parse_unsigned (const char *what,
924 const char *str, unsigned *r);
925 int nbdkit_parse_int8_t (const char *what,
926 const char *str, int8_t *r);
927 int nbdkit_parse_uint8_t (const char *what,
928 const char *str, uint8_t *r);
929 int nbdkit_parse_int16_t (const char *what,
930 const char *str, int16_t *r);
931 int nbdkit_parse_uint16_t (const char *what,
932 const char *str, uint16_t *r);
933 int nbdkit_parse_int32_t (const char *what,
934 const char *str, int32_t *r);
935 int nbdkit_parse_uint32_t (const char *what,
936 const char *str, uint32_t *r);
937 int nbdkit_parse_int64_t (const char *what,
938 const char *str, int64_t *r);
939 int nbdkit_parse_uint64_t (const char *what,
940 const char *str, uint64_t *r);
941 Parse string "str" into an integer of various types. These functions
943 parse a decimal, hexadecimal ("0x...") or octal ("0...") number.
944 On success the functions return 0 and set *r to the parsed value
946 (unless "*r == NULL" in which case the result is discarded). On error,
947 "nbdkit_error" is called and the functions return "-1". On error *r is
948 always unchanged.
949 The "what" parameter is printed in error messages to provide context.
951 It should usually be a short descriptive string of what you are trying
952 to parse, eg:
953 if (nbdkit_parse_int ("random seed", argv[1], &seed) == -1)
955 return -1;
956 might print an error:
958 random seed: could not parse number: "lalala"
960 Parsing sizes
962 Use the "nbdkit_parse_size" utility function to parse human-readable
963 size strings such as "100M" into the size in bytes.
964 int64_t nbdkit_parse_size (const char *str);
966 "str" can be a string in a number of common formats. The function
968 returns the size in bytes. If there was an error, it returns "-1".
969 Parsing booleans
971 Use the "nbdkit_parse_bool" utility function to parse human-readable
972 strings such as "on" into a boolean value.
973 int nbdkit_parse_bool (const char *str);
975 "str" can be a string containing a case-insensitive form of various
977 common toggle values. The function returns 0 or 1 if the parse was
978 successful. If there was an error, it returns "-1".
979 Reading passwords
981 The "nbdkit_read_password" utility function can be used to read
982 passwords from config parameters:
983 int nbdkit_read_password (const char *value, char **password);
985 For example:
987 char *password = NULL;
989 static int
991 myplugin_config (const char *key, const char *value)
992 {
993 ..
994 if (strcmp (key, "password") == 0) {
995 free (password);
996 if (nbdkit_read_password (value, &password) == -1)
997 return -1;
998 }
999 ..
1000 }
1001 The "password" result string is allocated by malloc, and so you may
1003 need to free it.
1004 This function recognizes several password formats. A password may be
1006 used directly on the command line, eg:
1007 nbdkit myplugin password=mostsecret
1009 But more securely this function can also read a password interactively:
1011 nbdkit myplugin password=-
1013 or from a file:
1015 nbdkit myplugin password=+/tmp/secret
1017 or from a file descriptor inherited by nbdkit:
1019 nbdkit myplugin password=-99
1021 (If the password begins with a "-" or "+" character then it must be
1023 passed in a file).
1024
1026 The server usually (not always) changes directory to "/" before it
1027 starts serving connections. This means that any relative paths passed
1028 during configuration will not work when the server is running (example:
1029 "nbdkit plugin.so disk.img").
1030 To avoid problems, prepend relative paths with the current directory
1032 before storing them in the handle. Or open files and store the file
1033 descriptor.
1034 "nbdkit_absolute_path"
1036 char *nbdkit_absolute_path (const char *filename);
1037 The utility function "nbdkit_absolute_path" converts any path to an
1039 absolute path: if it is relative, then all this function does is
1040 prepend the current working directory to the path, with no extra
1041 checks.
1042 Note that this function works only when used in the ".config", and
1044 ".config_complete" callbacks.
1045 If conversion was not possible, this calls "nbdkit_error" and returns
1047 "NULL". Note that this function does not check that the file exists.
1048 The returned string must be freed by the caller.
1050 "nbdkit_realpath"
1052 char *nbdkit_realpath (const char *filename);
1053 The utility function "nbdkit_realpath" converts any path to an absolute
1055 path, resolving symlinks. Under the hood it uses the "realpath"
1056 function, and thus it fails if the path does not exist, or it is not
1057 possible to access to any of the components of the path.
1058 Note that this function works only when used in the ".config", and
1060 ".config_complete" callbacks.
1061 If the path resolution was not possible, this calls "nbdkit_error" and
1063 returns "NULL".
1064 The returned string must be freed by the caller.
1066 umask
1068 All plugins will see a umask(2) of 0022.
1069
1071 A plugin that needs to sleep may call sleep(2), nanosleep(2) and
1072 similar. However that can cause nbdkit to delay excessively when
1073 shutting down (since it must wait for any plugin or filter which is
1074 sleeping). To avoid this there is a special wrapper around nanosleep
1075 which plugins and filters should use instead.
1076 "nbdkit_nanosleep"
1078 int nbdkit_nanosleep (unsigned sec, unsigned nsec);
1079 The utility function "nbdkit_nanosleep" suspends the current thread,
1081 and returns 0 if it slept at least as many seconds and nanoseconds as
1082 requested, or -1 after calling "nbdkit_error" if there is no point in
1083 continuing the current command. Attempts to sleep more than "INT_MAX"
1084 seconds are treated as an error.
1085
1087 If the client negotiated an NBD export name with nbdkit then plugins
1088 may read this from any connected callbacks. Nbdkit's normal behaviour
1089 is to accept any export name passed by the client, log it in debug
1090 output, but otherwise ignore it. By using "nbdkit_export_name" plugins
1091 may choose to filter by export name or serve different content.
1092 "nbdkit_export_name"
1094 const char *nbdkit_export_name (void);
1095 Return the optional NBD export name if one was negotiated with the
1097 current client (this uses thread-local magic so no parameter is
1098 required). The returned string is only valid while the client is
1099 connected, so if you need to store it in the plugin you must copy it.
1100 The export name is a free-form text string, it is not necessarily a
1102 path or filename and it does not need to begin with a '/' character.
1103 The NBD protocol describes the empty string ("") as a representing a
1104 "default export" or to be used in cases where the export name does not
1105 make sense. The export name is untrusted client data, be cautious when
1106 parsing it.
1107 On error, "nbdkit_error" is called and the call returns "NULL".
1109
1111 It is possible to get the address of the client when you are running in
1112 any connected callback.
1113 "nbdkit_peer_name"
1115 int nbdkit_peer_name (struct sockaddr *addr, socklen_t *addrlen);
1116 Return the peer (client) address, if available. The "addr" and
1118 "addrlen" parameters behave like getpeername(2). In particular you
1119 must initialize "addrlen" with the size of the buffer pointed to by
1120 "addr", and if "addr" is not large enough then the address will be
1121 truncated.
1122 In some cases this is not available or the address returned will be
1124 meaningless (eg. if there is a proxy between the client and nbdkit).
1125 This call uses thread-local magic so no parameter is required to
1126 specify the current connection.
1127 On success this returns 0. On error, "nbdkit_error" is called and this
1129 call returns "-1".
1130
1132 Run the server with -f and -v options so it doesn't fork and you can
1133 see debugging information:
1134 nbdkit -fv ./myplugin.so [key=value [key=value [...]]]
1136 To print debugging information from within the plugin, call
1138 "nbdkit_debug", which has the following prototype and works like
1139 printf(3):
1140 void nbdkit_debug (const char *fs, ...);
1142 void nbdkit_vdebug (const char *fs, va_list args);
1143 For convenience, "nbdkit_debug" preserves the value of "errno", and
1145 also supports the glibc extension of a single %m in a format string
1146 expanding to "strerror(errno)", even on platforms that don't support
1147 that natively. Note that "nbdkit_debug" only prints things when the
1148 server is in verbose mode (-v option).
1149 Debug Flags
1151 The -v option switches general debugging on or off, and this debugging
1152 should be used for messages which are useful for all users of your
1153 plugin.
1154 In cases where you want to enable specific extra debugging to track
1156 down bugs in plugins or filters — mainly for use by the plugin/filter
1157 developers themselves — you can define Debug Flags. These are global
1158 ints called "myplugin_debug_*":
1159 int myplugin_debug_foo;
1161 int myplugin_debug_bar;
1162 ...
1163 if (myplugin_debug_foo) {
1164 nbdkit_debug ("lots of extra debugging about foo: ...");
1165 }
1166 Debug Flags can be controlled on the command line using the -D (or
1168 --debug) option:
1169 nbdkit -f -v -D myplugin.foo=1 -D myplugin.bar=2 myplugin [...]
1171 Note "myplugin" is the name passed to ".name" in the "struct
1173 nbdkit_plugin".
1174 You should only use this feature for debug settings. For general
1176 settings use ordinary plugin parameters. Debug Flags can only be C
1177 ints. They are not supported by non-C language plugins.
1178
1180 The plugin is a "*.so" file and possibly a manual page. You can of
1181 course install the plugin "*.so" file wherever you want, and users will
1182 be able to use it by running:
1183 nbdkit /path/to/plugin.so [args]
1185 However if the shared library has a name of the form
1187 "nbdkit-name-plugin.so" and if the library is installed in the
1188 $plugindir directory, then users can be run it by only typing:
1189 nbdkit name [args]
1191 The location of the $plugindir directory is set when nbdkit is compiled
1193 and can be found by doing:
1194 nbdkit --dump-config
1196 If using the pkg-config/pkgconf system then you can also find the
1198 plugin directory at compile time by doing:
1199 pkgconf nbdkit --variable=plugindir
1201
1203 nbdkit provides a pkg-config/pkgconf file called "nbdkit.pc" which
1204 should be installed on the correct path when the nbdkit plugin
1205 development environment is installed. You can use this in autoconf
1206 configure.ac scripts to test for the development environment:
1207 PKG_CHECK_MODULES([NBDKIT], [nbdkit >= 1.2.3])
1209 The above will fail unless nbdkit ≥ 1.2.3 and the header file is
1211 installed, and will set "NBDKIT_CFLAGS" and "NBDKIT_LIBS" appropriately
1212 for compiling plugins.
1213 You can also run pkg-config/pkgconf directly, for example:
1215 if ! pkgconf nbdkit --exists; then
1217 echo "you must install the nbdkit plugin development environment"
1218 exit 1
1219 fi
1220 You can also substitute the plugindir variable by doing:
1222 PKG_CHECK_VAR([NBDKIT_PLUGINDIR], [nbdkit], [plugindir])
1224 which defines "$(NBDKIT_PLUGINDIR)" in automake-generated Makefiles.
1226
1228 You can also write nbdkit plugins in Lua, OCaml, Perl, Python, Ruby,
1229 Rust, shell script or Tcl. Other programming languages may be offered
1230 in future.
1231 For more information see: nbdkit-lua-plugin(3), nbdkit-ocaml-plugin(3),
1233 nbdkit-perl-plugin(3), nbdkit-python-plugin(3), nbdkit-ruby-plugin(3),
1234 nbdkit-rust-plugin(3), nbdkit-sh-plugin(3), nbdkit-tcl-plugin(3) .
1235 Plugins written in scripting languages may also be installed in
1237 $plugindir. These must be called "nbdkit-name-plugin" without any
1238 extension. They must be executable, and they must use the shebang
1239 header (see "Shebang scripts" in nbdkit(1)). For example a plugin
1240 written in Perl called "foo.pl" might be installed like this:
1241 $ head -1 foo.pl
1243 #!/usr/sbin/nbdkit perl
1244 $ sudo install -m 0755 foo.pl $plugindir/nbdkit-foo-plugin
1246 and then users will be able to run it like this:
1248 $ nbdkit foo [args ...]
1250
1252 nbdkit(1), nbdkit-nozero-filter(3), nbdkit-filter(3).
1253 Standard plugins provided by nbdkit:
1255 nbdkit-curl-plugin(1), nbdkit-data-plugin(1),
1257 nbdkit-example1-plugin(1), nbdkit-example2-plugin(1),
1258 nbdkit-example3-plugin(1), nbdkit-example4-plugin(1),
1259 nbdkit-ext2-plugin(1), nbdkit-file-plugin(1), nbdkit-floppy-plugin(1),
1260 nbdkit-full-plugin(1), nbdkit-guestfs-plugin(1), nbdkit-gzip-plugin(1),
1261 nbdkit-info-plugin(1), nbdkit-iso-plugin(1), nbdkit-libvirt-plugin(1),
1262 nbdkit-linuxdisk-plugin(1), nbdkit-memory-plugin(1),
1263 nbdkit-nbd-plugin(1), nbdkit-null-plugin(1),
1264 nbdkit-partitioning-plugin(1), nbdkit-pattern-plugin(1),
1265 nbdkit-random-plugin(1), nbdkit-split-plugin(1), nbdkit-ssh-plugin(1),
1266 nbdkit-streaming-plugin(1), nbdkit-tar-plugin(1),
1267 nbdkit-vddk-plugin(1), nbdkit-zero-plugin(1) ; nbdkit-lua-plugin(3),
1268 nbdkit-ocaml-plugin(3), nbdkit-perl-plugin(3), nbdkit-python-plugin(3),
1269 nbdkit-ruby-plugin(3), nbdkit-rust-plugin(3), nbdkit-sh-plugin(3),
1270 nbdkit-tcl-plugin(3) .
1271
1273 Eric Blake
1274 Richard W.M. Jones
1276 Pino Toscano
1278
1280 Copyright (C) 2013-2018 Red Hat Inc.
1281
1283 Redistribution and use in source and binary forms, with or without
1284 modification, are permitted provided that the following conditions are
1285 met:
1286 · Redistributions of source code must retain the above copyright
1288 notice, this list of conditions and the following disclaimer.
1289 · Redistributions in binary form must reproduce the above copyright
1291 notice, this list of conditions and the following disclaimer in the
1292 documentation and/or other materials provided with the
1293 distribution.
1294 · Neither the name of Red Hat nor the names of its contributors may
1296 be used to endorse or promote products derived from this software
1297 without specific prior written permission.
1298 THIS SOFTWARE IS PROVIDED BY RED HAT AND CONTRIBUTORS ''AS IS'' AND ANY
1300 EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
1301 IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
1302 PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL RED HAT OR CONTRIBUTORS BE
1303 LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
1304 CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
1305 SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
1306 BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
1307 WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
1308 OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
1309 ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
1310nbdkit-1.16.1 2019-12-03 nbdkit-plugin(3)