similar to: Preliminary release notes for nbdkit 1.22

$SUBJECT here ... https://github.com/libguestfs/libguestfs/blob/master/docs/guestfs-release-notes-1.50.pod https://github.com/rwmjones/guestfs-tools/blob/master/docs/guestfs-tools-release-notes-1.50.pod Any extra stuff that's pending for either project that isn't too invasive for 1.50, then let me know. By the way this will be the 28th major release of libguestfs. Depending on how

--- docs/nbdkit-release-notes-1.22.pod | 6 ------ 1 file changed, 6 deletions(-) diff --git a/docs/nbdkit-release-notes-1.22.pod b/docs/nbdkit-release-notes-1.22.pod index f84e0e12..20af7ea3 100644 --- a/docs/nbdkit-release-notes-1.22.pod +++ b/docs/nbdkit-release-notes-1.22.pod @@ -165,12 +165,6 @@ New API C<nbdkit_extents_aligned> is a helper function for filters that retrieves extents

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

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

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

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 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 enforcing that .open is called only with an export name that the plugin was willing to advertise, but for that, we'll

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

On Wed, Jul 22, 2020 at 06:12:30AM -0500, Eric Blake wrote: > On 7/22/20 4:02 AM, Richard W.M. Jones wrote: > >Perhaps we should have a rule something like this: > > > > - plugins should serve default content on the "" export > > > > - unless they implement .list_exports, in which case the > > first export returned is the default export >

Use the recently added nbdkit_string_intern to make this possible. Testsuite coverage is added in both tls-fallback as well as a cleanup to test-eval-exports.sh. Signed-off-by: Eric Blake <eblake@redhat.com> --- plugins/eval/nbdkit-eval-plugin.pod | 2 ++ plugins/sh/nbdkit-sh-plugin.pod | 20 +++++++++-- plugins/sh/methods.h | 1 + plugins/eval/eval.c |

On 8/27/20 2:57 AM, Richard W.M. Jones wrote: > 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

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

On Mon, Feb 10, 2020 at 01:52:25PM -0600, Eric Blake wrote: > On 2/10/20 1:39 PM, Richard W.M. Jones wrote: > >https://github.com/libguestfs/nbdkit/blob/ecef5b16359fb5af7e7abf4fd2fb3ad5438b16be/TODO#L76 > > > >Already existing filters (readahead, cache) could be improved if > >filters could open a background work thread or threads which connect > >independently to

On Tue, Jan 31, 2023 at 06:36:04PM +0000, Richard W.M. Jones wrote: > > $SUBJECT here ... > > https://github.com/libguestfs/libguestfs/blob/master/docs/guestfs-release-notes-1.50.pod Currently contains a pod error: https://github.com/libguestfs/libguestfs/blob/master/docs/guestfs-release-notes-1.50.pod#pod-errors I presume there's a way to mark the .pod file, or at least

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

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 affect which > names are exported. Next, overloading .list_exports to do both >

On 8/27/20 7:29 AM, Richard W.M. Jones wrote: > 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

I'm about to add an 'exportname' filter, and in the process, I noticed a few shortcomings in our API. Having .default_export makes it easy to answer NBD_INFO_NAME in response to a client request during NBD_OPT_GO, but answering NBD_INFO_DESCRIPTION is awkward - there's no guarantee the export name was given with a description in .list_exports. Note, however, that while we map

On Thu, Apr 23, 2020 at 10:03:45AM +0100, Richard W.M. Jones wrote: > On Tue, Apr 21, 2020 at 05:07:43PM +0100, Daniel P. Berrangé wrote: > > On Tue, Apr 21, 2020 at 11:44:59AM +0100, Richard W.M. Jones wrote: > > > Thanks: Dan Berrangé > > > > > > XXX UNFINISHED: > > > > > > - Is using uintptr for the handle a good idea? Plugins must

On Wed, Aug 26, 2020 at 09:16:48PM -0500, Eric Blake wrote: > Implementing .default_export with its 'const char *' return is tricky > in the sh plugin: we must return dynamic memory, but must avoid a > use-after-free. And we don't want to change the return type of > .default_export to 'char *', because that would make our choice of > malloc()/free() part of the

On Wed, Mar 06, 2019 at 09:59:33AM -0600, Eric Blake wrote: > On 3/6/19 9:40 AM, Richard W.M. Jones wrote: > > --- > > plugins/curl/nbdkit-curl-plugin.pod | 22 +- > > plugins/ssh/nbdkit-ssh-plugin.pod | 150 ++++++++ > > configure.ac | 17 + > > plugins/ssh/ssh.c | 521 ++++++++++++++++++++++++++++ > > README