search for: disentangl

On Wed, 10 Feb 2016 14:08:43 +0100 Greg Kurz <gkurz at linux.vnet.ibm.com> wrote: > But you are right, there is a bug: we should rollback if vhost_init_used() > fails. Something like below: > > err_used: > vq->private_data = oldsock; > vhost_net_enable_vq(n, vq); > + vhost_adjust_vring_endian(vq); Shouldn't we switch back before we

On Wed, 10 Feb 2016 14:08:43 +0100 Greg Kurz <gkurz at linux.vnet.ibm.com> wrote: > But you are right, there is a bug: we should rollback if vhost_init_used() > fails. Something like below: > > err_used: > vq->private_data = oldsock; > vhost_net_enable_vq(n, vq); > + vhost_adjust_vring_endian(vq); Shouldn't we switch back before we

The way vring endianness is being handled currently obfuscates the code in vhost_init_used(). This patch tries to fix that by doing the following: - move the the code that adjusts endianness to a dedicated helper - export this helper so that backends explicitely call it No behaviour change. Signed-off-by: Greg Kurz <gkurz at linux.vnet.ibm.com> --- drivers/vhost/net.c | 3 +++

On Wed, 10 Feb 2016 13:48:09 +0200 "Michael S. Tsirkin" <mst at redhat.com> wrote: > On Wed, Jan 13, 2016 at 06:09:47PM +0100, Greg Kurz wrote: > > The way vring endianness is being handled currently obfuscates > > the code in vhost_init_used(). > > > > This patch tries to fix that by doing the following: > > - move the the code that adjusts

On Wed, Jan 13, 2016 at 06:09:47PM +0100, Greg Kurz wrote: > The way vring endianness is being handled currently obfuscates > the code in vhost_init_used(). > > This patch tries to fix that by doing the following: > - move the the code that adjusts endianness to a dedicated helper > - export this helper so that backends explicitely call it > > No behaviour change. >

On Wed, Jan 13, 2016 at 06:09:47PM +0100, Greg Kurz wrote: > The way vring endianness is being handled currently obfuscates > the code in vhost_init_used(). > > This patch tries to fix that by doing the following: > - move the the code that adjusts endianness to a dedicated helper > - export this helper so that backends explicitely call it > > No behaviour change. >

On Feb 17, 2014, at 5:13 AM, Kostya Serebryany <kcc at google.com> wrote: > Then my question: will there be any objection if I disentangle AsanCoverage from ASan and make it a separate LLVM phase with the proper clang driver support? > Or it will be an unwelcome competition with the planned clang coverage? I don’t view it as a competition, but assuming that we both succeed in our plans, LLVM would then end up with two very simila...

Hi there, I have following equations to be solved for a and b: a/(a+b) = x1 ab/((a+b)^2 (a+b+1)) = x2 Is there any direct function available to solve them without disentangling them manually? Thanks for your help.

> On Jul 19, 2016, at 09:52, David Chisnall via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > The IR disruptions for CHERI aren’t that major (the main thing is that we allow alloca’s in different address spaces, but that’s not too difficult to upstream), but it does fail to tick one box that you didn’t list: We would like this feature upstreamed -Matt -------------- next part

Hi David, On Wed, Feb 12, 2014 at 5:22 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk > wrote: > On 12 Feb 2014, at 13:21, Alexey Samsonov <samsonov at google.com> wrote: > > > On Wed, Feb 12, 2014 at 4:56 PM, David Chisnall < > David.Chisnall at cl.cam.ac.uk> wrote: > >> Are you going to move the unwind library there as part of the >

...c at google.com> wrote: > > > > On Tue, Feb 18, 2014 at 12:20 AM, Bob Wilson <bob.wilson at apple.com> wrote: > >> >> On Feb 17, 2014, at 5:13 AM, Kostya Serebryany <kcc at google.com> wrote: >> > Then my question: will there be any objection if I disentangle >> AsanCoverage from ASan and make it a separate LLVM phase with the proper >> clang driver support? >> > Or it will be an unwelcome competition with the planned clang coverage? >> >> I don’t view it as a competition, but assuming that we both succeed in >> o...

