When using llvm-addr2line in replacement of addr2line, it will output
zero sized symbols, which can shadow other binaries depending on where
there location is (happens with arm-trusted-firmware and its different
binaries). Thus, those symbols.

Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
---
 contrib/plugins/uftrace_symbols.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/contrib/plugins/uftrace_symbols.py b/contrib/plugins/uftrace_symbols.py
index 7d79b81cdec..02d1221228c 100755
--- a/contrib/plugins/uftrace_symbols.py
+++ b/contrib/plugins/uftrace_symbols.py
@@ -45,6 +45,8 @@ def get_symbols(elf_file):
             continue
         addr = int(addr, 16)
         size = int(size, 16)
+        if size == 0:
+            continue
         symbols.append(Symbol(name, addr, size))
     symbols.sort(key = lambda x: x.addr)
     return symbols
-- 
2.47.3

On 3/5/26 9:15 PM, Pierrick Bouvier wrote:
> When using llvm-addr2line in replacement of addr2line, it will output
> zero sized symbols, which can shadow other binaries depending on where
> there location is (happens with arm-trusted-firmware and its different
> binaries). Thus, those symbols.
> 
> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
> ---
>   contrib/plugins/uftrace_symbols.py | 2 ++
>   1 file changed, 2 insertions(+)
> 

This was merged into master (a8ff516c2f5ec05fb8b8bf4bceb88f49701f80d6).

Regards,
Pierrick

On Mon, 9 Mar 2026, Pierrick Bouvier wrote:
> On 3/5/26 9:15 PM, Pierrick Bouvier wrote:
>> When using llvm-addr2line in replacement of addr2line, it will output
>> zero sized symbols, which can shadow other binaries depending on where
>> there location is (happens with arm-trusted-firmware and its different
>> binaries). Thus, those symbols.
>> 
>> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
>> ---
>>   contrib/plugins/uftrace_symbols.py | 2 ++
>>   1 file changed, 2 insertions(+)
>> 
>
> This was merged into master (a8ff516c2f5ec05fb8b8bf4bceb88f49701f80d6).

I doubt the usefulness of such messages. People will know when pulling 
from git and this list already has high enough volume. If you think this 
is useful for contributors could you please send such mails off list only 
to involved parties?

Getting messages about patches being queued is useful for other 
maintainers and contributors to know the patches are picked up and then 
they will also see the pull request on the list and when the pull request 
got merged. Getting separate messages for each patch in a pull request 
does not add more info to that for people already following the list.

Regards,
BALATON Zoltan

On 3/9/26 9:38 AM, BALATON Zoltan wrote:
> On Mon, 9 Mar 2026, Pierrick Bouvier wrote:
>> On 3/5/26 9:15 PM, Pierrick Bouvier wrote:
>>> When using llvm-addr2line in replacement of addr2line, it will output
>>> zero sized symbols, which can shadow other binaries depending on where
>>> there location is (happens with arm-trusted-firmware and its different
>>> binaries). Thus, those symbols.
>>>
>>> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
>>> ---
>>>    contrib/plugins/uftrace_symbols.py | 2 ++
>>>    1 file changed, 2 insertions(+)
>>>
>>
>> This was merged into master (a8ff516c2f5ec05fb8b8bf4bceb88f49701f80d6).
> 
> I doubt the usefulness of such messages. People will know when pulling
> from git and this list already has high enough volume. If you think this
> is useful for contributors could you please send such mails off list only
> to involved parties?
>

 From what I understand, since you were not directly CC on this series, 
your problem is not especially with the message in itself, but with the 
fact that "this list already has high enough volume". I personally don't 
suffer from that, even though being CC on all patches touching docs/, 
because my email workflow allows me to follow threads I have specific 
interest with, and ignore the rest.

In general, a mailing list is not something you are supposed to read 
exhaustively. Instead, you're supposed to track your personal interests 
out of it. For an analogy: When you go to your local supermarket, will 
you try to follow every conversation happening there?

If you feel it's too much for you, then maybe there is something to look 
into how you track the mailing list, and my advice would be to use a 
threaded view, with tags and mail filters to reduce the high volume you 
seem to receive on a daily basis. If you're interested, I can share my 
(simple) setup, and maybe you can get inspiration from it for your 
personal usage.

To be honest, I was thinking to organize a small BoF on next KVM Forum 
to allow people to share their personal tips with handling emails.
It seems to be a common issue, and some maintainers even missed some 
series they were supposed to review, or to pull them. For myself as 
well, it took quite some time before having a correct workflow. I even 
went through the idea of "reading everything" and quickly dropped it as 
it was unbearable.

> Getting messages about patches being queued is useful for other
> maintainers and contributors to know the patches are picked up and then
> they will also see the pull request on the list and when the pull request
> got merged. Getting separate messages for each patch in a pull request
> does not add more info to that for people already following the list.
>

