search for: fileop

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 mini-library called fileops, and uses it to implement the file plugin. Note that the name or prefix "file" leaks into fileops in a few places: the debug option is still called...

...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; /* Allocate *fops */ /* Set up fd however you want */ if (init_fileops (fd, fops) == -1) { free (fops); return NULL; } return fops; } static struct nbdkit_plugin plugin = { .name = "foo", .open = foo_open, .clo...

...plugins/iso/Makefile.am index a0fd337a..44ecbc8a 100644 --- a/plugins/iso/Makefile.am +++ b/plugins/iso/Makefile.am @@ -43,8 +43,9 @@ nbdkit_iso_plugin_la_SOURCES = \ $(NULL) nbdkit_iso_plugin_la_CPPFLAGS = \ - -I$(top_srcdir)/common/utils \ -I$(top_srcdir)/include \ + -I$(top_srcdir)/common/fileops \ + -I$(top_srcdir)/common/utils \ -I. \ $(NULL) nbdkit_iso_plugin_la_CFLAGS = $(WARNINGS_CFLAGS) @@ -53,6 +54,7 @@ nbdkit_iso_plugin_la_LDFLAGS = \ -Wl,--version-script=$(top_srcdir)/plugins/plugins.syms \ $(NULL) nbdkit_iso_plugin_la_LIBADD = \ + $(top_builddir)/common/fileops/libfileo...

...cient 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 + plugins/tmpdisk/tmpdisk.c | 247 +++++------------------------------- 2 files changed, 32 insertions(+), 217 deletions(-) diff --git a/plugins/tmpdisk/Makefile.am b/plugins/tmpdisk/Makefile.am index 20aeb05f..471a0f6a 100644 --- a/plugins/tmpd...

...lugins/iso/iso.c | 99 +++++++++++++++++++---------------------- > 2 files changed, 48 insertions(+), 55 deletions(-) > > @@ -193,25 +195,43 @@ iso_get_ready (void) > static void * > iso_open (int readonly) > { > - return NBDKIT_HANDLE_NOT_NEEDED; > + struct fileops *fops; > + int fd; > + > + fops = malloc (sizeof *fops); > + if (fops == NULL) { > + nbdkit_error ("malloc: %m"); > + return NULL; > + } > + > + /* Copy the fd because fileops needs to have its own file descriptor. */ > + fd = dup (iso_fd); We u...

...-- >>   plugins/iso/Makefile.am |  4 +- >>   plugins/iso/iso.c       | 99 +++++++++++++++++++---------------------- >>   2 files changed, 48 insertions(+), 55 deletions(-) >> > Oops, you forgot to set #define NBDKIT_API_VERSION 2 Maybe in patch 1 you should add this to fileops.h: #if NBDKIT_API_VERSION - 0 != 2 # error This header requires API version 2 #endif -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org

...nch. # 2. set-eol-style operations get lost; see tags windows-set-eol, reset-eol. # 3. Should the first Eaton_SDK commit after the deleteall have a link # back to trunk? # 4. Is the new_UIs-root tag still useful? It doesn't seem to point # at an actual branch. Also, some remaining zero-fileop commits on the root branch should probably be tagified. >From what you said before, point 2 may actually be a non-issue. Should I cross it off the list? -- >>esr>>

...s diff --git a/lib/sanitizer_common/tests/sanitizer_libc_test.cc b/lib/sanitizer_common/tests/sanitizer_libc_test.cc index 689c6ed..a304458 100644 --- a/lib/sanitizer_common/tests/sanitizer_libc_test.cc +++ b/lib/sanitizer_common/tests/sanitizer_libc_test.cc @@ -85,7 +85,7 @@ TEST(SanitizerCommon, FileOps) { EXPECT_EQ(len2, internal_write(fd, str2, len2)); internal_close(fd); - openrv = OpenFile(tmpfile, WrOnly); + openrv = OpenFile(tmpfile, RdWr); EXPECT_FALSE(internal_iserror(openrv)); fd = openrv; uptr fsize = internal_filesize(fd); @@ -134,7 +134,7 @@ TEST(SanitizerCommon, Int...

...what seems actually to be going on: The first instance is initial creation on the master branch. The second and third instances are from branch creations. This reveals a minor bug - I shouldn't be generating duplicate modify ops on branch creation. The key point, though, is that no delete fileop is ever issued for the master branch copy. So why it's not showing up in the checkout is, to say the least, mysterious. git-fast-import is not behaving in the expected way. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> [W]hat country can preserve its libe...

...n-mips64-with-call-Test/MemorySanitizer.UnalignedStore32 MemorySanitizer-Unit :: Msan-mips64-with-call-Test/MemorySanitizer.gethostbyname_r_erange MemorySanitizer-Unit :: Msan-mips64-with-call-Test/MemorySanitizer.ptrtoint SanitizerCommon-Unit :: Sanitizer-mips64-Test/SanitizerCommon.FileOps SanitizerCommon-Unit :: Sanitizer-mips64-Test/SanitizerIoctl.KVM_GET_LAPIC SanitizerCommon-Unit :: Sanitizer-mips64-Test/SanitizerIoctl.KVM_GET_MP_STATE SanitizerCommon-asan :: Linux/getpwnam_r_invalid_user.cc SanitizerCommon-lsan :: Linux/getpwnam_r_invalid_user.cc Thread...

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

...in the lift recipe. This is the other algorithmic issue. The problem I have to deal with is not just patching this one link back to trunk, it's that I don't yet understand under which circumstances my translator should generate merge commits on its own. >> Also, some remaining zero-fileop commits on the root branch should >> probably be tagified. > >I haven't had a chance to look at the last two. I have. It's nothing - they're from branch deletions, or from branch renames that never need to get expressed in gitspace because there are no file operations after...

...zer.UnalignedStore32 > MemorySanitizer-Unit :: Msan-mips64-with-call-Test/MemorySanitizer.gethostbyname_r_erange > MemorySanitizer-Unit :: Msan-mips64-with-call-Test/MemorySanitizer.ptrtoint > SanitizerCommon-Unit :: Sanitizer-mips64-Test/SanitizerCommon.FileOps > SanitizerCommon-Unit :: Sanitizer-mips64-Test/SanitizerIoctl.KVM_GET_LAPIC > SanitizerCommon-Unit :: Sanitizer-mips64-Test/SanitizerIoctl.KVM_GET_MP_STATE > SanitizerCommon-asan :: Linux/getpwnam_r_invalid_user.cc > SanitizerCommon-lsan...

...tributeBuffer & UnlockAttributeBuffer. d3dx9: Implement GetAttributeTable and SetAttributeTable. d3dx9: Implement ID3DXMesh::DrawSubset. Eric Pouech (3): services: Be sure to unlock the current database in all error cases in service_start_process. msvcrt: Added tests in fileops with different buffer management modes. msvcrt: ungetc must create a buffer, even if _IONBF has been set with setvbuf. Francois Gouget (11): setupapi: Fix the SetupDiGetActualSectionToInstallEx() definition. mshtml: get_channelbsc_mon() is unused so remove it. msi: Move ms...

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: