On 8/30/23 13:59, Peter Krempa wrote:
> After recent cleanups we can now restrict the maximum stack frame size
> to 2k.
>
> Signed-off-by: Peter Krempa
> ---
> meson.build | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meson.build b/meson.build
> index
On Mon, Sep 04, 2023 at 02:34:49PM +0200, Michal Prívozník wrote:
On 9/1/23 17:12, Martin Kletzander wrote:
When we parse we keep that in memory
and pass it down to the hypervisor. However, that MAC address is not
strictly valid as it is not marked as locally administered (bit 0x02)
but it is
Ping2, I'm hoping for comments about the series.
Thanks,
Yong
On Sun, Aug 27, 2023 at 11:11 AM Yong Huang wrote:
> Ping1
>
> On Tue, Aug 15, 2023 at 9:48 AM Yong Huang wrote:
>
>> Ping.
>>
>> On Mon, Aug 7, 2023 at 11:56 PM ~hyman wrote:
>>
>>> Hi, This is the latest version for the series,
The conversion from ternary to a 'if' clause was wrong and thus didn't
properly increase the stack size where needed but only where not
actually needed.
Fixes: b68faa99d9f16c2f504b23737040d25d072ee85d
Signed-off-by: Peter Krempa
---
meson.build | 2 +-
1 file changed, 1 insertion(+), 1
On 9/1/23 17:12, Martin Kletzander wrote:
> When we parse we keep that in memory
> and pass it down to the hypervisor. However, that MAC address is not
> strictly valid as it is not marked as locally administered (bit 0x02)
> but it is not even globally unique. It is also used for loopback
Instead of an assignment into the 'stack_frame_size' variable when
sanitizers are enabled I've accidentally compared the value against the
requested size.
Fix the typo.
Fixes: b68faa99d9f16c2f504b23737040d25d072ee85d
Signed-off-by: Peter Krempa
---
meson.build | 2 +-
1 file changed, 1
On Mon, Sep 04, 2023 at 12:13:37PM +0200, Peter Krempa wrote:
> When building without optimization on clang, certain big functions trip
> the stack size limit despite not actually reaching it. Relax the stack
> limit size for clang without optimization.
>
> Signed-off-by: Peter Krempa
> ---
>
On Mon, Sep 04, 2023 at 12:13:36PM +0200, Peter Krempa wrote:
> Meson doesn't interpret what's set in CFLAGS, but rather simply appeds
> it to the command line. Thus any logic which is based on the
> optimization level will not work.
>
> Note the caveat in the docs and instruct users to use
>
When building without optimization on clang, certain big functions trip
the stack size limit despite not actually reaching it. Relax the stack
limit size for clang without optimization.
Signed-off-by: Peter Krempa
---
meson.build | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
Add a note for users how optimization is supposed to be controled with
meson and fix the build by using 4k stack flame on clang without
optimization.
Peter Krempa (2):
docs: compiling: Add a note about use of CFLAGS for optimization
build: Work around clang's stack size calculation without
Meson doesn't interpret what's set in CFLAGS, but rather simply appeds
it to the command line. Thus any logic which is based on the
optimization level will not work.
Note the caveat in the docs and instruct users to use
``--optimization=N`` instead.
Signed-off-by: Peter Krempa
---
On Mon, Sep 04, 2023 at 11:23:17AM +0200, Peter Krempa wrote:
> Build fails with this patch with 'clang' when optimizations are
> disabled in long functions which have many helper variables declared in
> nested blocks such as for-loops.
>
> As there is no clean solution for now, let's keep the
Build fails with this patch with 'clang' when optimizations are
disabled in long functions which have many helper variables declared in
nested blocks such as for-loops.
As there is no clean solution for now, let's keep the stack frame size
at 4k.
This reverts commit
On Mon, Sep 04, 2023 at 10:46:17 +0200, Peter Krempa wrote:
> On Mon, Sep 04, 2023 at 10:31:48 +0200, Michal Privoznik wrote:
> > Okay, this is a shortcut. Our coding style says that error
> > messages are exempt from '80 chars long lines' rule. But in the
> > very same paragraph it is said that
On Mon, Sep 04, 2023 at 10:31:48 +0200, Michal Privoznik wrote:
> Okay, this is a shortcut. Our coding style says that error
> messages are exempt from '80 chars long lines' rule. But in the
> very same paragraph it is said that all error messages need to be
> marked for translation (as they might
On Mon, Sep 04, 2023 at 10:31:47 +0200, Michal Privoznik wrote:
> The --help output of virsh and virt-admin shows supported options
> and commands and as such contains new lines. Both these strings
> are marked for translation btw. But the way they are formatted
> now ('\n' being at the start of
On 9/2/23 00:41, Martin Kletzander wrote:
> Change example logfile path and clarify how complicated all things passt
> are. I chose not to create the non-existing directory because it could
> open a whole new can of worms.
>
> Also explain missing `dev` attribute of ``
>
> Resolves:
Okay, this is a shortcut. Our coding style says that error
messages are exempt from '80 chars long lines' rule. But in the
very same paragraph it is said that all error messages need to be
marked for translation (as they might be presented to user).
Therefore, the syntax-check rule can check if
The --help output of virsh and virt-admin shows supported options
and commands and as such contains new lines. Both these strings
are marked for translation btw. But the way they are formatted
now ('\n' being at the start of new line instead at the end of
the previous) makes it hard to create a
This is a follow up of:
https://listman.redhat.com/archives/libvir-list/2023-August/241416.html
And while the regular expression in patch 2/2 is very trivial it mostly
works. But I'm open for suggestions.
Michal Prívozník (2):
tools: Reformat --help output of virsh and virt-admin
On Mon, Sep 04, 2023 at 09:22:54AM +0200, Peter Krempa wrote:
On Fri, Sep 01, 2023 at 23:32:14 +0200, Martin Kletzander wrote:
They represent nanoseconds, and we accept such values already. Not that
anyone would use such values in the wild, but even one person testing
QEMU could put in a
On Fri, Sep 01, 2023 at 03:24:11PM -0500, Jonathon Jongsma wrote:
On 8/16/23 4:19 PM, Jonathon Jongsma wrote:
On 8/8/23 6:00 AM, Stefano Garzarella wrote:
On Mon, Aug 07, 2023 at 03:41:21PM +0200, Peter Krempa wrote:
On Thu, Aug 03, 2023 at 09:48:01 +0200, Stefano Garzarella wrote:
On Wed,
On Fri, Sep 01, 2023 at 23:32:14 +0200, Martin Kletzander wrote:
> They represent nanoseconds, and we accept such values already. Not that
> anyone would use such values in the wild, but even one person testing
> QEMU could put in a bigger value and will be bothered with validation
> errors after
23 matches
Mail list logo
