Displaying 20 results from an estimated 5000 matches similar to: "[nbdkit PATCH v2 0/5] .list_exports"
2020 Aug 25
9
[nbdkit PATCH 0/5] Implement .default_export, nbdkit_string_intern
More patches on the way for improving .list_exports signature and
adding .export_description, but this is the promised code showing
why nbdkit_string_intern is useful. Patch 4 is somewhat RFC: we
could either add new API to take the boilerplate from:
foo_config(const char *key, const char *value) {
if (strcmp (key, "file") == 0) {
CLEANUP_FREE char *tmp = nbdkit_realpath (value);
2020 Aug 27
10
[nbdkit PATCH v2 0/8] exportname filter
This is a revision of my .default_export work, plus new work on
.export_descriptions and a new exportname filter. I think it is
now ready to check in.
Things I'd still like in 1.22:
- the file plugin should implement .list_exports (patch already posted,
but it needs rebasing on this series)
- the ext2 filter should override .list_exports when in exportname mode
- the nbd plugin should be
2020 Sep 21
18
[nbdkit PATCH v3 00/14] exportname filter
It's been several weeks since I posted v2 (I got distracted by
improving libnbd to better test things, which in turn surfaced some
major memory leak problems in nbdsh that are now fixed). Many of the
patches are minor rebases from v2, with the biggest changes being
fallout from:
- patch 2: rename nbdkit_add_default_export to nbdkit_use_default_export
- overall: this missed 1.22, so update
2020 Jul 31
6
[RFC nbdkit PATCH 0/4] Progress towards .list_exports
This takes Rich's API proposal and starts fleshing it out with enough
meat that I was able to test 'nbdkit eval' advertising multiple
exports with descriptions paired with 'qemu-nbd --list'.
Eric Blake (3):
server: Add exports list functions
server: Prepare to use export list from plugin
sh, eval: Add .list_exports support
Richard W.M. Jones (1):
server: Implement
2020 Aug 27
4
[PATCH nbdkit 0/2] Temporarily remove .list_exports for nbdkit 1.22
If you're following nbdkit development upstream you'll have seen that
we are still making changes to the .list_exports and related APIs.
The current .list_exports API upstream is not how it will look
finally. The latest set of proposals was here:
https://www.redhat.com/archives/libguestfs/2020-August/thread.html#00330
At the same time I'd like to do an nbdkit 1.22 (stable) release.
2020 Jul 22
3
[PATCH nbdkit v2] PROPOSED: server: Implement list_exports.
Updated proposal, taking into account the default export. Instead of
adding a second call, I made a couple of changes to list_exports:
(1) If the plugin has a concept of a default export, it should add it
as the first element in the exports list.
(2) There is a new default_only flag which tells the plugin that the
client is trying to request the name of the default export, so the
2020 Aug 24
3
[RFC nbdkit PATCH] protocol: Alter .list_exports, add .default_export
I'm about to add an 'exportname' filter, and in the process, I
noticed a few shortcomings in our API. Time to fix those before
the 1.22 release locks our API in stone. First, .list_exports
needs to know if it is pre- or post-TLS, as that may affect which
names are exported. Next, overloading .list_exports to do both
NBD_OPT_LIST and mapping "" to a canonical name is
2020 Aug 07
8
[nbdkit PATCH 0/4] More .list_exports uses
Here's changes to the file plugin (which I'm happy with) and a new
exportname filter (which is still at RFC stage; I need to finish
implementing strict mode in .open, and add tests).
I also discovered that we really want .list_exports and .open to know
when they are used on plaintext vs. tls clients for --tls=on, and we
may want to split out a new .default_export callback rather than
2020 Aug 27
2
Re: [nbdkit PATCH v2 2/8] api: Add nbdkit_add_default_export
On Wed, Aug 26, 2020 at 09:16:46PM -0500, Eric Blake wrote:
> Rather than defaulting .list_exports to blindly returning "", it is
> nicer to have it reflect the result of .default_export. Meanwhile,
> language bindings will have a C callback for both .list_exports and
> .default_export, even if the underlying script does not, which means
> any logic in plugins.c for
2020 Sep 01
4
[nbdkit PATCH 0/2] More language bindings for .list_exports
This picks up python and ocaml. Some of our languages are lacking a
number of bindings (for example, lua and perl lack .extents, so I
didn't have anything to copy from), and I felt less comfortable with
golang and rust. But for python and ocaml, I was able to test a
working implementation.
Eric Blake (2):
python: Implement .list_exports and friends
ocaml: Implement .list_exports and
2020 Aug 25
0
[nbdkit PATCH 1/5] api: Add .default_export
I'm about to add an 'exportname' filter, and in the process, I noticed
a few shortcomings in our API. Time to fix those before the 1.22
release locks our API in stone. Overloading .list_exports in order to
determine a canonical export name at .open time is awkward; the two
uses (answering NBD_OPT_LIST for a full list, vs. remapping a client's
"" into a canonical name
2020 Aug 03
1
Re: [nbdkit PATCH 3/4] server: Implement list_exports.
On 7/31/20 5:22 PM, Eric Blake wrote:
> From: "Richard W.M. Jones" <rjones@redhat.com>
>
> See also:
> https://www.redhat.com/archives/libguestfs/2020-July/msg00090.html
> Message-Id: <20200722124201.1823468-2-rjones@redhat.com>
>
> For now, this implementation is only for plugins; adding filter
> support will come later (and probably requires
2020 Aug 07
7
[nbdkit PATCH 0/3] Content differentiation during --tls=on
Patch 3 still needs tests added, but it is at least working from
my simple command line tests.
Eric Blake (3):
server: Implement nbdkit_is_tls for use during .open
server: Expose final thread_model to filter's .get_ready
tlsdummy: New filter
docs/nbdkit-filter.pod | 21 +-
docs/nbdkit-plugin.pod | 34 ++-
docs/nbdkit-tls.pod
2020 Aug 14
2
[PATCH nbdkit] New ondemand plugin.
This creates filesystems on demand. A client simply connects with a
desired export name and a new export is created. The export is
persistent (until deleted by the server admin), and clients may
disconnect and reconnect. In some respects this is similar to the
nbdkit-tmpdisk-plugin, or nbdkit-file-plugin with the dir= option.
---
plugins/ondemand/nbdkit-ondemand-plugin.pod | 190 ++++++
2020 Aug 27
0
[PATCH nbdkit 2/2] api: Remove .list_exports from nbdkit 1.22 release.
During the 1.21 development cycle we added support for listing
exports. However at the time that 1.22 was released we did not feel
the API was sufficiently finalized to commit to in a stable branch.
Therefore this new API was removed before 1.22 was released, but the
feature continues to be developed upstream and should appear in
nbdkit 1.24.
Note this also hides the nbdkit*export* functions so
2020 Sep 01
3
Re: [nbdkit PATCH 2/2] ocaml: Implement .list_exports and friends
On 9/1/20 8:25 AM, Eric Blake wrote:
> Fairly straightforward. I'd love for type export to be a bit more
> flexible to make description optional, but could not figure out how to
> decode that from the C side of things, so for now this just requires
> the caller to supply a description for all exports during
> .list_exports.
>
Maybe I did figure it out after all, although
2020 Aug 27
0
[nbdkit PATCH v2 2/8] api: Add nbdkit_add_default_export
Rather than defaulting .list_exports to blindly returning "", it is
nicer to have it reflect the result of .default_export. Meanwhile,
language bindings will have a C callback for both .list_exports and
.default_export, even if the underlying script does not, which means
any logic in plugins.c for calling .default_export when .list_export
is missing would have to be duplicated in each
2020 Jul 30
3
Re: [PATCH nbdkit v2] PROPOSED: server: Implement list_exports.
On 7/22/20 7:42 AM, Richard W.M. Jones wrote:
> See also:
> https://www.redhat.com/archives/libguestfs/2020-July/msg00090.html
> ---
> docs/nbdkit-plugin.pod | 57 +++++++++++++++++++++++++++++++++++++---
> docs/nbdkit-protocol.pod | 7 +++--
> 2 files changed, 58 insertions(+), 6 deletions(-)
I'm playing with code for an initial implementation of this, and quickly
2020 Aug 25
2
Re: [RFC nbdkit PATCH] protocol: Alter .list_exports, add .default_export
On Mon, Aug 24, 2020 at 05:02:56PM -0500, Eric Blake wrote:
> On 8/24/20 7:52 AM, Eric Blake wrote:
> >I'm about to add an 'exportname' filter, and in the process, I
> >noticed a few shortcomings in our API. Time to fix those before
> >the 1.22 release locks our API in stone. First, .list_exports
> >needs to know if it is pre- or post-TLS, as that may
2020 Aug 07
1
Re: [nbdkit RFC PATCH 4/4] exportname: New filter
On Thu, Aug 06, 2020 at 09:23:48PM -0500, Eric Blake wrote:
> Add a new filter to make it easier to add exports to a plugin that
> does advertise them, to avoid advertising where a plugin's list might
does *not* advertise them(?)
> be an information leak, and to alter which export name is used in
> place of "".
>
> I would love to be able to have a strict mode