Hi!
Is there any update on this? I haven't received any comments.
On Sun, Oct 23, 2022 at 12:04 PM Nikita Ivanov
wrote:
> At the moment, TFR() macro has a vague name and is not used
> where it possibly could be. In order to make it more transparent
> and useful, it was decided to
Rename macro name to more transparent one and refactor
it to expression.
Signed-off-by: Nikita Ivanov
---
chardev/char-fd.c | 2 +-
chardev/char-pipe.c| 8 +---
include/qemu/osdep.h | 8 +++-
net/tap-bsd.c | 6 +++---
net/tap-linux.c| 2 +-
net/tap-solaris.c
RETRY_ON_EINTR(). All the
places where RETRY_ON_EINTR() macro code be applied were covered.
Nikita Ivanov (2):
Refactoring: refactor TFR() macro to RETRY_ON_EINTR()
error handling: Use RETRY_ON_EINTR() macro where applicable
block/file-posix.c| 37 -
chardev
There is a defined RETRY_ON_EINTR() macro in qemu/osdep.h
which handles the same while loop.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/415
Signed-off-by: Nikita Ivanov
---
block/file-posix.c| 37 -
chardev/char-pty.c| 4 +---
hw
Hi!
Thanks for clarification! Corrected it in v4.
On Wed, Oct 19, 2022 at 6:24 PM Christian Schoenebeck <
qemu_...@crudebyte.com> wrote:
> On Tuesday, October 18, 2022 10:43:41 AM CEST Nikita Ivanov wrote:
> > There is a defined RETRY_ON_EINTR() macro in qemu/osdep.h
> > w
Hi!
Thanks for mentioning the issue. Corrected it in v4.
On Wed, Oct 19, 2022 at 6:40 PM Christian Schoenebeck <
qemu_...@crudebyte.com> wrote:
> On Dienstag, 18. Oktober 2022 10:43:40 CEST Nikita Ivanov wrote:
> > Rename macro name to more transparent one and refactor
>
There is a defined RETRY_ON_EINTR() macro in qemu/osdep.h
which handles the same while loop.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/415
Signed-off-by: Nikita Ivanov
---
block/file-posix.c| 37 -
chardev/char-pty.c| 4 +---
hw
Rename macro name to more transparent one and refactor
it to expression.
Signed-off-by: Nikita Ivanov
---
chardev/char-fd.c | 2 +-
chardev/char-pipe.c| 8 +---
include/qemu/osdep.h | 8 +++-
net/tap-bsd.c | 6 +++---
net/tap-linux.c| 2 +-
net/tap-solaris.c
RETRY_ON_EINTR(). All the
places where RETRY_ON_EINTR() macro code be applied were covered.
Nikita Ivanov (2):
Refactoring: refactor TFR() macro to RETRY_ON_EINTR()
error handling: Use RETRY_ON_EINTR() macro where applicable
block/file-posix.c| 37 -
chardev
Hi!
Execuse me, my fault. Overlooked TFR occurrences in second patch. I will
correct it.
ср, 12 окт. 2022 г., 18:43 Christian Schoenebeck :
> On Mittwoch, 12. Oktober 2022 17:17:46 CEST Bin Meng wrote:
> > Hi,
> >
> > On Wed, Oct 12, 2022 at 8:32 PM N
There is a defined RETRY_ON_EINTR() macro in qemu/osdep.h which
handles the same while loop.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/415
Signed-off-by: Nikita Ivanov
---
block/file-posix.c| 37 -
chardev/char-pty.c| 4 +---
hw
Rename macro name to more transparent one and refactor
it to expression.
Signed-off-by: Nikita Ivanov
---
chardev/char-fd.c| 2 +-
chardev/char-pipe.c | 8 +---
include/qemu/osdep.h | 8 +++-
net/tap-bsd.c| 6 +++---
net/tap-linux.c | 2 +-
net/tap-solaris.c| 8
RETRY_ON_EINTR(). All the
places where RETRY_ON_EINTR() macro code be applied were covered.
Nikita Ivanov (2):
Refactoring: refactor TFR() macro to RETRY_ON_EINTR()
error handling: Use RETRY_ON_EINTR() macro where applicable
block/file-posix.c| 37 -
chardev
_FAILURE_RETRY(expr) \
>
> We can't call the macro this, because the glibc system headers already
> may define a macro of that name, so the compiler will complain if they're
> both defined at the same time, and depending on header ordering it might
> not be clear which version you're getting.
>
Sorry, my fault. I will rename it to "RETRY_ON_EINTR" as it was proposed
earlier in this thread.
--
Best Regards,
*Nikita Ivanov* | C developer
Hi!
Sorry for such a long absence, I've been resolving some other issues in my
life for a while. I've adjusted the patch according to your latest
comments. Could you check it out, please?
>From 5389c5ccc8789f8f666ab99e50d38af728bd2c9c Mon Sep 17 00:00:00 2001
From: Nikita Ivanov
Date: Wed, 3
:
> On Wed, 17 Aug 2022 at 15:06, Nikita Ivanov
> wrote:
> >
> > Hi! Are there any updates? I have not received any comments since the
> last email.
>
> Looking at the thread, I don't think we (yet) have consensus on the
> right thing to do here...
>
> thanks
&g
Hi! Are there any updates? I have not received any comments since the last
email.
On Mon, Aug 8, 2022 at 9:03 PM Nikita Ivanov wrote:
> And summing up the discussion about TEMP_FAILURE_RETRY() usage examples,
> I've come up with a new patch for TFR() to TEMP_FAILURE_RETRY()
> refactor
And summing up the discussion about TEMP_FAILURE_RETRY() usage examples,
I've come up with a new patch for TFR() to TEMP_FAILURE_RETRY()
refactoring. I've decided to stick to expression realisation.
>From 94217dfacf12b3211cfab6e19d750e57d679e851 Mon Sep 17 00:00:00 2001
From: Nikita Ivanov
D
Hi!
During our discussion, I found that I've missed a couple of places where
TFR() macro could be applied. Here is an updated first patch:
>From 8a68f50aac4a8549f416b9350cf339cf0501a712 Mon Sep 17 00:00:00 2001
From: Nikita Ivanov
Date: Wed, 3 Aug 2022 12:54:00 +0300
Subject: [PATCH] er
Good point, thank you!
I think it's a bad idea to keep it like I proposed. Though, could I just
copy the definition that Markus has posted or there are any objections?
On Mon, Aug 8, 2022 at 11:06 AM Markus Armbruster wrote:
> Nikita Ivanov writes:
>
> > Summing up the discuss
Summing up the discussion above, I suggest the following patch for TFR()
macro refactoring. (The patch is sequential to the first one I introduced
in the start of the discussion).
>From 6318bee052900aa93bba6620b53c7cb2290e5001 Mon Sep 17 00:00:00 2001
From: Nikita Ivanov
Date: Mon, 8 Aug 2022
>From 0ceb04ada1ed5a863914f4449469d7572d3443ed Mon Sep 17 00:00:00 2001
From: Nikita Ivanov
Date: Wed, 3 Aug 2022 12:54:00 +0300
Subject: [PATCH] error handling: Use TFR() macro where applicable
There is a defined TFR() macro in qemu/osdep.h which
handles the same while loop.
Resolves: ht
22 matches
Mail list logo
