qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: "Richard W.M. Jones" <rjones@redhat.com>,
	Christoph Hellwig <hch@lst.de>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Heads up: glibc preadv emulation breaks qemu on older kernels
Date: Fri, 12 Feb 2010 20:58:13 +0200	[thread overview]
Message-ID: <4B75A4C5.7040209@redhat.com> (raw)
In-Reply-To: <4B758FD9.2010807@codemonkey.ws>

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 +0000, 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 preadv/pwritev code 
>>>> really
>>>> make me want to go to use the raw system calls on Linux only.  Any
>>>> opinions from the maintainers if that is acceptable?
>>> There are more than one way to parse the first sentence, if it 
>>> should be
>>> read as:
>>>    On linux and on linux only avoid using pread/write[v] and talk to 
>>> the
>>>    kernel directly.
>>>
>>> Then i agree.
>> 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 implementation of preadv/pwritev too.
>
> I think a configure option would be in order.  Forever avoiding glibc 
> is probably a bit extreme.
>

I'll go further and even avoid the configure options.  Users should run 
fully updated systems.

(how would a user know whether to enable or disable the option? by the 
time they figure out, they might as well update the system).

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

  parent reply	other threads:[~2010-02-12 18:58 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-11 19:06 [Qemu-devel] Heads up: glibc preadv emulation breaks qemu on older kernels Richard W.M. Jones
2010-02-12 12:52 ` Christoph Hellwig
2010-02-12 13:49   ` malc
2010-02-12 13:50     ` Christoph Hellwig
2010-02-12 17:28       ` Anthony Liguori
2010-02-12 18:47         ` Richard W.M. Jones
2010-02-15 22:17           ` Christoph Hellwig
2010-02-15 22:20             ` Richard W.M. Jones
2010-02-12 18:58         ` Avi Kivity [this message]
2010-02-15 22:16         ` Christoph Hellwig
2010-02-16 10:41           ` Avi Kivity
2010-02-16 10:45             ` Richard W.M. Jones
2010-02-12 13:56     ` Jamie Lokier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B75A4C5.7040209@redhat.com \
    --to=avi@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=hch@lst.de \
    --cc=qemu-devel@nongnu.org \
    --cc=rjones@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).