Except that some maintainers, including me, don't cc original authors 
when sending a PR (that's a deliberate decision). As well, some top 
maintainers don't always send back a message once the PR is done. Or 
they don't include all authors on individual patches.

So for consistency and the series I personnally track, yes, I believe 
there is a value in notifiying original series and author.

It's totally right for you to mention you don't like it, feel free to 
ignore the message. However, I feel it's a bit beyond your rights to 
decide what people can or can't send on mailing list when you are not in 
CC on the concerned thread, don't you think?

Regards,
Pierrick

On Mon, 9 Mar 2026, Pierrick Bouvier wrote:
> On 3/9/26 9:38 AM, BALATON Zoltan wrote:
>> On Mon, 9 Mar 2026, Pierrick Bouvier wrote:
>>> On 3/5/26 9:15 PM, Pierrick Bouvier wrote:
>>>> When using llvm-addr2line in replacement of addr2line, it will output
>>>> zero sized symbols, which can shadow other binaries depending on where
>>>> there location is (happens with arm-trusted-firmware and its different
>>>> binaries). Thus, those symbols.
>>>> 
>>>> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
>>>> ---
>>>>    contrib/plugins/uftrace_symbols.py | 2 ++
>>>>    1 file changed, 2 insertions(+)
>>>> 
>>> 
>>> This was merged into master (a8ff516c2f5ec05fb8b8bf4bceb88f49701f80d6).
>> 
>> I doubt the usefulness of such messages. People will know when pulling
>> from git and this list already has high enough volume. If you think this
>> is useful for contributors could you please send such mails off list only
>> to involved parties?
>
> From what I understand, since you were not directly CC on this series, your 
> problem is not especially with the message in itself, but with the fact that 
> "this list already has high enough volume". I personally don't suffer from 
> that, even though being CC on all patches touching docs/, because my email 
> workflow allows me to follow threads I have specific interest with, and 
> ignore the rest.
>
> In general, a mailing list is not something you are supposed to read 
> exhaustively. Instead, you're supposed to track your personal interests out 
> of it. For an analogy: When you go to your local supermarket, will you try to 
> follow every conversation happening there?
>
> If you feel it's too much for you, then maybe there is something to look into 
> how you track the mailing list, and my advice would be to use a threaded 
> view, with tags and mail filters to reduce the high volume you seem to 
> receive on a daily basis. If you're interested, I can share my (simple) 
> setup, and maybe you can get inspiration from it for your personal usage.

Threaded view does not help because the thread is already deleted when the 
separate "this patch was merged with commit hash" message arrives so it 
will show up at top level again. Ignoring everyting not cc'd to me would 
make me miss useful info about where the project goes or being able to 
review a few patches because I would not see them.

> To be honest, I was thinking to organize a small BoF on next KVM Forum to 
> allow people to share their personal tips with handling emails.
> It seems to be a common issue, and some maintainers even missed some series 
> they were supposed to review, or to pull them. For myself as well, it took 
> quite some time before having a correct workflow. I even went through the 
> idea of "reading everything" and quickly dropped it as it was unbearable.

This also suggests maybe there's too much traffic on the list so it would 
be useful to think about how to reduce it. However maintainers are 
supposed to be cc'd on series they should care about so they should not 
miss them but maybe the problem here is more that there are a lot of areas 
without maintainers listed or those in the MAINTAINERS file don't respond 
even if cc'd. Just email workflow may not help with that.

>> Getting messages about patches being queued is useful for other
>> maintainers and contributors to know the patches are picked up and then
>> they will also see the pull request on the list and when the pull request
>> got merged. Getting separate messages for each patch in a pull request
>> does not add more info to that for people already following the list.
>> 
>
> Except that some maintainers, including me, don't cc original authors when 
> sending a PR (that's a deliberate decision). As well, some top maintainers 
> don't always send back a message once the PR is done. Or they don't include 
> all authors on individual patches.

I don't think that's a problem. If somebody is interested they could 
follow the list or filter it e.g. for their S-o-b or simliar to get those 
messages or pull requests even without being cc'd.

> So for consistency and the series I personnally track, yes, I believe there 
> is a value in notifiying original series and author.

I'm OK with that, what I doubted is that it is useful to send this to the 
list too. Wouldn't it be enough to only send it to the people involved off 
list?

> It's totally right for you to mention you don't like it, feel free to ignore 
> the message. However, I feel it's a bit beyond your rights to decide what 
> people can or can't send on mailing list when you are not in CC on the 
> concerned thread, don't you think?

And that's what I did. Mentioned that I don't like it and asked if this is 
really something others want or think it's useful to get these messages on 
the list or could it be done without increasing list traffic. How did you 
get the impression I told you not to send such messages at all? Just asked 
if it's really necessary for everybody on the list? The same way don't you 
think it's beyond your right to decide how I choose to read the list? I 
think this is a misunderstanding and I don't want to tell you what to do 
but wanted to discuss if there's a better way to do this and tell you my 
opinion. Don't know why you felt offended.

Regards,
BALATON Zoltan

On 3/9/26 10:35 AM, BALATON Zoltan wrote:
> On Mon, 9 Mar 2026, Pierrick Bouvier wrote:
>> On 3/9/26 9:38 AM, BALATON Zoltan wrote:
>>> On Mon, 9 Mar 2026, Pierrick Bouvier wrote:
>>>> On 3/5/26 9:15 PM, Pierrick Bouvier wrote:
>>>>> When using llvm-addr2line in replacement of addr2line, it will output
>>>>> zero sized symbols, which can shadow other binaries depending on where
>>>>> there location is (happens with arm-trusted-firmware and its different
>>>>> binaries). Thus, those symbols.
>>>>>
>>>>> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
>>>>> ---
>>>>>     contrib/plugins/uftrace_symbols.py | 2 ++
>>>>>     1 file changed, 2 insertions(+)
>>>>>
>>>>
>>>> This was merged into master (a8ff516c2f5ec05fb8b8bf4bceb88f49701f80d6).
>>>
>>> I doubt the usefulness of such messages. People will know when pulling
>>> from git and this list already has high enough volume. If you think this
>>> is useful for contributors could you please send such mails off list only
>>> to involved parties?
>>
>>  From what I understand, since you were not directly CC on this series, your
>> problem is not especially with the message in itself, but with the fact that
>> "this list already has high enough volume". I personally don't suffer from
>> that, even though being CC on all patches touching docs/, because my email
>> workflow allows me to follow threads I have specific interest with, and
>> ignore the rest.
>>
>> In general, a mailing list is not something you are supposed to read
>> exhaustively. Instead, you're supposed to track your personal interests out
>> of it. For an analogy: When you go to your local supermarket, will you try to
>> follow every conversation happening there?
>>
>> If you feel it's too much for you, then maybe there is something to look into
>> how you track the mailing list, and my advice would be to use a threaded
>> view, with tags and mail filters to reduce the high volume you seem to
>> receive on a daily basis. If you're interested, I can share my (simple)
>> setup, and maybe you can get inspiration from it for your personal usage.
> 
> Threaded view does not help because the thread is already deleted when the
> separate "this patch was merged with commit hash" message arrives so it
> will show up at top level again. Ignoring everyting not cc'd to me would
> make me miss useful info about where the project goes or being able to
> review a few patches because I would not see them.
>

So, that's the issue, deleting existing threads breaks the context 
indeed. It's like working with git repositories at -depth 1 and trying 
to use 'git log' on a specific file.

Personally, I mark messages as read instead of deleting them and use 
"View -> Threads -> Threads with Unread". It has the added benefit that 
you can search efficiently through past conversations also.

Every N months, you can run a manual "archive" command (i.e. move to 
another INBOX subfolder) on messages older than N months and your 
qemu-devel INBOX will keep a constant size.

If you email client gets in the way, switch to another one.

>> To be honest, I was thinking to organize a small BoF on next KVM Forum to
>> allow people to share their personal tips with handling emails.
>> It seems to be a common issue, and some maintainers even missed some series
>> they were supposed to review, or to pull them. For myself as well, it took
>> quite some time before having a correct workflow. I even went through the
>> idea of "reading everything" and quickly dropped it as it was unbearable.
> 
> This also suggests maybe there's too much traffic on the list so it would
> be useful to think about how to reduce it. However maintainers are
> supposed to be cc'd on series they should care about so they should not
> miss them but maybe the problem here is more that there are a lot of areas
> without maintainers listed or those in the MAINTAINERS file don't respond
> even if cc'd. Just email workflow may not help with that.
>

That's true, some series fall through the cracks. That's why I applied 
to maintain docs/ to collect series/patches that might have been missed 
there. If you care about some specific subsystems, I encourage you to 
apply for becoming maintainer on the concerned top folder, so you can 
collect what is not by other maintainers.

>>> Getting messages about patches being queued is useful for other
>>> maintainers and contributors to know the patches are picked up and then
>>> they will also see the pull request on the list and when the pull request
>>> got merged. Getting separate messages for each patch in a pull request
>>> does not add more info to that for people already following the list.
>>>
>>
>> Except that some maintainers, including me, don't cc original authors when
>> sending a PR (that's a deliberate decision). As well, some top maintainers
>> don't always send back a message once the PR is done. Or they don't include
>> all authors on individual patches.
> 
> I don't think that's a problem. If somebody is interested they could
> follow the list or filter it e.g. for their S-o-b or simliar to get those
> messages or pull requests even without being cc'd.
>

In the case of TCG plugins, a lot of contributors are new comers and are 
not used to all this. I personally don't want to put the pressure on 
them to configure this kind of complicated setup, but prefer to offer 
them a GitHub/GitLab like experience. The series is a PR/MR, and when 
it's merged, the forge notify them it is.

Sending email patches is already a pain in itself for newcomers, no need 
to ask them to configure email filters on top of that.

>> So for consistency and the series I personnally track, yes, I believe there
>> is a value in notifiying original series and author.
> 
> I'm OK with that, what I doubted is that it is useful to send this to the
> list too. Wouldn't it be enough to only send it to the people involved off
> list?
>

It does not notify only original author, but other maintainers or 
reviewers also. As a concrete example, I'm sure you already went through 
a thread where someone was reviewing code already merged. With such 
notification, it would not have happened.

If you started arguing about the message itself, it would be an 
interesting debate. But your point is "My email workflow is A, and I 
don't like B, please change B". So my polite answer is "Your email 
workflow is A, and you don't like B, so change A". We can run in circles 
for hours I guess.

>> It's totally right for you to mention you don't like it, feel free to ignore
>> the message. However, I feel it's a bit beyond your rights to decide what
>> people can or can't send on mailing list when you are not in CC on the
>> concerned thread, don't you think?
> 
> And that's what I did. Mentioned that I don't like it and asked if this is
> really something others want or think it's useful to get these messages on
> the list or could it be done without increasing list traffic. How did you
> get the impression I told you not to send such messages at all? Just asked
> if it's really necessary for everybody on the list? The same way don't you
> think it's beyond your right to decide how I choose to read the list? I
> think this is a misunderstanding and I don't want to tell you what to do
> but wanted to discuss if there's a better way to do this and tell you my
> opinion. Don't know why you felt offended.
>

 > How did you get the impression I told you not to send such messages 
at all?
From: If you think this is useful for contributors could you please send 
such mails off list only to involved parties?

Reading it again, you are right, it can be seen as a polite suggestion, 
even though I read it as a mandatory request first.

I didn't feel offended, but felt like you were trying to control what 
someone can or can't send on mailing list, which is a big NO for me. I 
would react the same way on any other thread where I would read the same 
kind of message.
On the same note, I didn't try to control how you read the list, but to 
suggest a better workflow, because I sincerely think deleting threads 
and reading all new messages is not a good workflow.
It personally doesn't affect me, as long as you don't come to ask here 
how to reduce number of emails sent.

Regards,
Pierrick

On Mon, 9 Mar 2026, Pierrick Bouvier wrote:
> On 3/9/26 10:35 AM, BALATON Zoltan wrote:
>> On Mon, 9 Mar 2026, Pierrick Bouvier wrote:
>>> On 3/9/26 9:38 AM, BALATON Zoltan wrote:
>>>> On Mon, 9 Mar 2026, Pierrick Bouvier wrote:
>>>>> On 3/5/26 9:15 PM, Pierrick Bouvier wrote:
>>>>>> When using llvm-addr2line in replacement of addr2line, it will output
>>>>>> zero sized symbols, which can shadow other binaries depending on where
>>>>>> there location is (happens with arm-trusted-firmware and its different
>>>>>> binaries). Thus, those symbols.
>>>>>> 
>>>>>> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
>>>>>> ---
>>>>>>     contrib/plugins/uftrace_symbols.py | 2 ++
>>>>>>     1 file changed, 2 insertions(+)
>>>>>> 
>>>>> 
>>>>> This was merged into master (a8ff516c2f5ec05fb8b8bf4bceb88f49701f80d6).
>>>> 
>>>> I doubt the usefulness of such messages. People will know when pulling
>>>> from git and this list already has high enough volume. If you think this
>>>> is useful for contributors could you please send such mails off list only
>>>> to involved parties?
>>>
>>>  From what I understand, since you were not directly CC on this series, 
>>> your
>>> problem is not especially with the message in itself, but with the fact 
>>> that
>>> "this list already has high enough volume". I personally don't suffer from
>>> that, even though being CC on all patches touching docs/, because my email
>>> workflow allows me to follow threads I have specific interest with, and
>>> ignore the rest.
>>> 
>>> In general, a mailing list is not something you are supposed to read
>>> exhaustively. Instead, you're supposed to track your personal interests 
>>> out
>>> of it. For an analogy: When you go to your local supermarket, will you try 
>>> to
>>> follow every conversation happening there?
>>> 
>>> If you feel it's too much for you, then maybe there is something to look 
>>> into
>>> how you track the mailing list, and my advice would be to use a threaded
>>> view, with tags and mail filters to reduce the high volume you seem to
>>> receive on a daily basis. If you're interested, I can share my (simple)
>>> setup, and maybe you can get inspiration from it for your personal usage.
>> 
>> Threaded view does not help because the thread is already deleted when the
>> separate "this patch was merged with commit hash" message arrives so it
>> will show up at top level again. Ignoring everyting not cc'd to me would
>> make me miss useful info about where the project goes or being able to
>> review a few patches because I would not see them.
>> 
>
> So, that's the issue, deleting existing threads breaks the context indeed. 
> It's like working with git repositories at -depth 1 and trying to use 'git 
> log' on a specific file.
>
> Personally, I mark messages as read instead of deleting them and use "View -> 
> Threads -> Threads with Unread". It has the added benefit that you can search 
> efficiently through past conversations also.
>
> Every N months, you can run a manual "archive" command (i.e. move to another 
> INBOX subfolder) on messages older than N months and your qemu-devel INBOX 
> will keep a constant size.

Glad that it works for you but I have a limited mail quota so I have to 
delete read messages.

> If you email client gets in the way, switch to another one.

Please let me decide what I do.

>>> To be honest, I was thinking to organize a small BoF on next KVM Forum to
>>> allow people to share their personal tips with handling emails.
>>> It seems to be a common issue, and some maintainers even missed some 
>>> series
>>> they were supposed to review, or to pull them. For myself as well, it took
>>> quite some time before having a correct workflow. I even went through the
>>> idea of "reading everything" and quickly dropped it as it was unbearable.
>> 
>> This also suggests maybe there's too much traffic on the list so it would
>> be useful to think about how to reduce it. However maintainers are
>> supposed to be cc'd on series they should care about so they should not
>> miss them but maybe the problem here is more that there are a lot of areas
>> without maintainers listed or those in the MAINTAINERS file don't respond
>> even if cc'd. Just email workflow may not help with that.
>> 
>
> That's true, some series fall through the cracks. That's why I applied to 
> maintain docs/ to collect series/patches that might have been missed there. 
> If you care about some specific subsystems, I encourage you to apply for 
> becoming maintainer on the concerned top folder, so you can collect what is 
> not by other maintainers.

I'm already listed as maintainer of the machines I contributed and some 
other devices they use and were orphaned and I try to help reviewing and 
sharing ideas where I can. But I do this unpayed in free time so I would 
not take up more than I can do.

>>>> Getting messages about patches being queued is useful for other
>>>> maintainers and contributors to know the patches are picked up and then
>>>> they will also see the pull request on the list and when the pull request
>>>> got merged. Getting separate messages for each patch in a pull request
>>>> does not add more info to that for people already following the list.
>>>> 
>>> 
>>> Except that some maintainers, including me, don't cc original authors when
>>> sending a PR (that's a deliberate decision). As well, some top maintainers
>>> don't always send back a message once the PR is done. Or they don't 
>>> include
>>> all authors on individual patches.
>> 
>> I don't think that's a problem. If somebody is interested they could
>> follow the list or filter it e.g. for their S-o-b or simliar to get those
>> messages or pull requests even without being cc'd.
>> 
>
> In the case of TCG plugins, a lot of contributors are new comers and are not 
> used to all this. I personally don't want to put the pressure on them to 
> configure this kind of complicated setup, but prefer to offer them a 
> GitHub/GitLab like experience. The series is a PR/MR, and when it's merged, 
> the forge notify them it is.
>
> Sending email patches is already a pain in itself for newcomers, no need to 
> ask them to configure email filters on top of that.

But you have no problem putting that pressure on me :-). Yes I know it can 
be a pain for newcomers and did not say these messages can't be useful to 
them. But I can't follow your logic about sending these to the list. You 
say that they won't see if their patch were merged because they won't 
follow the list because it gets too many messages. So you need to cc them 
but you also send that to the list where they won't read it anyway so it 
just increases the volume of the list even more with messages that those 
on the list will just have to ignore. Wouldn't it be simpler to not send 
these messages to the list if those interested are already cc'd because 
they are not expected to read the list?

>>> So for consistency and the series I personnally track, yes, I believe 
>>> there
>>> is a value in notifiying original series and author.
>> 
>> I'm OK with that, what I doubted is that it is useful to send this to the
>> list too. Wouldn't it be enough to only send it to the people involved off
>> list?
>> 
>
> It does not notify only original author, but other maintainers or reviewers 
> also. As a concrete example, I'm sure you already went through a thread where 
> someone was reviewing code already merged. With such notification, it would 
> not have happened.

I'm not sure about that. If they are not on cc they would miss this 
message on the list the same way they missed the pull request. If they are 
on cc they would see this message without it being sent to the list too.

> If you started arguing about the message itself, it would be an interesting 
> debate. But your point is "My email workflow is A, and I don't like B, please 
> change B". So my polite answer is "Your email workflow is A, and you don't 
> like B, so change A". We can run in circles for hours I guess.

I'm arguing about if it's useful to send these messages to the list. My 
workflow is an example but just ignore that for now to avoid 
misunderstandings. If you say that you need to send these messages because 
those people won't follow the list then I think it's not useful to spam 
the list where nobody would read these messages just in case somebody 
might read them. I don't care if you send them off list or not and if 
others think that it's useful on the list I'm also OK with that but I 
don't see what this would add to the already sent pull requests and pull 
applied messages already sent to the list for those who follow the list.

>>> It's totally right for you to mention you don't like it, feel free to 
>>> ignore
>>> the message. However, I feel it's a bit beyond your rights to decide what
>>> people can or can't send on mailing list when you are not in CC on the
>>> concerned thread, don't you think?
>> 
>> And that's what I did. Mentioned that I don't like it and asked if this is
>> really something others want or think it's useful to get these messages on
>> the list or could it be done without increasing list traffic. How did you
>> get the impression I told you not to send such messages at all? Just asked
>> if it's really necessary for everybody on the list? The same way don't you
>> think it's beyond your right to decide how I choose to read the list? I
>> think this is a misunderstanding and I don't want to tell you what to do
>> but wanted to discuss if there's a better way to do this and tell you my
>> opinion. Don't know why you felt offended.
>> 
>
>> How did you get the impression I told you not to send such messages at all?
> From: If you think this is useful for contributors could you please send such 
> mails off list only to involved parties?
>
> Reading it again, you are right, it can be seen as a polite suggestion, even 
> though I read it as a mandatory request first.
>
> I didn't feel offended, but felt like you were trying to control what someone 
> can or can't send on mailing list, which is a big NO for me. I would react 
> the same way on any other thread where I would read the same kind of message.

No problem, may be a language issue and too direct way of telling things.

Regards,
BALATON Zoltan

On 3/9/26 11:50 AM, BALATON Zoltan wrote:
>> Every N months, you can run a manual "archive" command (i.e. move to another
>> INBOX subfolder) on messages older than N months and your qemu-devel INBOX
>> will keep a constant size.
> 
> Glad that it works for you but I have a limited mail quota so I have to
> delete read messages.
>

Let me update my suggestion with something that would work in your case.

Every N *weeks*, you can run a manual "delete" command on messages older 
than N weeks and your qemu-devel INBOX will keep a constant size under 
your quota.

The key is to not delete thread as soon as you receive them, but keep 
context for a few weeks, similar to keeping your git clone to a constant 
-depth=N because your disk space could be limited.

It's a win-win: you keep semantic context *and* your quota stays under 
control.

>>>>> Getting messages about patches being queued is useful for other
>>>>> maintainers and contributors to know the patches are picked up and then
>>>>> they will also see the pull request on the list and when the pull request
>>>>> got merged. Getting separate messages for each patch in a pull request
>>>>> does not add more info to that for people already following the list.
>>>>>
>>>>
>>>> Except that some maintainers, including me, don't cc original authors when
>>>> sending a PR (that's a deliberate decision). As well, some top maintainers
>>>> don't always send back a message once the PR is done. Or they don't
>>>> include
>>>> all authors on individual patches.
>>>
>>> I don't think that's a problem. If somebody is interested they could
>>> follow the list or filter it e.g. for their S-o-b or simliar to get those
>>> messages or pull requests even without being cc'd.
>>>
>>
>> In the case of TCG plugins, a lot of contributors are new comers and are not
>> used to all this. I personally don't want to put the pressure on them to
>> configure this kind of complicated setup, but prefer to offer them a
>> GitHub/GitLab like experience. The series is a PR/MR, and when it's merged,
>> the forge notify them it is.
>>
>> Sending email patches is already a pain in itself for newcomers, no need to
>> ask them to configure email filters on top of that.
> 
> But you have no problem putting that pressure on me :-). Yes I know it can
> be a pain for newcomers and did not say these messages can't be useful to
> them. But I can't follow your logic about sending these to the list. You
> say that they won't see if their patch were merged because they won't
> follow the list because it gets too many messages. So you need to cc them
> but you also send that to the list where they won't read it anyway so it
> just increases the volume of the list even more with messages that those
> on the list will just have to ignore. Wouldn't it be simpler to not send
> these messages to the list if those interested are already cc'd because
> they are not expected to read the list?
>

Answering below.

>>>> So for consistency and the series I personnally track, yes, I believe
>>>> there
>>>> is a value in notifiying original series and author.
>>>
>>> I'm OK with that, what I doubted is that it is useful to send this to the
>>> list too. Wouldn't it be enough to only send it to the people involved off
>>> list?
>>>
>>
>> It does not notify only original author, but other maintainers or reviewers
>> also. As a concrete example, I'm sure you already went through a thread where
>> someone was reviewing code already merged. With such notification, it would
>> not have happened.
> 
> I'm not sure about that. If they are not on cc they would miss this
> message on the list the same way they missed the pull request. If they are
> on cc they would see this message without it being sent to the list too.
>
>> If you started arguing about the message itself, it would be an interesting
>> debate. But your point is "My email workflow is A, and I don't like B, please
>> change B". So my polite answer is "Your email workflow is A, and you don't
>> like B, so change A". We can run in circles for hours I guess.
> 
> I'm arguing about if it's useful to send these messages to the list. My
> workflow is an example but just ignore that for now to avoid
> misunderstandings. If you say that you need to send these messages because
> those people won't follow the list then I think it's not useful to spam
> the list where nobody would read these messages just in case somebody
> might read them. I don't care if you send them off list or not and if
> others think that it's useful on the list I'm also OK with that but I
> don't see what this would add to the already sent pull requests and pull
> applied messages already sent to the list for those who follow the list.
> 

They might not be in pull request messages recipients, or didn't 
configure ad hoc filters for that, so they might have missed that.

As well, for people reading the thread afterward from lore.kernel.org, 
it confirms the series was merged and the topic is closed, without 
needing to check manually in git log, parse pull requests, or check on 
patchew status of series. You'll notice that I always send an update 
email when posting a new version to link to new version also, to "close" 
a given version, in a similar way. See it as an email ladder version -> 
version -> version -> notify_merged.

I didn't invent any of this but simply mimic what GitHub and GitLab (and 
other forges) do. They notify you on new versions, on final merge, and 
you're free to unsubscribe from a PR if you're not interested.

Once again, I totally respect you don't find it useful, feel free to 
delete and ignore those messages.

Regards,
Pierrick

On Mon, 9 Mar 2026, Pierrick Bouvier wrote:
> On 3/9/26 11:50 AM, BALATON Zoltan wrote:
>>> Every N months, you can run a manual "archive" command (i.e. move to 
>>> another
>>> INBOX subfolder) on messages older than N months and your qemu-devel INBOX
>>> will keep a constant size.
>> 
>> Glad that it works for you but I have a limited mail quota so I have to
>> delete read messages.
>> 
>
> Let me update my suggestion with something that would work in your case.
>
> Every N *weeks*, you can run a manual "delete" command on messages older than 
> N weeks and your qemu-devel INBOX will keep a constant size under your quota.
>
> The key is to not delete thread as soon as you receive them, but keep context 
> for a few weeks, similar to keeping your git clone to a constant -depth=N 
> because your disk space could be limited.
>
> It's a win-win: you keep semantic context *and* your quota stays under 
> control.

You complained why I want to tell you what you should do but you keep 
telling me what should I do instead. I say again, please let me decide how 
I read the list. I'm fine with the way I do it now. I don't want to keep 
context for months or weeks (there are tools like patchew or list archives 
for that already where I can look it up if needed) so I only keep locally 
what I need in the short term. This is fine as long as the related 
messages come threaded at once but with these mails it would come some 
indefinite time after the pull request and I'd end up with as many 
separate mails as many patches were in a pull request. That can be many 
and the only way to thread them would be to keep at least the covers of 
all pull requests for who knows how long.

>> I'm arguing about if it's useful to send these messages to the list. My
>> workflow is an example but just ignore that for now to avoid
>> misunderstandings. If you say that you need to send these messages because
>> those people won't follow the list then I think it's not useful to spam
>> the list where nobody would read these messages just in case somebody
>> might read them. I don't care if you send them off list or not and if
>> others think that it's useful on the list I'm also OK with that but I
>> don't see what this would add to the already sent pull requests and pull
>> applied messages already sent to the list for those who follow the list.
>> 
>
> They might not be in pull request messages recipients, or didn't configure ad 
> hoc filters for that, so they might have missed that.
>
> As well, for people reading the thread afterward from lore.kernel.org, it 
> confirms the series was merged and the topic is closed, without needing to 
> check manually in git log, parse pull requests, or check on patchew status of 
> series. You'll notice that I always send an update email when posting a new 
> version to link to new version also, to "close" a given version, in a similar 
> way. See it as an email ladder version -> version -> version -> 
> notify_merged.

OK at least this gives a reason why sending to the list might be useful 
for some to track a pull later on lore.kernel.org. There are already other 
similar systems but some may prefer this.

> I didn't invent any of this but simply mimic what GitHub and GitLab (and

But you started doing it on the QEMU list. Some other maintainers cc 
patches in pull requests also to authors, some others don't and you 
introduced yet another solution. So you kind of invented it here as we did 
without it for quite a while and nobody complained. That does not mean 
this can't be useful for some but could you at least consider doing it in 
a way that works for everybody?

> other forges) do. They notify you on new versions, on final merge, and you're 
> free to unsubscribe from a PR if you're not interested.

That's exactly the issue. With those forges I could subscribe or 
unsubscribe to/from these but here you decided I should be subscribed and 
left not much way to unsibscribe.

> Once again, I totally respect you don't find it useful, feel free to delete 
> and ignore those messages.

Could you at least make it easy to filter and delete them? Like sending 
them with a cover letter threaded at once or adding [MERGED] to the 
subject or something similar so they are easily filtered and not just tell 
me to deal with it if I don't like it?

Regards,
BALATON Zoltan

On 3/9/26 4:44 PM, BALATON Zoltan wrote:
> On Mon, 9 Mar 2026, Pierrick Bouvier wrote:
>> On 3/9/26 11:50 AM, BALATON Zoltan wrote:
>>>> Every N months, you can run a manual "archive" command (i.e. move to
>>>> another
>>>> INBOX subfolder) on messages older than N months and your qemu-devel INBOX
>>>> will keep a constant size.
>>>
>>> Glad that it works for you but I have a limited mail quota so I have to
>>> delete read messages.
>>>
>>
>> Let me update my suggestion with something that would work in your case.
>>
>> Every N *weeks*, you can run a manual "delete" command on messages older than
>> N weeks and your qemu-devel INBOX will keep a constant size under your quota.
>>
>> The key is to not delete thread as soon as you receive them, but keep context
>> for a few weeks, similar to keeping your git clone to a constant -depth=N
>> because your disk space could be limited.
>>
>> It's a win-win: you keep semantic context *and* your quota stays under
>> control.
> 
> You complained why I want to tell you what you should do but you keep
> telling me what should I do instead. I say again, please let me decide how
> I read the list. I'm fine with the way I do it now. I don't want to keep
> context for months or weeks (there are tools like patchew or list archives
> for that already where I can look it up if needed) so I only keep locally
> what I need in the short term. This is fine as long as the related
> messages come threaded at once but with these mails it would come some
> indefinite time after the pull request and I'd end up with as many
> separate mails as many patches were in a pull request. That can be many
> and the only way to thread them would be to keep at least the covers of
> all pull requests for who knows how long.
>

I simply suggested a solution for the problem you had, and you are 
totally free to take it or leave it. It's not a "you should", but a "if 
you want, you could".
Now, if you leave it and want to read the mailing list in your own way, 
feel free to do it, but you're on your own to find a solution for issues 
that are related to it.

I'm politely repeating that asking anyone to not send a specific message 
on a public mailing list because it breaks your personal workflow is not 
a realistic demand, you need to find on your side a way to ignore the 
content you don't want to see. That's how a shared space work.

>>> I'm arguing about if it's useful to send these messages to the list. My
>>> workflow is an example but just ignore that for now to avoid
>>> misunderstandings. If you say that you need to send these messages because
>>> those people won't follow the list then I think it's not useful to spam
>>> the list where nobody would read these messages just in case somebody
>>> might read them. I don't care if you send them off list or not and if
>>> others think that it's useful on the list I'm also OK with that but I
>>> don't see what this would add to the already sent pull requests and pull
>>> applied messages already sent to the list for those who follow the list.
>>>
>>
>> They might not be in pull request messages recipients, or didn't configure ad
>> hoc filters for that, so they might have missed that.
>>
>> As well, for people reading the thread afterward from lore.kernel.org, it
>> confirms the series was merged and the topic is closed, without needing to
>> check manually in git log, parse pull requests, or check on patchew status of
>> series. You'll notice that I always send an update email when posting a new
>> version to link to new version also, to "close" a given version, in a similar
>> way. See it as an email ladder version -> version -> version ->
>> notify_merged.
> 
> OK at least this gives a reason why sending to the list might be useful
> for some to track a pull later on lore.kernel.org. There are already other
> similar systems but some may prefer this.
> 
>> I didn't invent any of this but simply mimic what GitHub and GitLab (and
> 
> But you started doing it on the QEMU list. Some other maintainers cc
> patches in pull requests also to authors, some others don't and you
> introduced yet another solution. So you kind of invented it here as we did
> without it for quite a while and nobody complained. That does not mean
> this can't be useful for some but could you at least consider doing it in
> a way that works for everybody?
>

In this case, feel free to start a topic and forbid this "officially" 
for everyone, including maintainers that sometimes report that code was 
merged, or that they pulled it in their own tree, as it's the same kind 
of semantic message. I would be very happy to obey to any new rule of 
conduct that would be added for the whole community.

>> other forges) do. They notify you on new versions, on final merge, and you're
>> free to unsubscribe from a PR if you're not interested.
> 
> That's exactly the issue. With those forges I could subscribe or
> unsubscribe to/from these but here you decided I should be subscribed and
> left not much way to unsibscribe.
>

