search for: fileoper

Needs some work still, see in particular the commit message for patch 3. Rich.

Writing "file-like" plugins is hard because you have to implement your own .zero, .trim, .extents, etc, and that is very complicated. However implementations of these functions already exist in the file plugin. By factoring out the file plugin into a separate "fileops" mini-library we can reuse these implementations in other plugins. This refactoring commit creates a new

There's a lot of code in nbdkit-file-plugin which it would be nice to reuse elsewhere. One possible approach (as outlined here) is simply to move the file callbacks (like file.pread, file.pwrite, file.zero etc) to a new mini-library. They can then be consumed by other plugins fairly easily by doing: static void * foo_open (int readonly) { struct fileops *fops; int fd, flags; /*

The plugin should now support pre-fetch and extents, although most ISO images will be non-sparse so extents probably isn't that useful. --- plugins/iso/Makefile.am | 4 +- plugins/iso/iso.c | 99 +++++++++++++++++++---------------------- 2 files changed, 48 insertions(+), 55 deletions(-) diff --git a/plugins/iso/Makefile.am b/plugins/iso/Makefile.am index a0fd337a..44ecbc8a 100644 ---

This plugin now implements efficient zeroing, pre-fetch and extents, which should give quite a performance boost. XXX On the flip side, it no longer ignores flush and FUA (which we can ignore because these are temporary disks), which very likely has a large negative impact on performance. Fixing this would involve generalising fileops a little. --- plugins/tmpdisk/Makefile.am | 2 +

On 4/9/20 3:36 AM, Richard W.M. Jones wrote: > The plugin should now support pre-fetch and extents, although most ISO > images will be non-sparse so extents probably isn't that useful. True, but it can't hurt ;) > --- > plugins/iso/Makefile.am | 4 +- > plugins/iso/iso.c | 99 +++++++++++++++++++---------------------- > 2 files changed, 48 insertions(+), 55

On 4/9/20 4:27 PM, Eric Blake wrote: > On 4/9/20 3:36 AM, Richard W.M. Jones wrote: >> The plugin should now support pre-fetch and extents, although most ISO >> images will be non-sparse so extents probably isn't that useful. > > True, but it can't hurt ;) > >> --- >>   plugins/iso/Makefile.am |  4 +- >>   plugins/iso/iso.c       | 99

Well, that wasn't as nasty as I feared it would be. Turns out that in the general case it's possible to partition a mixed-branch revision into branch cliques and generate multiple import-stream commits, one for each affected branch. We lose only if the split commit is the source of a later directory copy; I have a check for that that says, basically, "if you see this fatal error,

Hi all, I experienced some test failures under Linux, probably caused by r232936: In the test SanitizerCommon-Unit :: Sanitizer-i386-Test/MemoryMappingLayout.CodeRange the temporary test file was opened write-only, but was read from, what subsequently failed: Note: Google Test filter = MemoryMappingLayout.CodeRange [==========] Running 1 test from 1 test case. [----------] Global test

I can reproduce your list of missing files; I've written a make production to generate it. Something extremely odd is happening here. I looked at the first such case, clients/cgilib.h. When I grep for it in my generated nut.fi, I see this: grep -nH -e clients/cgilib.h nut.fi nut.fi:77309:M 100644 :14 clients/cgilib.h nut.fi:9602662:M 100644 :14 clients/cgilib.h nut.fi:10381358:M 100644 :14

clang+llvm-3.8.0-rc3-x86_64-linux-gnu-debian8.tar.xz (sha1sum: 2dedc6136d7cfbac8348652c543887964d92393c) Native: All ok Cross compiling to MIPS: All ok clang+llvm-3.8.0-rc3-mips-linux-gnu.tar.xz (sha1sum: f286149dbb2ea7e194c5c3719b6cded476f6e65f) All ok (aside from non-regression failures in check-all). There were two kinds of check-all failure: * mips64 sanitizers. Not a regression since

Dear testers, Release Candidate 3 has just been tagged [1]. Please build, test, and upload to the sftp. If there are no regressions from previous release candidates, this will be the last release candidate before the final release. Release notes can still go into the branch. Thanks again for all your work! Hans [1] http://lists.llvm.org/pipermail/llvm-branch-commits/2016-February/009866.html

This is a consolidated reply to your four most recent emails. > I am trying to leverage reposurgeon to automate the process of finding merge > points, and I seem to be spinning my wheels. Can you provide an example of how > you are searching for merges? Not a working one, yet. That code is buggy. It's my next thing to work on. >reposurgeon% merge (apcsmart-dev)

On Mon, Feb 29, 2016 at 2:20 AM, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: > clang+llvm-3.8.0-rc3-x86_64-linux-gnu-debian8.tar.xz (sha1sum: 2dedc6136d7cfbac8348652c543887964d92393c) > Native: All ok > Cross compiling to MIPS: All ok > > clang+llvm-3.8.0-rc3-mips-linux-gnu.tar.xz (sha1sum: f286149dbb2ea7e194c5c3719b6cded476f6e65f) > All ok

The Wine development release 1.3.19 is now available. What's new in this release (see below for details): - New sound driver architecture for MMDevAPI. - Better support for relative mouse events in DInput. - Debugger support for the ARM platform. - Various improvements in D3DX9. - More MSVC runtime functions. - Various bug fixes. The source is available from the following

https://bugs.freedesktop.org/show_bug.cgi?id=98039 Bug ID: 98039 Summary: KMail crash on starting (nouveau-related) Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: critical Priority: medium Component: Drivers/DRI/nouveau Assignee: