search for: l93

...he function is defined as > having ExternalLinkage. I have to test on Linux / Mac OSX to see if > the behaviour is different there. Correct. There's a comment on it in the Kaleidoscope example: https://github.com/llvm-mirror/llvm/blob/master/examples/Kaleidoscope/include/KaleidoscopeJIT.h#L93 Cheers Stefan Am 24.09.17 um 00:36 schrieb Dibyendu Majumdar via llvm-dev: > Hi, > > On 22 September 2017 at 15:33, Dibyendu Majumdar <mobile at majumdar.org.uk> wrote: >> I am looking to port my MCJIT based implementation to ORC. I have been >> reading up on the ORC tu...

...*get_mdev_features)(struct mdev_device *mdev); Do we need a .set_mdev_features method as well? It's not very clear what does mdev_features mean. Does it mean the vhost backend features? https://github.com/torvalds/linux/blob/0e2adab6cf285c41e825b6c74a3aa61324d1132c/include/uapi/linux/vhost.h#L93-L94 > + u32 (*get_generation)(struct mdev_device *mdev); > +}; > + > +void mdev_set_virtio_ops(struct mdev_device *mdev, > + const struct virtio_mdev_device_ops *virtio_ops); > + > +#endif > -- > 2.19.1 >

..., which also removes the need to chroot out in the > parent. The CHROOT_IN/OUT business does need to be rewritten. Every instance where we currently do something like: CHROOT_IN; r = stat (fd, &statbuf); CHROOT_OUT [https://github.com/libguestfs/libguestfs/blob/master/daemon/stat.c#L93-L95] should instead be forking a subprocess, chrooting in the subprocess, and doing the system call in the subprocess. The problem which makes it not so easy is that instead of using a nice local variable, we would have to pass back the result from a subprocess to the parent process (the pair (r,...

...ess does need to be rewritten. Every > instance where we currently do something like: > > CHROOT_IN; > r = stat (fd, &statbuf); > CHROOT_OUT > Ouch. Fortunately commandvf change should be easy. > [https://github.com/libguestfs/libguestfs/blob/master/daemon/stat.c#L93-L95] > > should instead be forking a subprocess, chrooting in the subprocess, > and doing the system call in the subprocess. > > The problem which makes it not so easy is that instead of using a nice > local variable, we would have to pass back the result from a > subprocess...

On Thu, Jan 26, 2023 at 2:31 PM Richard W.M. Jones <rjones at redhat.com> wrote: > > Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1986386 > Reported-by: Junqin Zhou > --- > output/rhv-upload-precheck.py | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/output/rhv-upload-precheck.py b/output/rhv-upload-precheck.py > index

...multiple inclusion of file ld: warning: file ../../src/lib-dovecot/.libs/libdovecot.so: linked to /home/henrikj/Build/dovecot-2.1.15/src/lib-dovecot/.libs/libdovecot.so: attempted multiple inclusion of file Undefined first referenced symbol in file $XBKaiwbjOCHRV5w.array_append_array_i..L93 dsync/libdsync.a(dsync-brain.o) $XBKaiwbjOCHRV5w.array_append_array_i..L94 dsync/libdsync.a(dsync-brain.o) $XBKaiwbjOCHRV5w.array_append_array_i..L95 dsync/libdsync.a(dsync-brain.o) ld: fatal: symbol referencing errors. No output written to .libs/doveadm *** Error code 2 make: Fatal error: Command...

Get minimum size of NTFS filesystem in bytes. This is used primarily for shrinking images. In case of a full images ntfsresize returns error code and does not print minimum size. So we calculate it manually by rounding 'volume size' up to 'cluster size'. --- daemon/ntfs.c | 68 ++++++++++++++++++++++++++++++++++++++++++++++++++++ generator/actions.ml | 17 +++++++++++++

Hi, On 22 September 2017 at 15:33, Dibyendu Majumdar <mobile at majumdar.org.uk> wrote: > I am looking to port my MCJIT based implementation to ORC. I have been > reading up on the ORC tutorials, but am not clear on how to do > following: > > I would like to discard everything other than the compiled code after > compiling a module. > A module may have more than one

Hi, I am looking to port my MCJIT based implementation to ORC. I have been reading up on the ORC tutorials, but am not clear on how to do following: I would like to discard everything other than the compiled code after compiling a module. A module may have more than one function in it - so I would like to retain all the compiled functions. I am okay with eager compilation - i.e. there is no need

When running commands in the mounted guest (using the "command" API, and APIs based on it), provide the /dev/null from the appliance as open fd for stdin. Commands usually assume stdin is open if they didn't close it explicitly, so this should avoid crashes or misbehavings due to that. --- daemon/command.c | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-)

Hi all: There are hardwares that can do virtio datapath offloading while having its own control path. This path tries to implement a mdev based unified API to support using kernel virtio driver to drive those devices. This is done by introducing a new mdev transport for virtio (virtio_mdev) and register itself as a new kind of mdev driver. Then it provides a unified way for kernel virtio driver

Hi all: There are hardwares that can do virtio datapath offloading while having its own control path. This path tries to implement a mdev based unified API to support using kernel virtio driver to drive those devices. This is done by introducing a new mdev transport for virtio (virtio_mdev) and register itself as a new kind of mdev driver. Then it provides a unified way for kernel virtio driver