There is a way to do it, by keeping threads context in your mailbox.
If you don't want, your need to invent another ad-hoc solution.

>> Once again, I totally respect you don't find it useful, feel free to delete
>> and ignore those messages.
> 
> Could you at least make it easy to filter and delete them? Like sending
> them with a cover letter threaded at once or adding [MERGED] to the
> subject or something similar so they are easily filtered and not just tell
> me to deal with it if I don't like it?
>

The message body will always be the same, as I use a template in my 
email client.
```
This was merged into master (.*).
Thank you for your contribution!

Regards,
Pierrick
```

Second line is optional because I don't thank myself when sending my own 
series.

So a simple email filter could be:
from: pierrick.bouvier@linaro.org
contains: 'This was merged into master (.*)'

Does that sound good to you?

> Regards,
> BALATON Zoltan

Regards,
Pierrick

On Mon, 9 Mar 2026, Pierrick Bouvier wrote:
>>> As well, for people reading the thread afterward from lore.kernel.org, it
>>> confirms the series was merged and the topic is closed, without needing to
>>> check manually in git log, parse pull requests, or check on patchew status 
>>> of
>>> series. You'll notice that I always send an update email when posting a 
>>> new
>>> version to link to new version also, to "close" a given version, in a 
>>> similar
>>> way. See it as an email ladder version -> version -> version ->
>>> notify_merged.
>> 
>> OK at least this gives a reason why sending to the list might be useful
>> for some to track a pull later on lore.kernel.org. There are already other
>> similar systems but some may prefer this.
>> 
>>> I didn't invent any of this but simply mimic what GitHub and GitLab (and
>> 
>> But you started doing it on the QEMU list. Some other maintainers cc
>> patches in pull requests also to authors, some others don't and you
>> introduced yet another solution. So you kind of invented it here as we did
>> without it for quite a while and nobody complained. That does not mean
>> this can't be useful for some but could you at least consider doing it in
>> a way that works for everybody?
>> 
>
> In this case, feel free to start a topic and forbid this "officially" for 
> everyone, including maintainers that sometimes report that code was merged, 
> or that they pulled it in their own tree, as it's the same kind of semantic 
> message. I would be very happy to obey to any new rule of conduct that would 
> be added for the whole community.

