From: Jan Kiszka <jan.kiszka@web.de>
To: linuxram@us.ibm.com
Cc: Anthony Liguori <aliguori@us.ibm.com>,
qemu-devel <qemu-devel@nongnu.org>
Subject: [Qemu-devel] Re: [COMMIT 707c0db] support colon in filenames
Date: Tue, 07 Jul 2009 20:29:58 +0200 [thread overview]
Message-ID: <4A539426.2020507@web.de> (raw)
In-Reply-To: <1246897688.6429.89.camel@localhost>
[-- Attachment #1: Type: text/plain, Size: 1678 bytes --]
Ram Pai wrote:
> On Sun, 2009-07-05 at 23:47 +0200, Jan Kiszka wrote:
>> Jan Kiszka wrote:
>>> Anthony,
>>>
>>> please revert this patch until Ram Pai provides a better version. It
>>> causes too many problems. At least it
> Jan,
>
> Yes I am working on the next revision of the patch.
I'm ok with keeping the change if you commit yourself to fix the
regressions quickly.
>
>>> - breaks -pflash somefile -snapshot
>> Some more details on this: it's not just pflash that suffers, -snapshot
>> was broken for raw images in general. Declaring file access as a
>> protocol apparently has some unwanted side effects that first have to be
>> resolved (check also bdrv_open2 /wrt realpath).
>
> I do not entirely understand the side effect. I will see if I can figure
> this out. It will certainly help if you can elaborate more?
Start with running/debugging 'qemu raw.image -snapshot'. Also study the
codepath bdrv_open2 takes when snapshot is enabled. Specifically watch
out for realpath(). I'm not sure ATM why it is needed, but it used to be
applied on all file paths.
>
>>> - breaks mingw32 build due to redefined _open
>> Sorry, this obviously does not apply to the merged revision 2 but to
>> rev3 which I had applied locally.
>>
>>> - uses PATH_MAX
>
> PATH_MAX is not defined in mingw32 environment?
It may not be defined in all environments (I've recently stumbled over
this with a patch, too), and it's possible that PATH_MAX < strlen(path).
Given that you can measure the input path length and the fact that the
output path cannot be larger, allocating this buffer from the heap is
really straightforward.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]
prev parent reply other threads:[~2009-07-07 18:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200906300055.n5U0tAD8013302@d03av01.boulder.ibm.com>
2009-07-04 11:13 ` [Qemu-devel] Re: [COMMIT 707c0db] support colon in filenames Jan Kiszka
2009-07-05 21:47 ` Jan Kiszka
2009-07-06 16:28 ` Ram Pai
2009-07-07 18:29 ` Jan Kiszka [this message]
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=4A539426.2020507@web.de \
--to=jan.kiszka@web.de \
--cc=aliguori@us.ibm.com \
--cc=linuxram@us.ibm.com \
--cc=qemu-devel@nongnu.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.