...(where beta_1.hat is specific to the particular level of `a' being considered). If I am not mistaken. (Please correct me if I am!) But in the logistic model, everything is entangled in the inverse link function (the ``expit'' function as it is called by some), and I can see no way of disentangling. Is there any way of getting at this? I figure that simulation/Monte Carlo inference/ parametric bootstrapping would provide a workaround, but before I go that route, can anyone point me to a simpler method? There wouldn't be anything built into R or an R package, would there? (I d...

...;> >> >> >> On Tue, Feb 18, 2014 at 12:20 AM, Bob Wilson <bob.wilson at apple.com>wrote: >> >>> >>> On Feb 17, 2014, at 5:13 AM, Kostya Serebryany <kcc at google.com> wrote: >>> > Then my question: will there be any objection if I disentangle >>> AsanCoverage from ASan and make it a separate LLVM phase with the proper >>> clang driver support? >>> > Or it will be an unwelcome competition with the planned clang coverage? >>> >>> I don’t view it as a competition, but assuming that we both s...

...ensively about these issues with Nick Lewycky, Richard Smith, Benjamin Kramer, and Duncan Sands. Duncan and I made the final call to pull these patches out once I heard that Micah was going to be out and unable te quickly address an PRs, etc. Since I made the call to pull it out, I did the work to disentangle the commits, and have backed it out in a series of commits tonight. I'll plan on doing some of the cleanups and API fixes in the core libraries as well to ensure those are in place prior to 3.2. Some things I think are going to be pretty important when you try to return to this Micah in orde...

...e I've just realised I didn't send an announcement for -pre2. There are still a number of fairly important bugs that are causing people issues and unfortunately I haven't had the time to fix them in this release. But they are still on the TODO list. --- H. Peter Anvin (3): pxe: disentangle the legacy and lwip stacks without #ifdef font: load data as a single block serial: Clean up and abstract handling of serial ports Josh Triplett (1): Fix support for Linux kernel images with no protected mode code Matt Fleming (12): ldlinux: Always update ConfigName when...

...#39;d like to get in first, or any other problems with the current state of the ARM64 backend that they think should block this? If not, I'd suggest I start work either next weekend (if I'm feeling keen, to minimize disruption) or on Monday 26th (if not). I expect it to take a day or so to disentangle things; but after the move commit (while I'm doing final tidying up of tests & such), work should be able to start again without issue. Looks like we might make 3.5 comfortably! Cheers. Tim. (Oh, and I'm away this weekend and early next week; without any net for the weekend bit, so...

...r" seems to better indicate the intention. Also, in the same place, I think "don't inherit from ExecutionEngine" is a potentially misleading comment, since that's the class that clients actually use to interface with MCJIT. It would probably be better to say something about disentangling the JIT and MCJIT interfaces and specifically mention that we don't want the base class to manage our modules. Keep in mind, however, that in addition to JIT and MCJIT, there's also the Interpreter class which inherits from ExecutionEngine. There are a few very basic multiple module te...

On Feb 12, 2014, at 11:43 PM, Kostya Serebryany <kcc at google.com> wrote: > > > > On Thu, Feb 13, 2014 at 11:10 AM, Bob Wilson <bob.wilson at apple.com> wrote: > > On Feb 12, 2014, at 10:31 AM, Kostya Serebryany <kcc at google.com> wrote: > >> Hi, >> >> Justin is making nice commits for llvm-cov, so I thought we may continue this

# HG changeset patch # User Roger Pau Monne <roger.pau@entel.upc.edu> # Date 1324385575 -3600 # Node ID 716d6d48e647d1d4352f7206e74e693152a4f8fa # Parent f72b99fccfca694674259cc1c03c526a827b67ec libxl: add support for yajl 2.x This patch adds support for yajl versions 2.x, while retaining 1.x compatibility. This patch adds quite a lot of #ifdefs all over the json code, so I''m open

Hi Andy, Here is the patch. it incorporates: 1) your latest patch to SVN. 2) mcjit-module-state-optimization.patch. 3) the PtrSet changes. Other than the OwnedModules implementation there were other differences between 1) and 2), especially in the Finalize* functions, so please review that I got the right code. I got bitten by subtle bugs arising from MCJIT inheriting from EE: First, MCJIT