In that case maybe you should start a topic and agree on an official way. 
I don't want to forbid anything, just noted there's an inconsistency here 
and your way just added to that inconsistency besides making my life more 
difficult. I was questioning if it's useful to send such messages to the 
list as the reasoning for them was that people who don't follow the list 
might miss their patches were merged. That to me does not imply the list 
also needs these messages. Above you gave a reason to archive it in the 
list too so a lifecycle of a patch can be followed. OK that answers why 
the list might need these too.

>>> other forges) do. They notify you on new versions, on final merge, and 
>>> you're
>>> free to unsubscribe from a PR if you're not interested.
>> 
>> That's exactly the issue. With those forges I could subscribe or
>> unsubscribe to/from these but here you decided I should be subscribed and
>> left not much way to unsibscribe.
>> 
>
> There is a way to do it, by keeping threads context in your mailbox.
> If you don't want, your need to invent another ad-hoc solution.
>
>>> Once again, I totally respect you don't find it useful, feel free to 
>>> delete
>>> and ignore those messages.
>> 
>> Could you at least make it easy to filter and delete them? Like sending
>> them with a cover letter threaded at once or adding [MERGED] to the
>> subject or something similar so they are easily filtered and not just tell
>> me to deal with it if I don't like it?
>> 
>
> The message body will always be the same, as I use a template in my email 
> client.
> ```
> This was merged into master (.*).
> Thank you for your contribution!
>
> Regards,
> Pierrick
> ```
>
> Second line is optional because I don't thank myself when sending my own 
> series.
>
> So a simple email filter could be:
> from: pierrick.bouvier@linaro.org
> contains: 'This was merged into master (.*)'
>
> Does that sound good to you?

