similar to: proposal

Hi, Attached is the pdf of the operation to make things easier to read. Thanks Shankar Easwaran On 9/20/2013 7:04 PM, Shankar Easwaran wrote: > My email client spoilt the whole email, will create a pdf and send it. > > On 9/20/2013 7:00 PM, Shankar Easwaran wrote: >> Hi Nick, >> >> On 9/20/2013 5:59 PM, Nick Kledzik wrote: >>> On Sep 20, 2013, at 3:42 PM,

My point was that if the driver is not required to change the IDs, it can initialized the ID's in all the descriptors when the ring is created and never write the ID field again. A simple allocator for the IDs can solve the problem I presented but it is still more expensive then not doing ID allocation at all. > -----Original Message----- > From: Michael S. Tsirkin [mailto:mst at

> -----Original Message----- > From: Michael S. Tsirkin [mailto:mst at redhat.com] > Sent: Monday, October 30, 2017 4:09 AM > To: Ilya Lesokhin <ilyal at mellanox.com> > Cc: virtio-dev at lists.oasis-open.org; virtualization at lists.linux-foundation.org > Subject: Re: packed ring layout proposal v3 > > On Sun, Oct 29, 2017 at 02:34:56PM +0000, Ilya Lesokhin wrote:

If you do this whats the point of the id? Just use descriptor offset like virtio 0 did. On Sun, Oct 29, 2017 at 09:05:01AM +0000, Ilya Lesokhin wrote: > My point was that if the driver is not required to change the IDs, > it can initialized the ID's in all the descriptors when the ring is created > and never write the ID field again. > > A simple allocator for the IDs can

Shankar, I think your proposal and mine are pretty much the same. The difference is passing back info to the InputGraph as a parameter in nextFile() vs as a separate method call. My original draft email had a parameter in nextFile(), but it seemed a little confusing because the information was referring to the previous file. That is, if the current resolver state has newDefinedAtoms, that

Hi Michael, > -----Original Message----- > From: virtio-dev at lists.oasis-open.org [mailto:virtio-dev at lists.oasis-open.org] > On Behalf Of Michael S. Tsirkin > Sent: Sunday, September 10, 2017 1:06 PM > To: virtio-dev at lists.oasis-open.org > Cc: virtualization at lists.linux-foundation.org > Subject: [virtio-dev] packed ring layout proposal v3 > [...] > *

On Sun, Oct 29, 2017 at 02:34:56PM +0000, Ilya Lesokhin wrote: > > -----Original Message----- > > From: Michael S. Tsirkin [mailto:mst at redhat.com] > > Sent: Sunday, October 29, 2017 4:22 PM > > To: Ilya Lesokhin <ilyal at mellanox.com> > > Cc: virtio-dev at lists.oasis-open.org; virtualization at lists.linux-foundation.org > > Subject: Re: packed ring

My email client spoilt the whole email, will create a pdf and send it. On 9/20/2013 7:00 PM, Shankar Easwaran wrote: > Hi Nick, > > On 9/20/2013 5:59 PM, Nick Kledzik wrote: >> On Sep 20, 2013, at 3:42 PM, Shankar Easwaran >> <shankare at codeaurora.org> wrote: >>> nextFile could pass the current resolver state at the time when its >>> called, the

Hi Nick, Read this along with this example extract: ld -flavor gnu main.o thread.o --start-group libc.a libpthread.a --end-group function.o main.o has atoms ------------------------ main (defined) printf(undefined) fn(undefined) thread.o has atoms ----------------------------- pthread_create (undefined) libc.a(printf.o) has atoms ------------------------------------ printf(defined)

If you do this whats the point of the id? Just use descriptor offset like virtio 0 did. On Sun, Oct 29, 2017 at 09:05:01AM +0000, Ilya Lesokhin wrote: > My point was that if the driver is not required to change the IDs, > it can initialized the ID's in all the descriptors when the ring is created > and never write the ID field again. > > A simple allocator for the IDs can

