-Original Message-
From: Scott Feldman [mailto:scofe...@cisco.com]
Sent: Wednesday, May 05, 2010 7:04 PM
To: Shreyas Bhatewara; Arnd Bergmann; Dmitry Torokhov
Cc: Christoph Hellwig; pv-driv...@vmware.com; net...@vger.kernel.org;
linux-ker...@vger.kernel.org;
From: Michael S. Tsirkin m...@redhat.com
Date: Tue, 4 May 2010 14:21:01 +0300
This is an amended pull request: I have rebased the tree to the
correct patches. This has been through basic tests and seems
to work fine here.
The following tree includes a couple of enhancements that help
Rusty Russell wrote:
On Wed, 5 May 2010 05:47:05 am Jamie Lokier wrote:
Jens Axboe wrote:
On Tue, May 04 2010, Rusty Russell wrote:
ISTR someone mentioning a desire for such an API years ago, so CC'ing
the
usual I/O suspects...
It would be nice to have a more fuller API
On Thu, May 06, 2010 at 01:19:33AM -0700, Gleb Natapov wrote:
Overhead of interpreting bytecode plugin is written in. Or are you
saying plugin is x86 assembly (32bit or 64bit btw?) and other arches
will have to have in kernel x86 emulator to use the plugin (like some
of them had for vgabios)?
On Wed, May 05, 2010 at 10:47:10AM -0700, Pankaj Thakkar wrote:
Forget about the licensing. Loading binary blobs written to a shim
layer is a complete pain in the ass and totally unsupportable, and
also uninteresting because of the overhead.
[PT] Why do you think it is unsupportable? How
On Wed, May 05, 2010 at 10:52:53AM -0700, Stephen Hemminger wrote:
Let me put it bluntly. Any design that allows external code to run
in the kernel is not going to be accepted. Out of tree kernel modules are
enough
of a pain already, why do you expect the developers to add another
On Thu, 6 May 2010 03:57:55 pm Michael S. Tsirkin wrote:
On Thu, May 06, 2010 at 10:22:12AM +0930, Rusty Russell wrote:
On Wed, 5 May 2010 03:52:36 am Michael S. Tsirkin wrote:
What do you think?
I think everyone is settled on 128 byte cache lines for the forseeable
future, so it's
On Thu, 6 May 2010 07:30:00 pm Avi Kivity wrote:
On 05/05/2010 11:58 PM, Michael S. Tsirkin wrote:
+ /* We publish the last-seen used index at the end of the available ring.
+* It is at the end for backwards compatibility. */
+ vr-last_used_idx =(vr)-avail-ring[num];
+ /* Verify
On Thu, 6 May 2010 03:49:46 pm Michael S. Tsirkin wrote:
Now, I also added an mb() in guest between read and write so
that last used index write can not get ahead of used index read.
It does feel good to have it there, but I can not say why
it's helpful. Works fine without it, but then these
From: Stijn Tintel st...@linux-ipv6.be
Move initialization of the virtio framework before the initialization of
mtd, so that block2mtd can be used on virtio-based block devices.
Addresses https://bugzilla.kernel.org/show_bug.cgi?id=15644
Signed-off-by: Stijn Tintel st...@linux-ipv6.be
10 matches
Mail list logo