3 nbdkit-plugin - how to write nbdkit plugins
7 #define NBDKIT_API_VERSION 2
8 #include <nbdkit-plugin.h>
10 #define THREAD_MODEL NBDKIT_THREAD_MODEL_SERIALIZE_ALL_REQUESTS
15 /* create a handle ... */
19 static struct nbdkit_plugin plugin = {
21 .open = myplugin_open,
22 .get_size = myplugin_get_size,
23 .pread = myplugin_pread,
24 .pwrite = myplugin_pwrite,
27 NBDKIT_REGISTER_PLUGIN(plugin)
29 Compile the plugin as a shared library:
31 gcc -fPIC -shared myplugin.c -o myplugin.so
33 and load it into nbdkit:
35 nbdkit [--args ...] ./myplugin.so [key=value ...]
37 When debugging, use the I<-fv> options:
39 nbdkit -fv ./myplugin.so [key=value ...]
43 An nbdkit plugin is a new source device which can be served using the
44 Network Block Device (NBD) protocol. This manual page describes how
45 to create an nbdkit plugin in C.
47 To see example plugins:
48 L<https://gitlab.com/nbdkit/nbdkit/tree/master/plugins>
50 To write plugins in other languages, see:
51 __LANG_PLUGIN_LINKS__.
53 =head2 API and ABI guarantee for C plugins
55 Plugins written in C have an ABI guarantee: a plugin compiled against
56 an older version of nbdkit will still work correctly when loaded with
57 a newer nbdkit. We also try (but cannot guarantee) to support plugins
58 compiled against a newer version of nbdkit when loaded with an older
59 nbdkit, although the plugin may have reduced functionality if it
60 depends on features only provided by newer nbdkit.
62 For plugins written in C, we also provide an API guarantee: a plugin
63 written against an older header will still compile unmodified with a
66 The API guarantee does not always apply to plugins written in other
67 (non-C) languages which may have to adapt to changes when recompiled
68 against a newer nbdkit.
70 =head1 WRITING AN NBDKIT PLUGIN
72 =head2 C<#define NBDKIT_API_VERSION 2>
74 Plugins must choose which API version they want to use, by defining
75 NBDKIT_API_VERSION before including C<E<lt>nbdkit-plugin.hE<gt>> (or
76 any other nbdkit header).
78 If omitted, the default version is 1 for backwards-compatibility with
79 nbdkit v1.1.26 and earlier; however, it is recommended that new
80 plugins be written to the maximum version (currently 2) as it enables
81 more features and better interaction with nbdkit filters.
83 The rest of this document only covers the version 2 interface. A
84 newer nbdkit will always support plugins written in C which use any
87 =head2 C<#include E<lt>nbdkit-plugin.hE<gt>>
89 All plugins should start by including this header file (after
90 optionally choosing an API version).
92 =head2 C<#define THREAD_MODEL ...>
94 All plugins must define a thread model. See L</Threads> below for
95 details. It is generally safe to use:
97 #define THREAD_MODEL NBDKIT_THREAD_MODEL_SERIALIZE_ALL_REQUESTS
99 =head2 C<struct nbdkit_plugin>
101 All plugins must define and register one C<struct nbdkit_plugin>,
102 which contains the name of the plugin and pointers to callback
103 functions, and use the C<NBDKIT_REGISTER_PLUGIN(plugin)> macro:
105 static struct nbdkit_plugin plugin = {
107 .longname = "My Plugin",
108 .description = "This is my great plugin for nbdkit",
109 .open = myplugin_open,
110 .get_size = myplugin_get_size,
111 .pread = myplugin_pread,
112 .pwrite = myplugin_pwrite,
115 NBDKIT_REGISTER_PLUGIN(plugin)
117 The C<.name> field is the name of the plugin.
119 The callbacks are described below (see L</CALLBACKS>). Only C<.name>,
120 C<.open>, C<.get_size> and C<.pread> are required. All other
121 callbacks can be omitted, although typical plugins need to use more.
123 =head2 Callback lifecycle
125 Callbacks are called in the following order over the lifecycle of
131 │ configuration phase starts ─┐
132 ┌─────────┴────────┐ ┆
133 │ config │ config is called once per ┆
134 └─────────┬────────┘↺ key=value on the command line ┆
135 ┌─────────┴────────┐ ┆
136 │ config_complete │ ┆
137 └─────────┬────────┘ ┆
138 ┌─────────┴────────┐ ┆
140 └─────────┬────────┘ configuration phase ends ─┘
144 │ nbdkit forks into the background
148 │ nbdkit starts serving clients
150 ┌──────────┴─────────────┬─ ─ ─ ─ ─ ─ ─ ─ ─
151 ┌──────┴─────┐ client #1 │
160 ┌──────┴─────┐ NBD option │
161 │ can_write │ negotiation │
163 ┌──────┴─────┐ ┌──────┴─────┐ client #2
164 │ get_size │ │ preconnect │
165 └──────┬─────┘ └──────┬─────┘
171 └──────┬─────┘↺ ┌──────┴─────┐
172 ┌──────┴─────┐ │ close │
173 │ close │ └────────────┘
176 │ before nbdkit exits
189 =item C<nbdkit --dump-plugin>
191 The order of calls when the user queries the plugin is slightly
192 different: C<.config> is called once for each parameter.
193 C<.config_complete> is I<not> called. C<.thread_model> is called
198 This is the last chance to do any global preparation that is needed to
199 serve connections. In particular, error messages here will be visible
200 to the user, but they might not be in C<.after_fork> (see below).
202 Plugins should not create background threads here. Use C<.after_fork>
207 C<.after_fork> is called after the server has forked into the
208 background and changed UID and directory. If a plugin needs to create
209 background threads (or uses an external library that creates threads)
210 it should do so here, because background threads are invalidated by
213 Because the server may have forked into the background, error messages
214 and failures from C<.after_fork> cannot be seen by the user unless
215 they look through syslog. An error in C<.after_fork> can appear to
216 the user as if nbdkit “just died”. So in almost all cases it is
217 better to use C<.get_ready> instead of this callback, or to do as much
218 preparation work as possible in C<.get_ready> and only start
219 background threads here.
221 The server doesn't always fork (eg. if the I<-f> flag is used), but
222 even so this callback will be called. If you want to find out if the
223 server forked between C<.get_ready> and C<.after_fork> use
226 =item C<.preconnect> and C<.open>
228 C<.preconnect> is called when a TCP connection has been made to the
229 server. This happens early, before NBD or TLS negotiation.
231 C<.open> is called when a new client has connected and finished the
232 NBD handshake. TLS negotiation (if used) has been completed
235 =item C<.can_write>, C<.get_size> and other option negotiation callbacks
237 These are called during option negotiation with the client, but before
238 any data is served. These callbacks may return different values
239 across different C<.open> calls, but within a single connection, they
240 are called at most once and cached by nbdkit for that connection.
242 =item C<.pread>, C<.pwrite> and other data serving callbacks
244 After option negotiation has finished, these may be called to serve
245 data. Depending on the thread model chosen, they might be called in
246 parallel from multiple threads. The data serving callbacks include a
247 flags argument; the results of the negotiation callbacks influence
248 whether particular flags will ever be passed to a data callback.
250 =item C<.cleanup> and C<.unload>
252 The difference between these two methods is that C<.cleanup> is called
253 before any filter has been removed from memory with L<dlclose(3)>.
254 When C<.unload> is called, nbdkit is in the middle of calling
255 L<dlclose(3)>. Most plugins do not need to worry about this
262 The following flags are defined by nbdkit, and used in various data
263 serving callbacks as follows:
267 =item C<NBDKIT_FLAG_MAY_TRIM>
269 This flag is used by the C<.zero> callback; there is no way to disable
270 this flag, although a plugin that does not support trims as a way to
271 write zeroes may ignore the flag without violating expected semantics.
273 =item C<NBDKIT_FLAG_FUA>
275 This flag represents Forced Unit Access semantics. It is used by the
276 C<.pwrite>, C<.zero>, and C<.trim> callbacks to indicate that the
277 plugin must not return a result until the action has landed in
278 persistent storage. This flag will not be sent to the plugin unless
279 C<.can_fua> is provided and returns C<NBDKIT_FUA_NATIVE>.
283 The following defines are valid as successful return values for
288 =item C<NBDKIT_FUA_NONE>
290 Forced Unit Access is not supported; the client must manually request
291 a flush after writes have completed. The C<NBDKIT_FLAG_FUA> flag will
292 not be passed to the plugin's write callbacks.
294 =item C<NBDKIT_FUA_EMULATE>
296 The client may request Forced Unit Access, but it is implemented by
297 emulation, where nbdkit calls C<.flush> after a write operation; this
298 is semantically correct, but may hurt performance as it tends to flush
299 more data than just what the client requested. The C<NBDKIT_FLAG_FUA>
300 flag will not be passed to the plugin's write callbacks.
302 =item C<NBDKIT_FUA_NATIVE>
304 The client may request Forced Unit Access, which results in the
305 C<NBDKIT_FLAG_FUA> flag being passed to the plugin's write callbacks
306 (C<.pwrite>, C<.trim>, and C<.zero>). When the flag is set, these
307 callbacks must not return success until the client's request has
308 landed in persistent storage.
312 The following defines are valid as successful return values for
317 =item C<NBDKIT_CACHE_NONE>
319 The server does not advertise caching support, and rejects any
320 client-requested caching. Any C<.cache> callback is ignored.
322 =item C<NBDKIT_CACHE_EMULATE>
324 The nbdkit server advertises cache support to the client, where the
325 client may request that the server cache a region of the export to
326 potentially speed up future read and/or write operations on that
327 region. The nbdkit server implements the caching by calling C<.pread>
328 and ignoring the results. This option exists to ease the
329 implementation of a common form of caching; any C<.cache> callback is
332 =item C<NBDKIT_CACHE_NATIVE>
334 The nbdkit server advertises cache support to the client, where the
335 client may request that the server cache a region of the export to
336 potentially speed up future read and/or write operations on that
337 region. The nbdkit server calls the C<.cache> callback to perform the
338 caching; if that callback is missing, the client's cache request
339 succeeds without doing anything.
345 Each nbdkit plugin must declare its maximum thread safety model by
346 defining the C<THREAD_MODEL> macro. (This macro is used by
347 C<NBDKIT_REGISTER_PLUGIN>). Additionally, a plugin may implement the
348 C<.thread_model> callback, called right after C<.config_complete> to
349 make a runtime decision on which thread model to use. The nbdkit
350 server chooses the most restrictive model between the plugin's
351 C<THREAD_MODEL>, the C<.thread_model> if present, any restrictions
352 requested by filters, and any limitations imposed by the operating
355 In C<nbdkit --dump-plugin PLUGIN> output, the C<max_thread_model> line
356 matches the C<THREAD_MODEL> macro, and the C<thread_model> line
357 matches what the system finally settled on after applying all
360 The possible settings for C<THREAD_MODEL> are defined below.
364 =item C<#define THREAD_MODEL NBDKIT_THREAD_MODEL_SERIALIZE_CONNECTIONS>
366 Only a single handle can be open at any time, and all requests happen
369 Note this means only one client can connect to the server at any time.
370 If a second client tries to connect it will block waiting for the
371 first client to close the connection.
373 =item C<#define THREAD_MODEL NBDKIT_THREAD_MODEL_SERIALIZE_ALL_REQUESTS>
375 I<This is a safe default for most plugins>.
377 Multiple handles can be open at the same time, but requests are
378 serialized so that for the plugin as a whole only one
379 open/read/write/close (etc) request will be in progress at any time.
381 This is a useful setting if the library you are using is not
382 thread-safe. However performance may not be good.
384 =item C<#define THREAD_MODEL NBDKIT_THREAD_MODEL_SERIALIZE_REQUESTS>
386 Multiple handles can be open and multiple data requests can happen in
387 parallel. However only one request will happen per handle at a time
388 (but requests on different handles might happen concurrently).
390 =item C<#define THREAD_MODEL NBDKIT_THREAD_MODEL_PARALLEL>
392 Multiple handles can be open and multiple data requests can happen in
393 parallel (even on the same handle). The server may reorder replies,
394 answering a later request before an earlier one.
396 All the libraries you use must be thread-safe and reentrant, and any
397 code that creates a file descriptor should atomically set
398 C<FD_CLOEXEC> if you do not want it accidentally leaked to another
399 thread's child process. You may also need to provide mutexes for
400 fields in your connection handle.
404 If none of the above thread models are suitable, use
405 C<NBDKIT_THREAD_MODEL_PARALLEL> and implement your own locking using
406 C<pthread_mutex_t> etc.
408 =head2 Error handling
410 If there is an error in the plugin, the plugin should call
411 C<nbdkit_error> to report an error message; additionally, if the
412 callback is involved in serving data, the plugin should call
413 C<nbdkit_set_error> to influence the error code that will be sent to
414 the client. These two functions can be called in either order. Then,
415 the callback should return the appropriate error indication,
416 eg. C<NULL> or C<-1>.
418 If the call to C<nbdkit_set_error> is omitted while serving data, then
419 the global variable C<errno> may be used. For plugins which have
420 C<.errno_is_preserved != 0> the core code will use C<errno>. In
421 plugins written in non-C languages, we usually cannot trust that
422 C<errno> will not be overwritten when returning from that language to
423 C. In that case, either the plugin must call C<nbdkit_set_error> or
424 hard-coded C<EIO> is used.
426 C<nbdkit_error> has the following prototype and works like
429 void nbdkit_error (const char *fs, ...);
430 void nbdkit_verror (const char *fs, va_list args);
432 For convenience, C<nbdkit_error> preserves the value of C<errno>, and
433 also supports the glibc extension of a single C<%m> in a format string
434 expanding to C<strerror(errno)>, even on platforms that don't support
437 C<nbdkit_set_error> can be called at any time, but only has an impact
438 during callbacks for serving data, and only when the callback returns
439 an indication of failure. It has the following prototype:
441 void nbdkit_set_error (int err);
449 This field (a string) is required, and B<must> contain only ASCII
450 alphanumeric characters or non-leading dashes, and be unique amongst
457 Plugins may optionally set a version string which is displayed in help
458 and debugging output. (See also L</VERSION> below)
462 const char *longname;
464 An optional free text name of the plugin. This field is used in error
467 =head2 C<.description>
469 const char *description;
471 An optional multi-line description of the plugin.
477 This is called once just after the plugin is loaded into memory. You
478 can use this to perform any global initialization needed by the
485 This may be called once just before the plugin is unloaded from
486 memory. Note that it's not guaranteed that C<.unload> will always be
487 called (eg. the server might be killed or segfault), so you should try
488 to make the plugin as robust as possible by not requiring cleanup.
489 See also L</SHUTDOWN> below.
491 =head2 C<.dump_plugin>
493 void dump_plugin (void);
495 This optional callback is called when the
496 S<C<nbdkit plugin --dump-plugin>> command is used. It should print
497 any additional informative C<key=value> fields to stdout as needed.
498 Prefixing the keys with the name of the plugin will avoid conflicts.
502 int config (const char *key, const char *value);
504 On the nbdkit command line, after the plugin filename, come an
505 optional list of C<key=value> arguments. These are passed to the
506 plugin through this callback when the plugin is first loaded and
507 before any connections are accepted.
509 This callback may be called zero or more times.
511 Both C<key> and C<value> parameters will be non-NULL. The strings are
512 owned by nbdkit but will remain valid for the lifetime of the plugin,
513 so the plugin does not need to copy them.
515 The key will be a non-empty string beginning with an ASCII alphabetic
516 character (C<A-Z> C<a-z>). The rest of the key must contain only
517 ASCII alphanumeric plus period, underscore or dash characters (C<A-Z>
518 C<a-z> C<0-9> C<.> C<_> C<->). The value may be an arbitrary string,
519 including an empty string.
521 The names of C<key>s accepted by plugins is up to the plugin, but you
522 should probably look at other plugins and follow the same conventions.
524 If the value is a relative path, then note that the server changes
525 directory when it starts up. See L</FILENAMES AND PATHS> above.
527 If C<nbdkit_stdio_safe> returns 1, the value of the configuration
528 parameter may be used to trigger reading additional data through stdin
529 (such as a password or inline script).
531 If the C<.config> callback is not provided by the plugin, and the user
532 tries to specify any C<key=value> arguments, then nbdkit will exit
535 If there is an error, C<.config> should call C<nbdkit_error> with an
536 error message and return C<-1>.
538 =head2 C<.magic_config_key>
540 const char *magic_config_key;
542 This optional string can be used to set a "magic" key used when
543 parsing plugin parameters. It affects how "bare parameters" (those
544 which do not contain an C<=> character) are parsed on the command
547 If C<magic_config_key != NULL> then any bare parameters are passed to
548 the C<.config> method as: S<C<config (magic_config_key, argv[i]);>>.
550 If C<magic_config_key> is not set then we behave as in nbdkit E<lt>
551 1.7: If the first parameter on the command line is bare then it is
552 passed to the C<.config> method as: S<C<config ("script", value);>>.
553 Any other bare parameters give errors.
555 =head2 C<.config_complete>
557 int config_complete (void);
559 This optional callback is called after all the configuration has been
560 passed to the plugin. It is a good place to do checks, for example
561 that the user has passed the required parameters to the plugin.
563 If there is an error, C<.config_complete> should call C<nbdkit_error>
564 with an error message and return C<-1>.
566 =head2 C<.config_help>
568 const char *config_help;
570 This optional multi-line help message should summarize any
571 C<key=value> parameters that it takes. It does I<not> need to repeat
572 what already appears in C<.description>.
574 If the plugin doesn't take any config parameters you should probably
577 =head2 C<.thread_model>
579 int thread_model (void)
581 This optional callback is called after all the configuration has been
582 passed to the plugin. It can be used to force a stricter thread model
583 based on configuration, compared to C<THREAD_MODEL>. See L</Threads>
584 above for details. Attempts to request a looser (more parallel) model
585 are silently ignored.
587 If there is an error, C<.thread_model> should call C<nbdkit_error>
588 with an error message and return C<-1>.
592 int get_ready (void);
594 This optional callback is called before the server starts serving. It
595 is called before the server forks or changes directory. It is
596 ordinarily the last chance to do any global preparation that is needed
597 to serve connections.
599 If there is an error, C<.get_ready> should call C<nbdkit_error> with
600 an error message and return C<-1>.
602 =head2 C<.after_fork>
604 int after_fork (void);
606 This optional callback is called before the server starts serving. It
607 is called after the server forks and changes directory. If a plugin
608 needs to create background threads (or uses an external library that
609 creates threads) it should do so here, because background threads are
610 killed by fork. However you should try to do as little as possible
611 here because error reporting is difficult. See L</Callback lifecycle>
614 If there is an error, C<.after_fork> should call C<nbdkit_error> with
615 an error message and return C<-1>.
621 This optional callback is called after the server has closed all
622 connections and is preparing to unload. It is only reached in the
623 same cases that the C<.after_fork> callback was used, making it a good
624 place to clean up any background threads. However, it is not
625 guaranteed that this callback will be reached, so you should try to
626 make the plugin as robust as possible by not requiring cleanup. See
627 also L</SHUTDOWN> below.
629 =head2 C<.preconnect>
631 int preconnect (int readonly);
633 This optional callback is called when a TCP connection has been made
634 to the server. This happens early, before NBD or TLS negotiation. If
635 TLS authentication is required to access the server, then it has
636 B<not> been negotiated at this point.
638 For security reasons (to avoid denial of service attacks) this
639 callback should be written to be as fast and take as few resources as
640 possible. If you use this callback, only use it to do basic access
641 control, such as checking C<nbdkit_peer_name>, C<nbdkit_peer_pid>,
642 C<nbdkit_peer_uid>, C<nbdkit_peer_gid> against a list of permitted
643 source addresses (see L</PEER NAME> and L<nbdkit-ip-filter(1)>). It
644 may be better to do access control outside the server, for example
645 using TCP wrappers or a firewall.
647 The C<readonly> flag informs the plugin that the server was started
648 with the I<-r> flag on the command line.
650 Returning C<0> will allow the connection to continue. If there is an
651 error or you want to deny the connection, call C<nbdkit_error> with an
652 error message and return C<-1>.
654 =head2 C<.list_exports>
656 int list_exports (int readonly, int is_tls,
657 struct nbdkit_exports *exports);
659 This optional callback is called if the client tries to list the
660 exports served by the plugin (using C<NBD_OPT_LIST>). If the plugin
661 does not supply this callback then the result of C<.default_export> is
662 advertised as the lone export. The NBD protocol defines C<""> as the
663 default export, so this is suitable for plugins which ignore the
664 export name and always serve the same content. See also L</EXPORT
667 The C<readonly> flag informs the plugin that the server was started
668 with the I<-r> flag on the command line, which is the same value
669 passed to C<.preconnect> and C<.open>. However, the NBD protocol does
670 not yet have a way to let the client advertise an intent to be
671 read-only even when the server allows writes, so this parameter may
672 not be as useful as it appears.
674 The C<is_tls> flag informs the plugin whether this listing was
675 requested after the client has completed TLS negotiation. When
676 running the server in a mode that permits but does not require TLS, be
677 careful that any exports listed when C<is_tls> is C<false> do not leak
678 unintended information.
680 The C<exports> parameter is an opaque object for collecting the list
681 of exports. Call C<nbdkit_add_export> as needed to add specific
684 int nbdkit_add_export (struct nbdkit_export *exports,
685 const char *name, const char *description);
687 The C<name> must be a non-NULL, UTF-8 string between 0 and 4096 bytes
688 in length. Export names must be unique. C<description> is an
689 optional description of the export which some clients can display but
690 which is otherwise unused (if you don't want a description, you can
691 pass this parameter as C<NULL>). The string(s) are copied into the
692 exports list so you may free them immediately after calling this
693 function. C<nbdkit_add_export> returns C<0> on success or C<-1> on
694 failure; on failure C<nbdkit_error> has already been called, with
695 C<errno> set to a suitable value.
697 There are also situations where a plugin may wish to duplicate the
698 nbdkit default behavior of supplying an export list containing only
699 the result of C<.default_export> when C<.list_exports> is missing;
700 this is most common in a language binding where it is not known at
701 compile time whether the language script will be providing an
702 implementation for C<.list_exports>, and is done by calling
703 C<nbdkit_use_default_export>.
705 int nbdkit_use_default_export (struct nbdkit_export *exports);
707 C<nbdkit_use_default_export> returns C<0> on success or C<-1> on
708 failure; on failure C<nbdkit_error> has already been called, with
709 C<errno> set to a suitable value.
711 The plugin may also leave the export list empty, by not calling either
712 helper. Once the plugin is happy with the list contents, returning
713 C<0> will send the list of exports back to the client. If there is an
714 error, C<.list_exports> should call C<nbdkit_error> with an error
715 message and return C<-1>.
717 =head2 C<.default_export>
719 const char *default_export (int readonly, int is_tls);
721 This optional callback is called if the client tries to connect to the
722 default export C<"">, where the plugin provides a UTF-8 string between
723 0 and 4096 bytes. If the plugin does not supply this callback, the
724 connection continues with the empty name; if the plugin returns a
725 valid string, nbdkit behaves as if the client had passed that string
726 instead of an empty name, and returns that name to clients that
727 support it (see the C<NBD_INFO_NAME> response to C<NBD_OPT_GO>).
728 Similarly, if the plugin does not supply a C<.list_exports> callback,
729 the result of this callback determines what export name to advertise
730 to a client requesting an export list.
732 The C<readonly> flag informs the plugin that the server was started
733 with the I<-r> flag on the command line, which is the same value
734 passed to C<.preconnect> and C<.open>. However, the NBD protocol does
735 not yet have a way to let the client advertise an intent to be
736 read-only even when the server allows writes, so this parameter may
737 not be as useful as it appears.
739 The C<is_tls> flag informs the plugin whether the canonical name for
740 the default export is being requested after the client has completed
741 TLS negotiation. When running the server in a mode that permits but
742 does not require TLS, be careful that a default export name does not
743 leak unintended information.
745 If the plugin returns C<NULL> or an invalid string (such as longer
746 than 4096 bytes), the client is not permitted to connect to the
747 default export. However, this is not an error in the protocol, so it
748 is not necessary to call C<nbdkit_error>.
752 void *open (int readonly);
754 This is called when a new client connects to the nbdkit server. The
755 callback should allocate a handle and return it. This handle
756 is passed back to other callbacks and could be freed in the C<.close>
759 Note that the handle is completely opaque to nbdkit, but it must not
760 be NULL. If you don't need to use a handle, return
761 C<NBDKIT_HANDLE_NOT_NEEDED> which is a static non-NULL pointer.
763 The C<readonly> flag informs the plugin that the server was started
764 with the I<-r> flag on the command line which forces connections to be
765 read-only. Note that the plugin may I<additionally> force the
766 connection to be readonly (even if this flag is false) by returning
767 false from the C<.can_write> callback. So if your plugin can only
768 serve read-only, you can ignore this parameter.
770 If the plugin wants to differentiate the content it serves based on
771 client input, then this is the spot to use C<nbdkit_export_name()> to
772 determine which export the client requested. See also L</EXPORT NAME>
775 This callback is called after the NBD handshake has completed; if the
776 server requires TLS authentication, then that has occurred as well.
777 But if the server is set up to have optional TLS authentication, you
778 may check C<nbdkit_is_tls> to learn whether the client has completed
779 TLS authentication. When running the server in a mode that permits
780 but does not require TLS, be careful that you do not allow
781 unauthenticated clients to cause a denial of service against
784 If there is an error, C<.open> should call C<nbdkit_error> with an
785 error message and return C<NULL>.
789 void close (void *handle);
791 This is called when the client closes the connection. It should clean
792 up any per-connection resources.
794 Note there is no way in the NBD protocol to communicate close errors
795 back to the client, for example if your plugin calls L<close(2)> and
796 you are checking for errors (as you should do). Therefore the best
797 you can do is to log the error on the server. Well-behaved NBD
798 clients I<should> try to flush the connection before it is closed and
799 check for errors, but obviously this is outside the scope of nbdkit.
803 int64_t get_size (void *handle);
805 This is called during the option negotiation phase of the protocol
806 to get the size (in bytes) of the block device being exported.
808 The returned size must be E<ge> 0. If there is an error, C<.get_size>
809 should call C<nbdkit_error> with an error message and return C<-1>.
811 =head2 C<.export_description>
813 const char *export_description (void *handle);
815 This is called during the option negotiation phase only if the
816 client specifically requested an export description (see the
817 C<NBD_INFO_DESCRIPTION> response to C<NBD_OPT_GO>). Any
818 description provided must be human-readable UTF-8, no longer
819 than 4096 bytes. Ideally, this description should match any
820 description set during C<.list_exports>, but that is not
823 If the plugin returns C<NULL> or an invalid string (such as longer
824 than 4096 bytes), or if this callback is omitted, no description is
825 offered to the client. As this is not an error in the protocol, it is
826 not necessary to call C<nbdkit_error>. If the callback will not be
827 returning a compile-time constant string, you may find
828 C<nbdkit_strdup_intern> helpful for returning a value that avoids a
831 =head2 C<.block_size>
833 int block_size (void *handle, uint32_t *minimum,
834 uint32_t *preferred, uint32_t *maximum);
836 This is called during the option negotiation phase of the protocol to
837 get the minimum, preferred and maximum block size (all in bytes) of
838 the block device. The client should obey these constraints by not
839 making requests which are smaller than the minimum size or larger than
840 the maximum size, and usually making requests of a multiple of the
841 preferred size. Furthermore requests should be aligned to at least
842 the minimum block size, and usually the preferred block size.
844 "Preferred" block size in the NBD specification can be misinterpreted.
845 It means the I/O size which does not have a penalty for
848 Even if the plugin implements this callback, this does B<not> mean
849 that all client requests will obey the constraints. A client could
850 still ignore the constraints. nbdkit passes all requests through to
851 the plugin, because what the plugin does depends on the plugin's
852 policy. It might decide to serve the requests correctly anyway, or
853 reject them with an error. Plugins can avoid this complexity by using
854 L<nbdkit-blocksize-policy-filter(1)> which allows both
855 setting/adjusting the constraints, and selecting an error policy.
857 The minimum block size must be E<ge> 1. The maximum block size must
858 be E<le> 0xffff_ffff. minimum E<le> preferred E<le> maximum.
860 As a special case, the plugin may return minimum == preferred ==
861 maximum == 0, meaning no information.
863 If this callback is not used, then the NBD protocol assumes by default
864 minimum = 1, preferred = 4096. (Maximum block size depends on various
865 factors, see the NBD protocol specification, section "Block size
870 int can_write (void *handle);
872 This is called during the option negotiation phase to find out if the
873 handle supports writes.
875 If there is an error, C<.can_write> should call C<nbdkit_error> with
876 an error message and return C<-1>.
878 This callback is not required. If omitted, then we return true iff a
879 C<.pwrite> callback has been defined.
883 int can_flush (void *handle);
885 This is called during the option negotiation phase to find out if the
886 handle supports the flush-to-disk operation.
888 If there is an error, C<.can_flush> should call C<nbdkit_error> with
889 an error message and return C<-1>.
891 This callback is not required. If omitted, then we return true iff a
892 C<.flush> callback has been defined.
894 =head2 C<.is_rotational>
896 int is_rotational (void *handle);
898 This is called during the option negotiation phase to find out if the
899 backing disk is a rotational medium (like a traditional hard disk) or
900 not (like an SSD). If true, this may cause the client to reorder
901 requests to make them more efficient for a slow rotating disk.
903 If there is an error, C<.is_rotational> should call C<nbdkit_error>
904 with an error message and return C<-1>.
906 This callback is not required. If omitted, then we return false.
910 int can_trim (void *handle);
912 This is called during the option negotiation phase to find out if the
913 plugin supports the trim/discard operation for punching holes in the
916 If there is an error, C<.can_trim> should call C<nbdkit_error> with an
917 error message and return C<-1>.
919 This callback is not required. If omitted, then we return true iff a
920 C<.trim> callback has been defined.
924 int can_zero (void *handle);
926 This is called during the option negotiation phase to find out if the
927 plugin wants the C<.zero> callback to be utilized. Support for
928 writing zeroes is still advertised to the client (unless the
929 L<nbdkit-nozero-filter(1)> is also used), so returning false merely
930 serves as a way to avoid complicating the C<.zero> callback to have to
931 fail with C<ENOTSUP> or C<EOPNOTSUPP> on the connections where it will
932 never be more efficient than using C<.pwrite> up front.
934 If there is an error, C<.can_zero> should call C<nbdkit_error> with an
935 error message and return C<-1>.
937 This callback is not required. If omitted, then for a normal zero
938 request, nbdkit always tries C<.zero> first if it is present, and
939 gracefully falls back to C<.pwrite> if C<.zero> was absent or failed
940 with C<ENOTSUP> or C<EOPNOTSUPP>.
942 =head2 C<.can_fast_zero>
944 int can_fast_zero (void *handle);
946 This is called during the option negotiation phase to find out if the
947 plugin wants to advertise support for fast zero requests. If this
948 support is not advertised, a client cannot attempt fast zero requests,
949 and has no way to tell if writing zeroes offers any speedups compared
950 to using C<.pwrite> (other than compressed network traffic). If
951 support is advertised, then C<.zero> will have
952 C<NBDKIT_FLAG_FAST_ZERO> set when the client has requested a fast
953 zero, in which case the plugin must fail with C<ENOTSUP> or
954 C<EOPNOTSUPP> up front if the request would not offer any benefits
955 over C<.pwrite>. Advertising support for fast zero requests does not
956 require that writing zeroes be fast, only that the result (whether
957 success or failure) is fast, so this should be advertised when
960 If there is an error, C<.can_fast_zero> should call C<nbdkit_error>
961 with an error message and return C<-1>.
963 This callback is not required. If omitted, then nbdkit returns true
964 if C<.zero> is absent or C<.can_zero> returns false (in those cases,
965 nbdkit fails all fast zero requests, as its fallback to C<.pwrite> is
966 not inherently faster), otherwise false (since it cannot be determined
967 in advance if the plugin's C<.zero> will properly honor the semantics
968 of C<NBDKIT_FLAG_FAST_ZERO>).
970 =head2 C<.can_extents>
972 int can_extents (void *handle);
974 This is called during the option negotiation phase to find out if the
975 plugin supports detecting allocated (non-sparse) regions of the disk
976 with the C<.extents> callback.
978 If there is an error, C<.can_extents> should call C<nbdkit_error> with
979 an error message and return C<-1>.
981 This callback is not required. If omitted, then we return true iff a
982 C<.extents> callback has been defined.
986 int can_fua (void *handle);
988 This is called during the option negotiation phase to find out if the
989 plugin supports the Forced Unit Access (FUA) flag on write, zero, and
990 trim requests. If this returns C<NBDKIT_FUA_NONE>, FUA support is not
991 advertised to the client; if this returns C<NBDKIT_FUA_EMULATE>, the
992 C<.flush> callback must work (even if C<.can_flush> returns false),
993 and FUA support is emulated by calling C<.flush> after any write
994 operation; if this returns C<NBDKIT_FUA_NATIVE>, then the C<.pwrite>,
995 C<.zero>, and C<.trim> callbacks (if implemented) must handle the flag
996 C<NBDKIT_FLAG_FUA>, by not returning until that action has landed in
999 If there is an error, C<.can_fua> should call C<nbdkit_error> with an
1000 error message and return C<-1>.
1002 This callback is not required unless a plugin wants to specifically
1003 handle FUA requests. If omitted, nbdkit checks whether C<.flush>
1004 exists, and behaves as if this function returns C<NBDKIT_FUA_NONE> or
1005 C<NBDKIT_FUA_EMULATE> as appropriate.
1007 =head2 C<.can_multi_conn>
1009 int can_multi_conn (void *handle);
1011 This is called during the option negotiation phase to find out if the
1012 plugin is prepared to handle multiple connections from a single
1013 client. If the plugin sets this to true then a client may try to open
1014 multiple connections to the nbdkit server and spread requests across
1015 all connections to maximize parallelism. If the plugin sets it to
1016 false (which is the default) then well-behaved clients should only
1017 open a single connection, although we cannot control what clients do
1020 Specifically it means that either the plugin does not cache requests
1021 at all. Or if it does cache them then the effects of a C<.flush>
1022 request or setting C<NBDKIT_FLAG_FUA> on a request must be visible
1023 across all connections to the plugin before the plugin replies to that
1026 Properly working clients should send the same export name for each of
1029 If you use Linux L<nbd-client(8)> option S<I<-C num>> with
1030 S<num E<gt> 1> then Linux checks this flag and will refuse to connect
1031 if C<.can_multi_conn> is false.
1033 If there is an error, C<.can_multi_conn> should call C<nbdkit_error>
1034 with an error message and return C<-1>.
1036 This callback is not required. If omitted, then we return false.
1038 =head2 C<.can_cache>
1040 int can_cache (void *handle);
1042 This is called during the option negotiation phase to find out if the
1043 plugin supports a cache or prefetch operation.
1049 =item C<NBDKIT_CACHE_NONE>
1051 Cache support is not advertised to the client.
1053 =item C<NBDKIT_CACHE_EMULATE>
1055 Caching is emulated by the server calling C<.pread> and discarding the
1058 =item C<NBDKIT_CACHE_NATIVE>
1060 Cache support is advertised to the client. The C<.cache> callback will
1061 be called if it exists, otherwise all cache requests instantly succeed.
1065 If there is an error, C<.can_cache> should call C<nbdkit_error> with
1066 an error message and return C<-1>.
1068 This callback is not required. If omitted, then we return
1069 C<NBDKIT_CACHE_NONE> if the C<.cache> callback is missing, or
1070 C<NBDKIT_CACHE_NATIVE> if it is defined.
1074 int pread (void *handle, void *buf, uint32_t count, uint64_t offset,
1077 During the data serving phase, nbdkit calls this callback to read data
1078 from the backing store. C<count> bytes starting at C<offset> in the
1079 backing store should be read and copied into C<buf>. nbdkit takes
1080 care of all bounds- and sanity-checking, so the plugin does not need
1081 to worry about that.
1083 The parameter C<flags> exists in case of future NBD protocol
1084 extensions; at this time, it will be 0 on input.
1086 The callback must read the whole C<count> bytes if it can. The NBD
1087 protocol doesn't allow partial reads (instead, these would be errors).
1088 If the whole C<count> bytes was read, the callback should return C<0>
1089 to indicate there was I<no> error.
1091 If there is an error (including a short read which couldn't be
1092 recovered from), C<.pread> should call C<nbdkit_error> with an error
1093 message, and C<nbdkit_set_error> to record an appropriate error
1094 (unless C<errno> is sufficient), then return C<-1>.
1098 int pwrite (void *handle, const void *buf, uint32_t count, uint64_t offset,
1101 During the data serving phase, nbdkit calls this callback to write
1102 data to the backing store. C<count> bytes starting at C<offset> in
1103 the backing store should be written using the data in C<buf>. nbdkit
1104 takes care of all bounds- and sanity-checking, so the plugin does not
1105 need to worry about that.
1107 This function will not be called if C<.can_write> returned false. The
1108 parameter C<flags> may include C<NBDKIT_FLAG_FUA> on input based on
1109 the result of C<.can_fua>.
1111 The callback must write the whole C<count> bytes if it can. The NBD
1112 protocol doesn't allow partial writes (instead, these would be
1113 errors). If the whole C<count> bytes was written successfully, the
1114 callback should return C<0> to indicate there was I<no> error.
1116 If there is an error (including a short write which couldn't be
1117 recovered from), C<.pwrite> should call C<nbdkit_error> with an error
1118 message, and C<nbdkit_set_error> to record an appropriate error
1119 (unless C<errno> is sufficient), then return C<-1>.
1123 int flush (void *handle, uint32_t flags);
1125 During the data serving phase, this callback is used to
1126 L<fdatasync(2)> the backing store, ie. to ensure it has been
1127 completely written to a permanent medium. If that is not possible
1128 then you can omit this callback.
1130 This function will not be called directly by the client if
1131 C<.can_flush> returned false; however, it may still be called by
1132 nbdkit if C<.can_fua> returned C<NBDKIT_FUA_EMULATE>. The parameter
1133 C<flags> exists in case of future NBD protocol extensions; at this
1134 time, it will be 0 on input.
1136 If there is an error, C<.flush> should call C<nbdkit_error> with an
1137 error message, and C<nbdkit_set_error> to record an appropriate error
1138 (unless C<errno> is sufficient), then return C<-1>.
1142 int trim (void *handle, uint32_t count, uint64_t offset, uint32_t flags);
1144 During the data serving phase, this callback is used to "punch holes"
1145 in the backing store. If that is not possible then you can omit this
1148 This function will not be called if C<.can_trim> returned false. The
1149 parameter C<flags> may include C<NBDKIT_FLAG_FUA> on input based on
1150 the result of C<.can_fua>.
1152 If there is an error, C<.trim> should call C<nbdkit_error> with an
1153 error message, and C<nbdkit_set_error> to record an appropriate error
1154 (unless C<errno> is sufficient), then return C<-1>.
1158 int zero (void *handle, uint32_t count, uint64_t offset, uint32_t flags);
1160 During the data serving phase, this callback is used to write C<count>
1161 bytes of zeroes at C<offset> in the backing store.
1163 This function will not be called if C<.can_zero> returned false. On
1164 input, the parameter C<flags> may include C<NBDKIT_FLAG_MAY_TRIM>
1165 unconditionally, C<NBDKIT_FLAG_FUA> based on the result of
1166 C<.can_fua>, and C<NBDKIT_FLAG_FAST_ZERO> based on the result of
1169 If C<NBDKIT_FLAG_MAY_TRIM> is requested, the operation can punch a
1170 hole instead of writing actual zero bytes, but only if subsequent
1171 reads from the hole read as zeroes.
1173 If C<NBDKIT_FLAG_FAST_ZERO> is requested, the plugin must decide up
1174 front if the implementation is likely to be faster than a
1175 corresponding C<.pwrite>; if not, then it must immediately fail with
1176 C<ENOTSUP> or C<EOPNOTSUPP> (whether by C<nbdkit_set_error> or
1177 C<errno>) and preferably without modifying the exported image. It is
1178 acceptable to always fail a fast zero request (as a fast failure is
1179 better than attempting the write only to find out after the fact that
1180 it was not fast after all). Note that on Linux, support for
1181 C<ioctl(BLKZEROOUT)> is insufficient for determining whether a zero
1182 request to a block device will be fast (because the kernel will
1183 perform a slow fallback when needed).
1185 The callback must write the whole C<count> bytes if it can. The NBD
1186 protocol doesn't allow partial writes (instead, these would be
1187 errors). If the whole C<count> bytes was written successfully, the
1188 callback should return C<0> to indicate there was I<no> error.
1190 If there is an error, C<.zero> should call C<nbdkit_error> with an
1191 error message, and C<nbdkit_set_error> to record an appropriate error
1192 (unless C<errno> is sufficient), then return C<-1>.
1194 If this callback is omitted, or if it fails with C<ENOTSUP> or
1195 C<EOPNOTSUPP> (whether by C<nbdkit_set_error> or C<errno>), then
1196 C<.pwrite> will be used as an automatic fallback except when the
1197 client requested a fast zero.
1201 int extents (void *handle, uint32_t count, uint64_t offset,
1202 uint32_t flags, struct nbdkit_extents *extents);
1204 During the data serving phase, this callback is used to detect
1205 allocated, sparse and zeroed regions of the disk.
1207 This function will not be called if C<.can_extents> returned false.
1208 nbdkit's default behaviour in this case is to treat the whole virtual
1209 disk as if it was allocated. Also, this function will not be called
1210 by a client that does not request structured replies (the I<--no-sr>
1211 option of nbdkit can be used to test behavior when C<.extents> is
1212 unavailable to the client).
1214 The callback should detect and return the list of extents overlapping
1215 the range C<[offset...offset+count-1]>. The C<extents> parameter
1216 points to an opaque object which the callback should fill in by
1217 calling C<nbdkit_add_extent>. See L</Extents list> below.
1219 If there is an error, C<.extents> should call C<nbdkit_error> with an
1220 error message, and C<nbdkit_set_error> to record an appropriate error
1221 (unless C<errno> is sufficient), then return C<-1>.
1225 The plugin C<extents> callback is passed an opaque pointer C<struct
1226 nbdkit_extents *extents>. This structure represents a list of
1227 L<filesystem extents|https://en.wikipedia.org/wiki/Extent_(file_systems)>
1228 describing which areas of the disk are allocated, which are sparse
1229 (“holes”), and, if supported, which are zeroes.
1231 The C<extents> callback should scan the disk starting at C<offset> and
1232 call C<nbdkit_add_extent> for each extent found.
1234 Extents overlapping the range C<[offset...offset+count-1]> should be
1235 returned if possible. However nbdkit ignores extents E<lt> offset so
1236 the plugin may, if it is easier to implement, return all extent
1237 information for the whole disk. The plugin may return extents beyond
1238 the end of the range. It may also return extent information for less
1239 than the whole range, but it must return at least one extent
1240 overlapping C<offset>.
1242 The extents B<must> be added in ascending order, and B<must> be
1245 The C<flags> parameter of the C<.extents> callback may contain the
1246 flag C<NBDKIT_FLAG_REQ_ONE>. This means that the client is only
1247 requesting information about the extent overlapping C<offset>. The
1248 plugin may ignore this flag, or as an optimization it may return just
1249 a single extent for C<offset>.
1251 int nbdkit_add_extent (struct nbdkit_extents *extents,
1252 uint64_t offset, uint64_t length, uint32_t type);
1254 Add an extent covering C<[offset...offset+length-1]> of one of
1255 the following four types:
1261 A normal, allocated data extent.
1263 =item C<type = NBDKIT_EXTENT_HOLE|NBDKIT_EXTENT_ZERO>
1265 An unallocated extent, a.k.a. a “hole”, which reads back as zeroes.
1266 This is the normal type of hole applicable to most disks.
1268 =item C<type = NBDKIT_EXTENT_ZERO>
1270 An allocated extent which is known to contain only zeroes.
1272 =item C<type = NBDKIT_EXTENT_HOLE>
1274 An unallocated extent (hole) which does not read back as zeroes. Note
1275 this should only be used in specialized circumstances such as when
1276 writing a plugin for (or to emulate) certain SCSI drives which do not
1277 guarantee that trimmed blocks read back as zeroes.
1281 C<nbdkit_add_extent> returns C<0> on success or C<-1> on failure. On
1282 failure C<nbdkit_error> and/or C<nbdkit_set_error> has already been
1283 called. C<errno> will be set to a suitable value.
1287 int cache (void *handle, uint32_t count, uint64_t offset, uint32_t flags);
1289 During the data serving phase, this callback is used to give the
1290 plugin a hint that the client intends to make further accesses to the
1291 given region of the export.
1293 The nature of caching/prefetching is not specified further by the NBD
1294 specification. For example, a server may place limits on how much may
1295 be cached at once, and there is no way to control if writes to a
1296 cached area have write-through or write-back semantics. In fact, the
1297 cache command can always fail and still be compliant, and success
1298 might not guarantee a performance gain.
1300 If this callback is omitted, then the results of C<.can_cache>
1301 determine whether nbdkit will reject cache requests, treat them as
1302 instant success, or emulate caching by calling C<.pread> over the same
1303 region and ignoring the results.
1305 This function will not be called if C<.can_cache> did not return
1306 C<NBDKIT_CACHE_NATIVE>.
1308 The C<flags> parameter exists in case of future NBD protocol
1309 extensions; at this time, it will be 0 on input. A plugin must fail
1310 this function if C<flags> includes an unrecognized flag, as that may
1311 indicate a requirement that the plugin must comply with to provide a
1312 specific caching semantic.
1314 If there is an error, C<.cache> should call C<nbdkit_error> with an
1315 error message, and C<nbdkit_set_error> to record an appropriate error
1316 (unless C<errno> is sufficient), then return C<-1>.
1318 =head2 C<.errno_is_preserved>
1320 This field defaults to 0; if non-zero, nbdkit can reliably use the
1321 value of C<errno> when a callback reports failure, rather than the
1322 plugin having to call C<nbdkit_set_error>.
1326 When nbdkit receives certain signals it will shut down (see
1327 L<nbdkit(1)/SIGNALS>). The server will wait for any currently running
1328 plugin callbacks to finish, call C<.close> on those connections, then
1329 call the C<.cleanup> and C<.unload> callbacks before unloading the
1332 Note that it's not guaranteed this can always happen (eg. the server
1333 might be killed by C<SIGKILL> or segfault).
1335 =head2 Requesting asynchronous shutdown
1337 Plugins and filters can call L<exit(3)> in the configuration phase
1338 (before and including C<.get_ready>, but not in connected callbacks).
1340 Once nbdkit has started serving connections, plugins and filters
1341 should not call L<exit(3)>. However they may instruct nbdkit to shut
1342 down by calling C<nbdkit_shutdown>, or to disconnect a single client
1343 by calling C<nbdkit_disconnect>:
1345 void nbdkit_shutdown (void);
1347 This function requests an asynchronous shutdown and returns (I<note>
1348 that it does I<not> exit the process immediately). It ensures that
1349 the plugin and all filters are unloaded cleanly which may take some
1350 time. Further callbacks from nbdkit into the plugin or filter may
1351 occur after you have called this.
1353 void nbdkit_disconnect (int force);
1355 This function requests that the current connection be disconnected
1356 (I<note> that it does not affect other connections, and the client may
1357 try to reconnect). It is only useful from connected callbacks (that
1358 is, after C<.open> and before C<.close>). If C<force> is true, nbdkit
1359 will disconnect the client immediately, and the client will not
1360 receive any response to the current command or any other commands in
1361 flight in parallel threads; otherwise, nbdkit will not accept any new
1362 commands from the client (failing all commands other than
1363 C<NBD_CMD_DISC> with C<ESHUTDOWN>), but will allow existing commands
1364 to complete gracefully. Either way, the next callback for the current
1365 connection should be C<.close>.
1367 =head1 PARSING COMMAND LINE PARAMETERS
1369 =head2 Parsing numbers
1371 There are several functions for parsing numbers. These all deal
1372 correctly with overflow, out of range and parse errors, and you should
1373 use them instead of unsafe functions like L<sscanf(3)>, L<atoi(3)> and
1376 int nbdkit_parse_int (const char *what, const char *str, int *r);
1377 int nbdkit_parse_unsigned (const char *what,
1378 const char *str, unsigned *r);
1379 int nbdkit_parse_int8_t (const char *what,
1380 const char *str, int8_t *r);
1381 int nbdkit_parse_uint8_t (const char *what,
1382 const char *str, uint8_t *r);
1383 int nbdkit_parse_int16_t (const char *what,
1384 const char *str, int16_t *r);
1385 int nbdkit_parse_uint16_t (const char *what,
1386 const char *str, uint16_t *r);
1387 int nbdkit_parse_int32_t (const char *what,
1388 const char *str, int32_t *r);
1389 int nbdkit_parse_uint32_t (const char *what,
1390 const char *str, uint32_t *r);
1391 int nbdkit_parse_int64_t (const char *what,
1392 const char *str, int64_t *r);
1393 int nbdkit_parse_uint64_t (const char *what,
1394 const char *str, uint64_t *r);
1396 Parse string C<str> into an integer of various types. These functions
1397 parse a decimal, hexadecimal (C<"0x...">) or octal (C<"0...">) number.
1399 On success the functions return C<0> and set C<*r> to the parsed value
1400 (unless C<*r == NULL> in which case the result is discarded). On
1401 error, C<nbdkit_error> is called and the functions return C<-1>. On
1402 error C<*r> is always unchanged.
1404 The C<what> parameter is printed in error messages to provide context.
1405 It should usually be a short descriptive string of what you are trying
1408 if (nbdkit_parse_int ("random seed", value, &seed) == -1)
1411 might print an error:
1413 random seed: could not parse number: "lalala"
1415 =head2 Parsing sizes
1417 Use the C<nbdkit_parse_size> utility function to parse human-readable
1418 size strings such as "100M" into the size in bytes.
1420 int64_t nbdkit_parse_size (const char *str);
1422 C<str> can be a string in a number of common formats. The function
1423 returns the size in bytes. If there was an error, it returns C<-1>.
1425 =head2 Parsing booleans
1427 Use the C<nbdkit_parse_bool> utility function to parse human-readable
1428 strings such as "on" into a boolean value.
1430 int nbdkit_parse_bool (const char *str);
1432 C<str> can be a string containing a case-insensitive form of various
1433 common toggle values. The function returns 0 or 1 if the parse was
1434 successful. If there was an error, it returns C<-1>.
1436 =head2 Reading passwords
1438 The C<nbdkit_read_password> utility function can be used to read
1439 passwords from config parameters:
1441 int nbdkit_read_password (const char *value, char **password);
1445 char *password = NULL;
1448 myplugin_config (const char *key, const char *value)
1451 if (strcmp (key, "password") == 0) {
1453 if (nbdkit_read_password (value, &password) == -1)
1459 The C<password> result string is allocated by malloc, and so you may
1462 This function recognizes several password formats. A password may be
1463 used directly on the command line, eg:
1465 nbdkit myplugin password=mostsecret
1467 But more securely this function can also read a password
1470 nbdkit myplugin password=-
1474 nbdkit myplugin password=+/tmp/secret
1476 or from a file descriptor inherited by nbdkit:
1478 nbdkit myplugin password=-99
1480 =head3 Notes on reading passwords
1482 If the password begins with a C<-> or C<+> character then it must be
1485 C<password=-> can only be used when stdin is a terminal.
1487 C<password=-FD> cannot be used with stdin, stdout or stderr
1488 (ie. C<-0>, C<-1> or C<-2>). The reason is that after reading the
1489 password the file descriptor is closed, which causes bad stuff to
1492 =head2 Safely interacting with stdin and stdout
1494 int nbdkit_stdio_safe (void);
1496 The C<nbdkit_stdio_safe> utility function returns C<1> if it is safe
1497 to interact with stdin and stdout during the configuration phase, and
1498 C<0> otherwise. This is because when the nbdkit I<-s> option is used
1499 the plugin must not directly interact with stdin, because that would
1500 interfere with the client.
1502 The result of this function only matters in callbacks up to
1503 C<.config_complete>. Once nbdkit reaches C<.get_ready>, the plugin
1504 should assume that nbdkit may have closed the original stdin and
1505 stdout in order to become a daemon.
1507 L<nbdkit-sh-plugin(3)> uses this function to determine whether it is
1508 safe to support C<script=-> to read a script from stdin. Also
1509 constructs like C<password=-> (see L</Reading passwords> above) are
1510 disabled when reading from stdio is not safe.
1512 =head1 FILENAMES AND PATHS
1514 The server usually (not always) changes directory to C</> before it
1515 starts serving connections. This means that any relative paths passed
1516 during configuration will not work when the server is running
1517 (example: S<C<nbdkit plugin.so disk.img>>).
1519 To avoid problems, prepend relative paths with the current directory
1520 before storing them in the handle. Or open files and store the file
1523 =head2 C<nbdkit_absolute_path>
1525 char *nbdkit_absolute_path (const char *filename);
1527 The utility function C<nbdkit_absolute_path> converts any path to an
1528 absolute path: if it is relative, then all this function does is
1529 prepend the current working directory to the path, with no extra
1532 Note that this function works I<only> when used in the C<.config>,
1533 C<.config_complete> and C<.get_ready> callbacks.
1535 If conversion was not possible, this calls C<nbdkit_error> and returns
1536 C<NULL>. Note that this function does not check that the file exists.
1538 The returned string must be freed by the caller.
1540 =head2 C<nbdkit_realpath>
1542 char *nbdkit_realpath (const char *filename);
1544 The utility function C<nbdkit_realpath> converts any path to an
1545 absolute path, resolving symlinks. Under the hood it uses the
1546 C<realpath> function, and thus it fails if the path does not exist,
1547 or it is not possible to access to any of the components of the path.
1549 Note that this function works I<only> when used in the C<.config>,
1550 C<.config_complete> and C<.get_ready> callbacks.
1552 If the path resolution was not possible, this calls C<nbdkit_error>
1553 and returns C<NULL>.
1555 The returned string must be freed by the caller.
1559 All plugins will see a L<umask(2)> of C<0022>.
1563 A plugin that needs to sleep may call L<sleep(2)>, L<nanosleep(2)> and
1564 similar. However that can cause nbdkit to delay excessively when
1565 shutting down (since it must wait for any plugin or filter which is
1566 sleeping). To avoid this there is a special wrapper around nanosleep
1567 which plugins and filters should use instead.
1569 =head2 C<nbdkit_nanosleep>
1571 int nbdkit_nanosleep (unsigned sec, unsigned nsec);
1573 The utility function C<nbdkit_nanosleep> suspends the current thread,
1574 and returns 0 if it slept at least as many seconds and nanoseconds as
1575 requested, or -1 after calling C<nbdkit_error> if there is no point in
1576 continuing the current command. Attempts to sleep more than
1577 C<INT_MAX> seconds are treated as an error.
1581 If the client negotiated an NBD export name with nbdkit then plugins
1582 may read this from any connected callbacks. Nbdkit's normal behaviour
1583 is to accept any export name passed by the client, log it in debug
1584 output, but otherwise ignore it. By using C<nbdkit_export_name>
1585 plugins may choose to filter by export name or serve different
1588 =head2 C<nbdkit_export_name>
1590 const char *nbdkit_export_name (void);
1592 Return the optional NBD export name if one was negotiated with the
1593 current client (this uses thread-local magic so no parameter is
1594 required). The returned string is valid at least through the
1595 C<.close> of the current connection, but if you need to store it
1596 in the plugin for use by more than one client you must copy it.
1598 The export name is a free-form text string, it is not necessarily a
1599 path or filename and it does not need to begin with a C<'/'>
1600 character. The NBD protocol describes the empty string (C<"">) as a
1601 representing a "default export" or to be used in cases where the
1602 export name does not make sense. B<The export name is untrusted
1603 client data, be cautious when parsing it.>
1605 On error, C<nbdkit_error> is called and the call returns C<NULL>.
1607 =head1 STRING LIFETIME
1609 Some callbacks are specified to return C<const char *>, even when a
1610 plugin may not have a suitable compile-time constant to return.
1611 Returning dynamically-allocated memory for such a callback would
1612 induce a memory leak or otherwise complicate the plugin to perform
1613 additional bookkeeping. For these cases, nbdkit provides several
1614 convenience functions for creating a copy of a string for better
1615 lifetime management.
1617 =head2 C<nbdkit_strdup_intern>
1619 =head2 C<nbdkit_strndup_intern>
1621 const char *nbdkit_strdup_intern (const char *str);
1622 const char *nbdkit_strndup_intern (const char *str, size_t n);
1624 Returns a copy of C<str>, possibly limited to a maximum of C<n> bytes,
1625 so that the caller may reclaim str and use the copy in its place. If
1626 the copy is created outside the scope of a connection (such as during
1627 C<.load> or C<.config>), the lifetime of the copy will last at least
1628 through C<.unload>. If the copy is created after a client has
1629 triggered a connection (such as during C<.preconnect> or C<.open>),
1630 the lifetime will last at least through C<.close>, but the copy is not
1631 safe to share with other connections.
1633 On error, C<nbdkit_error> is called and the call returns C<NULL>.
1635 =head2 C<nbdkit_printf_intern>
1637 =head2 C<nbdkit_vprintf_intern>
1639 const char *nbdkit_printf_intern (const char *fmt, ...);
1640 const char *nbdkit_vprintf_intern (const char *fmt, va_list ap);
1642 Return a string created from a format template, with a lifetime longer
1643 than the current connection. Shorthand for passing C<fmt> to
1644 L<asprintf(3)> on a temporary string, then passing that result to
1645 C<nbdkit_strdup_intern>.
1647 On error, C<nbdkit_error> is called and the call returns C<NULL>.
1649 =head1 AUTHENTICATION
1651 A server may use C<nbdkit_is_tls> to limit which export names work
1652 until after a client has completed TLS authentication. See
1653 L<nbdkit-tls(1)>. It is also possible to use
1654 L<nbdkit-tls-fallback-filter(1)> to automatically ensure that the
1655 plugin is only used with authentication.
1657 =head2 C<nbdkit_is_tls>
1659 int nbdkit_is_tls (void);
1661 Return true if the client has completed TLS authentication, or false
1662 if the connection is still plaintext.
1664 On error (such as calling this function outside of the context of
1665 C<.open>), C<nbdkit_error> is called and the call returns C<-1>.
1669 It is possible to get the source address of the client when you are
1670 running in any connected callback.
1672 =head2 C<nbdkit_peer_name>
1674 int nbdkit_peer_name (struct sockaddr *addr, socklen_t *addrlen);
1676 Return the peer (client) address, if available. The C<addr> and
1677 C<addrlen> parameters behave like L<getpeername(2)>. In particular
1678 you must initialize C<addrlen> with the size of the buffer pointed to
1679 by C<addr>, and if C<addr> is not large enough then the address will
1682 In some cases this is not available or the address returned will be
1683 meaningless (eg. if there is a proxy between the client and nbdkit).
1684 This call uses thread-local magic so no parameter is required to
1685 specify the current connection.
1687 On success this returns C<0>. On error, C<nbdkit_error> is called and
1688 this call returns C<-1>.
1690 =head2 C<nbdkit_peer_pid>
1692 (nbdkit E<ge> 1.24, Linux only)
1694 int64_t nbdkit_peer_pid (void);
1696 Return the peer process ID. This is only available when the client
1697 connected over a Unix domain socket.
1699 On success this returns the peer process ID. On error,
1700 C<nbdkit_error> is called and this call returns C<-1>.
1702 =head2 C<nbdkit_peer_uid>
1706 int64_t nbdkit_peer_uid (void);
1708 Return the peer user ID. This is only available when the client
1709 connected over a Unix domain socket.
1711 On success this returns the user ID. On error, C<nbdkit_error> is
1712 called and this call returns C<-1>.
1714 =head2 C<nbdkit_peer_gid>
1718 int64_t nbdkit_peer_gid (void);
1720 Return the peer group ID. This is only available when the client
1721 connected over a Unix domain socket.
1723 On success this returns the user ID. On error, C<nbdkit_error> is
1724 called and this call returns C<-1>.
1728 =head2 Compile-time version of nbdkit
1730 The macros C<NBDKIT_VERSION_MAJOR>, C<NBDKIT_VERSION_MINOR> and
1731 C<NBDKIT_VERSION_MICRO> expand to integers containing the version of
1732 the nbdkit headers that you are compiling against.
1734 C<NBDKIT_VERSION_MAJOR> is always 1. C<NBDKIT_VERSION_MINOR> is even
1735 for stable releases of nbdkit and odd for development releases.
1737 The macro C<NBDKIT_VERSION_STRING> expands to the same version as a
1740 =head2 Run-time version of nbdkit
1742 When the plugin is loaded into nbdkit, it may not be the same version
1743 that it was compiled against. nbdkit guarantees backwards
1744 compatibility of the API and ABI, so provided that nbdkit is the same
1745 version or newer, the plugin will still work. There is no way to get
1746 the version of nbdkit from the plugin.
1748 =head2 Version of the plugin
1750 The plugin itself can use any versioning scheme you want, and put any
1751 string into the C<.version> field of the plugin struct (or leave the
1756 See L</WRITING AN NBDKIT PLUGIN> above.
1760 Run the server with I<-f> and I<-v> options so it doesn't fork and you
1761 can see debugging information:
1763 nbdkit -fv ./myplugin.so [key=value [key=value [...]]]
1765 To print debugging information from within the plugin, call
1766 C<nbdkit_debug>, which has the following prototype and works like
1769 void nbdkit_debug (const char *fs, ...);
1770 void nbdkit_vdebug (const char *fs, va_list args);
1772 For convenience, C<nbdkit_debug> preserves the value of C<errno>, and
1773 also supports the glibc extension of a single C<%m> in a format string
1774 expanding to C<strerror(errno)>, even on platforms that don't support
1775 that natively. Note that C<nbdkit_debug> only prints things when the
1776 server is in verbose mode (I<-v> option).
1780 The I<-v> option switches general debugging on or off, and this
1781 debugging should be used for messages which are useful for all users
1784 In cases where you want to enable specific extra debugging to track
1785 down bugs in plugins or filters — mainly for use by the plugin/filter
1786 developers themselves — you can define Debug Flags. These are global
1787 ints called C<myplugin_debug_*>:
1789 int myplugin_debug_foo;
1790 int myplugin_debug_bar;
1792 if (myplugin_debug_foo) {
1793 nbdkit_debug ("lots of extra debugging about foo: ...");
1796 Debug Flags can be controlled on the command line using the I<-D> (or
1799 nbdkit -f -v -D myplugin.foo=1 -D myplugin.bar=2 myplugin [...]
1801 Note C<myplugin> is the name passed to C<.name> in the C<struct
1804 You should only use this feature for debug settings. For general
1805 settings use ordinary plugin parameters. Debug Flags can only be C
1806 ints. They are not supported by non-C language plugins.
1808 For convenience C<'.'> characters are replaced with C<'_'> characters
1809 in the variable name, so both of these parameters:
1811 -D myplugin.foo_bar=1
1812 -D myplugin.foo.bar=1
1814 correspond to the plugin variable C<myplugin_debug_foo_bar>.
1816 =head1 COMPILING THE PLUGIN
1818 Plugins should be compiled as shared libraries. There are various
1819 ways to achieve this, but most Linux compilers support a I<-shared>
1820 option to create the shared library directly, for example:
1822 gcc -fPIC -shared myplugin.c -o myplugin.so
1824 Note that the shared library will have undefined symbols for functions
1825 that you call like C<nbdkit_parse_int> or C<nbdkit_error>. These will
1826 be resolved by the server binary when nbdkit dlopens the plugin.
1828 =head2 PKG-CONFIG/PKGCONF
1830 nbdkit provides a pkg-config/pkgconf file called C<nbdkit.pc> which
1831 should be installed on the correct path when the nbdkit plugin
1832 development environment is installed. You can use this in autoconf
1833 F<configure.ac> scripts to test for the development environment:
1835 PKG_CHECK_MODULES([NBDKIT], [nbdkit >= 1.2.3])
1837 The above will fail unless nbdkit E<ge> 1.2.3 and the header file is
1838 installed, and will set C<NBDKIT_CFLAGS> and C<NBDKIT_LIBS>
1839 appropriately for compiling plugins.
1841 You can also run pkg-config/pkgconf directly, for example:
1843 if ! pkg-config nbdkit --exists; then
1844 echo "you must install the nbdkit plugin development environment"
1848 You can also substitute the plugindir variable by doing:
1850 PKG_CHECK_VAR([NBDKIT_PLUGINDIR], [nbdkit], [plugindir])
1852 which defines C<$(NBDKIT_PLUGINDIR)> in automake-generated Makefiles.
1854 If nbdkit development headers are installed in a non-standard location
1855 then you may need to compile plugins using:
1857 gcc -fPIC -shared myplugin.c -o myplugin.so \
1858 `pkg-config nbdkit --cflags --libs`
1860 =head1 INSTALLING THE PLUGIN
1862 The plugin is a C<*.so> file and possibly a manual page. You can of
1863 course install the plugin C<*.so> file wherever you want, and users
1864 will be able to use it by running:
1866 nbdkit /path/to/plugin.so [args]
1868 However B<if> the shared library has a name of the form
1869 C<nbdkit-I<name>-plugin.so> B<and if> the library is installed in the
1870 C<$plugindir> directory, then users can be run it by only typing:
1874 The location of the C<$plugindir> directory is set when nbdkit is
1875 compiled and can be found by doing:
1877 nbdkit --dump-config
1879 If using the pkg-config/pkgconf system then you can also find the
1880 plugin directory at compile time by doing:
1882 pkg-config nbdkit --variable=plugindir
1884 =head1 WRITING PLUGINS IN C++
1886 Plugins in C++ work almost exactly like those in C, but the way you
1887 define the C<nbdkit_plugin> struct is slightly different:
1890 nbdkit_plugin create_plugin() {
1891 nbdkit_plugin plugin = nbdkit_plugin ();
1892 plugin.name = "myplugin";
1893 plugin.open = myplugin_open;
1894 plugin.get_size = myplugin_get_size;
1895 plugin.pread = myplugin_pread;
1896 plugin.pwrite = myplugin_pwrite;
1900 static struct nbdkit_plugin plugin = create_plugin ();
1901 NBDKIT_REGISTER_PLUGIN(plugin)
1903 =head1 WRITING PLUGINS IN OTHER PROGRAMMING LANGUAGES
1905 You can also write nbdkit plugins in Go, Lua, OCaml, Perl, Python,
1906 Ruby, Rust, shell script or Tcl. Other programming languages may be
1909 For more information see:
1910 __LANG_PLUGIN_LINKS__.
1912 Plugins written in scripting languages may also be installed in
1913 C<$plugindir>. These must be called C<nbdkit-I<name>-plugin> without
1914 any extension. They must be executable, and they must use the shebang
1915 header (see L<nbdkit(1)/Shebang scripts>). For example a plugin
1916 written in Perl called C<foo.pl> might be installed like this:
1919 #!/usr/sbin/nbdkit perl
1923 $ sudo install -m 0755 foo.pl $plugindir/nbdkit-foo-plugin
1925 and then users will be able to run it like this:
1927 $ nbdkit foo [args ...]
1932 L<nbdkit-nozero-filter(1)>,
1933 L<nbdkit-tls-fallback-filter(1)>,
1934 L<nbdkit-filter(3)>.
1936 Standard plugins provided by nbdkit: