On Tue, Feb 16, 2010 at 12:41:43PM +0200, Avi Kivity wrote:
> On 02/16/2010 12:16 AM, Christoph Hellwig wrote:
>> On Fri, Feb 12, 2010 at 11:28:57AM -0600, Anthony Liguori wrote:
>>
Yes. The BSDs tend to not play stupid emulation games in the libc, so
changes of these kinds of messup
On 02/16/2010 12:16 AM, Christoph Hellwig wrote:
On Fri, Feb 12, 2010 at 11:28:57AM -0600, Anthony Liguori wrote:
Yes. The BSDs tend to not play stupid emulation games in the libc, so
changes of these kinds of messups to happen are far less.
In all fairness, I seem to recall there
On Mon, Feb 15, 2010 at 11:17:27PM +0100, Christoph Hellwig wrote:
> On Fri, Feb 12, 2010 at 06:47:55PM +, Richard W.M. Jones wrote:
> > I don't think there's a good solution for this at the qemu level.
> > However I have a working patch for glibc:
> >
> > https://bugzilla.redhat.com/show_bug.
On Fri, Feb 12, 2010 at 06:47:55PM +, Richard W.M. Jones wrote:
> I don't think there's a good solution for this at the qemu level.
> However I have a working patch for glibc:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=563103#c13
Any chance you could just persuade Uli to drop the optimiz
On Fri, Feb 12, 2010 at 11:28:57AM -0600, Anthony Liguori wrote:
> >Yes. The BSDs tend to not play stupid emulation games in the libc, so
> >changes of these kinds of messups to happen are far less.
> >
>
> In all fairness, I seem to recall there being a problem with the kernel
> implementati
On 02/12/2010 07:28 PM, Anthony Liguori wrote:
On 02/12/2010 07:50 AM, Christoph Hellwig wrote:
On Fri, Feb 12, 2010 at 04:49:23PM +0300, malc wrote:
On Fri, 12 Feb 2010, Christoph Hellwig wrote:
On Thu, Feb 11, 2010 at 07:06:08PM +, Richard W.M. Jones wrote:
One interesting thing is that
On Fri, Feb 12, 2010 at 11:28:57AM -0600, Anthony Liguori wrote:
> I think a configure option would be in order. Forever avoiding glibc is
> probably a bit extreme.
I think a configure option won't work. The issue here was that
the binary is being installed on a machine with an older
kernel.
On 02/12/2010 07:50 AM, Christoph Hellwig wrote:
On Fri, Feb 12, 2010 at 04:49:23PM +0300, malc wrote:
On Fri, 12 Feb 2010, Christoph Hellwig wrote:
On Thu, Feb 11, 2010 at 07:06:08PM +, Richard W.M. Jones wrote:
One interesting thing is that qemu has its own preadv emul
malc wrote:
> On Fri, 12 Feb 2010, Christoph Hellwig wrote:
>
> > On Thu, Feb 11, 2010 at 07:06:08PM +, Richard W.M. Jones wrote:
> > > One interesting thing is that qemu has its own preadv emulation (which
> > > does the emulation correctly), but this is never used because qemu
> > > never ge
On Fri, Feb 12, 2010 at 04:49:23PM +0300, malc wrote:
> On Fri, 12 Feb 2010, Christoph Hellwig wrote:
>
> > On Thu, Feb 11, 2010 at 07:06:08PM +, Richard W.M. Jones wrote:
> > > One interesting thing is that qemu has its own preadv emulation (which
> > > does the emulation correctly), but this
On Fri, 12 Feb 2010, Christoph Hellwig wrote:
> On Thu, Feb 11, 2010 at 07:06:08PM +, Richard W.M. Jones wrote:
> > One interesting thing is that qemu has its own preadv emulation (which
> > does the emulation correctly), but this is never used because qemu
> > never gets ENOSYS back from prea
On Thu, Feb 11, 2010 at 07:06:08PM +, Richard W.M. Jones wrote:
> One interesting thing is that qemu has its own preadv emulation (which
> does the emulation correctly), but this is never used because qemu
> never gets ENOSYS back from preadv.
At this point the amount of bugs in the glibc prea
This isn't a problem with qemu as such, but it may affect you if you
use qemu with a newer glibc on a Linux kernel which does not support
the preadv(2) syscall natively. glibc will attempt to emulate
preadv(2) using pread(2) syscalls, but it doesn't align the user
buffer when it does this, and th
13 matches
Mail list logo