That helps as long as you're the only one sending these otherwise "from" 
is not the same. It would be even better it you could also change the 
label in the subject to [MERGED] as it's easier to filter by headers 
(faster than content search) and that may also help more easily tracking 
the lifecycle later so you'd see [PATCH vXX] -> [PULL] -> [MERGED}. Or add 
some header specific to these messages.

Regards,
BALATON Zoltan

On 3/10/26 5:44 AM, BALATON Zoltan wrote:
>>> Could you at least make it easy to filter and delete them? Like sending
>>> them with a cover letter threaded at once or adding [MERGED] to the
>>> subject or something similar so they are easily filtered and not just tell
>>> me to deal with it if I don't like it?
>>>
>>
>> The message body will always be the same, as I use a template in my email
>> client.
>> ```
>> This was merged into master (.*).
>> Thank you for your contribution!
>>
>> Regards,
>> Pierrick
>> ```
>>
>> Second line is optional because I don't thank myself when sending my own
>> series.
>>
>> So a simple email filter could be:
>> from: pierrick.bouvier@linaro.org
>> contains: 'This was merged into master (.*)'
>>
>> Does that sound good to you?
> 
> That helps as long as you're the only one sending these otherwise "from"
> is not the same. It would be even better it you could also change the
> label in the subject to [MERGED] as it's easier to filter by headers
> (faster than content search) and that may also help more easily tracking
> the lifecycle later so you'd see [PATCH vXX] -> [PULL] -> [MERGED}. Or add
> some header specific to these messages.
>

Unfortunately I can't do this with template, that only can have a fixed 
subject, and not reuse existing subject + a prefix.
If I use a manual process, I'm pretty sure I will get it wrong at some 
point, so I prefer not to promise something that will end up being 
inconsistent.

> Regards,
> BALATON Zoltan

Regards,
Pierrick

On 3/5/26 9:15 PM, Pierrick Bouvier wrote:
> When using llvm-addr2line in replacement of addr2line, it will output
> zero sized symbols, which can shadow other binaries depending on where
> there location is (happens with arm-trusted-firmware and its different
> binaries). Thus, those symbols.
> 
> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
> ---
>   contrib/plugins/uftrace_symbols.py | 2 ++
>   1 file changed, 2 insertions(+)
> 

Auto review on this trivial patch, to send PR on time.
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>