similar to: [nbdkit PATCH] filters: Bump API version

On Mon, Aug 26, 2019 at 12:15:27PM -0500, Eric Blake wrote: > We do not promise API compatibility for filters between stable > releases of nbdkit, however, we should at least ensure that when we do > break API, that we refuse to load a filter compiled against one > version of nbdkit with another server running a different API. A > single bump once per stable release is good enough

We documented our intent of only allowing a filter to run with the same version of nbdkit it was compiled against, but up to now, were not actually enforcing that - we had only been insisting on the looser notion of a matching ._api_version, which doesn't help when we've forgotten to bump that macro when making incompatible API/ABI changes (see commit 6934d4c1). However, we can't use

On 01/19/2018 09:23 AM, Richard W.M. Jones wrote: > Filters can be placed in front of plugins to modify their behaviour. > > This commit adds the <nbdkit-filter.h> header file, the manual page, > the ‘filterdir’ directory (like ‘plugindir’), the ‘filters/’ source > directory which will contain the actual filters, the ‘--filters’ > parameter, and the filters backend logic.

This is not intended for v1.14. In fact, we may decide that the second patch is too gross, although the first one still seems like a useful improvement in isolation. I will also point out that all our filters are in-tree, and set the user-controlled field .version to the current release string. We could replace the second patch with a simpler one that just checks ._api_version as an int (as

Another couple things I noticed that are worth improving, but aren't strictly related to implementing fast zero support. Eric Blake (2): server: Assert sane error responses nozero: More efficient FUA handling filters/nozero/nozero.c | 17 +++++++++++-- server/filters.c | 56 +++++++++++++++++++++++++++++++++-------- server/protocol.c | 32 +++++++++++++++++------ 3 files

On 3/20/19 5:11 PM, Richard W.M. Jones wrote: > This pair of calls allows plugins to describe which extents in the > virtual disk are allocated, holes or zeroes. > --- I see you've already made a couple of tweaks to your block-status branch since posting this (skipping 0-legnth add_extent, and coalescing consecutive add_extents with the same type), but here's some more review:

On Sat, Mar 23, 2019 at 11:25:06AM -0500, Eric Blake wrote: > On 3/20/19 5:11 PM, Richard W.M. Jones wrote: > > + myfilter_extents (...) > > + { > > + size_t i; > > + struct nbdkit_extents *extents2; > > + struct nbdkit_extent e; > > + > > + extents2 = nbdkit_extents_new (offset); > > + next_ops->extents (nxdata, count, offset, flags,

From: Yifan Gu <gyf304@gmail.com> This patch adds in indirection for API functions, as PE DLL loader does not resolve undefined symbols. This patch only includes header changes. --- include/nbdkit-common.h | 133 +++++++++++++++++++++++++++++++++++++++- include/nbdkit-compat.h | 97 +++++++++++++++++++++++++++++ include/nbdkit-filter.h | 39 ++++++++++++ include/nbdkit-plugin.h | 27

No need for filters to specify their model in two different ways; the callback alone is sufficient. Since all filters are in-tree, we can deal with the API/ABI change made here. Signed-off-by: Eric Blake <eblake@redhat.com> --- docs/nbdkit-filter.pod | 48 +++++++++++++++------------------ include/nbdkit-filter.h | 6 ++--- filters/cow/cow.c | 2 --

---------- Forwarded message ---------- From: Larry White <ljw1001@gmail.com> Date: May 23, 2006 10:35 AM Subject: filtering results in acts_as_tree To: rails@lists.rubyonrails.org I''m using a logical delete for a table and want to use acts_as_tree with it. Is there any way to filter the rows returned as the tree is traversed to include only those records where the deleted column

Hi! in the same problem with a select with some values from db: the following select in test.rhtml: <%= select(:listSetting, :code, @listSettings) %> where @listSettings = ListSetting.find(:all, :order => "code").map {|u| [u.code, u.id] } i have an observer_field defined in test.rhml as below: <%= observe_field("listSetting_code", :update =>

Fixes parallel piglit runs on fermi with boot clock speeds. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c b/drivers/gpu/drm/nouveau/nouveau_fence.c index 1e753b0..460dd00 100644 --- a/drivers/gpu/drm/nouveau/nouveau_fence.c +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c @@ -144,7 +144,7 @@

Ah, it's probably the compression that's breaking things... Do you also see errors in dmesg about LTCG? You can try turning it off by setting compressed = false in nvc0_miptree.c:nvc0_miptree_create. -ilia On Sun, May 18, 2014 at 1:51 PM, Sergei Antonov <saproj at gmail.com> wrote: > Hello! > I'm using NVIDIA GeForce GT 640M. And beginning with this commit: > >

Some adt7473 can't manage the 20?s delay we use for the bitbanging, bumping it to 40?s seem to do the trick. Signed-off-by: Martin Peres <martin.peres at free.fr> Tested-by: Marcel Dopita <mdop at seznam.cz> --- drivers/gpu/drm/nouveau/core/subdev/therm/ic.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/nouveau/core/subdev/therm/ic.c

Allows userspace to detect shared fences are supported. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- drivers/gpu/drm/nouveau/nouveau_drm.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) Dave, can you include this in drm-next? It should allow me to optimize nouveau's vdpau decoding a bit. diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.h

Op 2013-12-11 om 02:09 schreef syslinux-bot for Matt Fleming: > Commit-ID: 5e59ac11d6d105591d6da742750ea2f804534d43 > Gitweb: http://www.syslinux.org/commit/5e59ac11d6d105591d6da742750ea2f804534d43 > Author: Matt Fleming <matt.fleming at intel.com> > AuthorDate: Wed, 11 Dec 2013 10:03:13 +0000 > Committer: Matt Fleming <matt.fleming at intel.com> >

On 12/11/2013 11:52 AM, Geert Stappers wrote: > Op 2013-12-11 om 02:09 schreef syslinux-bot for Matt Fleming: >> Commit-ID: 5e59ac11d6d105591d6da742750ea2f804534d43 >> Gitweb: http://www.syslinux.org/commit/5e59ac11d6d105591d6da742750ea2f804534d43 >> Author: Matt Fleming <matt.fleming at intel.com> >> AuthorDate: Wed, 11 Dec 2013 10:03:13 +0000 >>

On 12/12/2013 12:31 AM, Ferenc Wagner wrote: > > Shall I rebase it to the current firmware head? > > Also, 5.2.3 was released a couple of days ago. It's a bugfix release. > I made it into a sepearete commit (pushed). > > Better default Lua paths (source and binary) would be useful. Shall I > mirror the Syslinux PATH at initialization, or use some static value? >

"H. Peter Anvin" <hpa at zytor.com> writes: > On 12/12/2013 12:31 AM, Ferenc Wagner wrote: > >> Shall I rebase it to the current firmware head? >> >> Also, 5.2.3 was released a couple of days ago. It's a bugfix release. >> I made it into a sepearete commit (pushed). >> >> Better default Lua paths (source and binary) would be

Op 2014-01-02 om 14:59 schreef Ferenc Wagner: > "H. Peter Anvin" <hpa at zytor.com> writes: > > > On 12/12/2013 12:31 AM, Ferenc Wagner wrote: > > > >> Shall I rebase it to the current firmware head? > >> > >> Also, 5.2.3 was released a couple of days ago. It's a bugfix release. > >> I made it into a sepearete commit