Don''t let the bureaucratic aspects of this RFP bother you: we''re eager to find and work with a good trainer to get our developers up to speed on RoR, and there''s a possibility of a paid Rails-evangelist gig as well. If that sounds like something you would be interested in and qualified for, I hope you will get in touch with us and submit a proposal. --Chris

> -----Original Message----- > From: Michael S. Tsirkin [mailto:mst at redhat.com] > Sent: Sunday, October 29, 2017 4:22 PM > To: Ilya Lesokhin <ilyal at mellanox.com> > Cc: virtio-dev at lists.oasis-open.org; virtualization at lists.linux-foundation.org > Subject: Re: packed ring layout proposal v3 > > If you do this whats the point of the id? Just use descriptor

Hi Eric, > -----Original Message----- > From: Auger Eric [mailto:eric.auger at redhat.com] > Sent: Tuesday, September 12, 2017 10:43 PM > To: Jean-Philippe Brucker <jean-philippe.brucker at arm.com>; > iommu at lists.linux-foundation.org; kvm at vger.kernel.org; > virtualization at lists.linux-foundation.org; virtio-dev at lists.oasis-open.org > Cc: will.deacon at

Hi Piotr, You may be interested in a recent patch I posted: http://reviews.llvm.org/D11043 This patch addresses a de-virtualization case that I’m not sure would be handled by your current proposal, namely that of a virtual call where the ‘this’ object is a global variable. For example: struct A { A(); virtual void foo(); }; void g(A * a) { a->foo(); } A a; int main()

> > -----Original Message----- > > From: virtualization-bounces at lists.linux-foundation.org > > [mailto:virtualization-bounces at lists.linux-foundation.org] On Behalf > > Of Michael S. Tsirkin > > > > This is an update from v2 version. >> ... > > When driver descriptors are chained in this way, multiple descriptors > > are treated as a part

Hi all, This is a GSoC 2013 proposal for LLVM project. Please see the formatted version at here: http://pacman.cs.tsinghua.edu.cn/~liuml07/files/gsoc2013-proposal-program-slicing.pdf Program slicing has been used in many applications, the criteria of which is a pair of statement and variables. I would like to write an inter-procedural program slicing pass in LLVM, which is able to calculate C

Hi, > -----Original Message----- > From: virtio-dev at lists.oasis-open.org [mailto:virtio-dev at lists.oasis-open.org] On > Behalf Of Michael S. Tsirkin > Sent: Sunday, September 10, 2017 1:06 PM > To: virtio-dev at lists.oasis-open.org > Cc: virtualization at lists.linux-foundation.org > Subject: [virtio-dev] packed ring layout proposal v3 > [...] > * Batching

On Sun, Oct 29, 2017 at 02:34:56PM +0000, Ilya Lesokhin wrote: > > -----Original Message----- > > From: Michael S. Tsirkin [mailto:mst at redhat.com] > > Sent: Sunday, October 29, 2017 4:22 PM > > To: Ilya Lesokhin <ilyal at mellanox.com> > > Cc: virtio-dev at lists.oasis-open.org; virtualization at lists.linux-foundation.org > > Subject: Re: packed ring

On Sun, Oct 08, 2017 at 06:16:44AM +0000, Ilya Lesokhin wrote: > > > -----Original Message----- > > > From: virtualization-bounces at lists.linux-foundation.org > > > [mailto:virtualization-bounces at lists.linux-foundation.org] On Behalf > > > Of Michael S. Tsirkin > > > > > > This is an update from v2 version. > >> ... > > >

HI, Yep, our proposal doesn't cover it, because this load ; icmp ; assume; will land global initilizer function, and main will not see it. At least if foo would be called multiple times, then we would only have one load from vtable, but unfortunatelly we will not be able to inline, or make direct call to it with this approach. I think that this case is rare enough to solve it right now. Piotr