Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1579170 > unrolled thread

[PATCH 2/2] arch/x86: Fix sparse warning symbol not declared

Started by"Tobin C. Harding" <me@tobin.cc>
First post2017-02-12 07:50 +0100
Last post2017-02-21 09:20 +0100
Articles 5 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  [PATCH 2/2] arch/x86: Fix sparse warning symbol not declared "Tobin C. Harding" <me@tobin.cc> - 2017-02-12 07:50 +0100
    Re: [PATCH 2/2] arch/x86: Fix sparse warning symbol not declared Thomas Gleixner <tglx@linutronix.de> - 2017-02-12 12:10 +0100
      Re: [PATCH 2/2] arch/x86: Fix sparse warning symbol not declared Tobin Harding <me@tobin.cc> - 2017-02-13 21:30 +0100
        Re: [PATCH 2/2] arch/x86: Fix sparse warning symbol not declared Thomas Gleixner <tglx@linutronix.de> - 2017-02-13 22:30 +0100
          Re: [PATCH 2/2] arch/x86: Fix sparse warning symbol not declared Tobin Harding <me@tobin.cc> - 2017-02-21 09:20 +0100

#1579170 — [PATCH 2/2] arch/x86: Fix sparse warning symbol not declared

From"Tobin C. Harding" <me@tobin.cc>
Date2017-02-12 07:50 +0100
Subject[PATCH 2/2] arch/x86: Fix sparse warning symbol not declared
Message-ID<t9W8W-2TD-11@gated-at.bofh.it>
This patch adds function declaration in order to quiet sparse symbol
not declared warning.

Signed-off-by: Tobin C. Harding <me@tobin.cc>
---

Unsure why adding declaration quiets sparse. This may not be the
correct solution. Only testing done is building and booting kernel.
Since 'purgatory' is called from assembler and does not need forward
declaration the only advantage to this patch seems to be to save the
next newbie from investigating the sparse warning.

arch/x86/purgatory/purgatory.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/purgatory/purgatory.c b/arch/x86/purgatory/purgatory.c
index 2a2cbe5..129433c 100644
--- a/arch/x86/purgatory/purgatory.c
+++ b/arch/x86/purgatory/purgatory.c
@@ -18,6 +18,8 @@ struct sha_region {
 	unsigned long len;
 };
 
+void purgatory(void);
+
 static unsigned long backup_dest = 0;
 static unsigned long backup_src = 0;
 static unsigned long backup_sz = 0;
-- 
2.7.4

[toc] | [next] | [standalone]


#1579195

FromThomas Gleixner <tglx@linutronix.de>
Date2017-02-12 12:10 +0100
Message-ID<ta0cx-5yR-11@gated-at.bofh.it>
In reply to#1579170
On Sun, 12 Feb 2017, Tobin C. Harding wrote:

> This patch adds function declaration in order to quiet sparse symbol
> not declared warning.

Same comment vs. 'This patch' as before. Hint, we already know that this is
a patch, otherwise it would be mislabeled.

> 
> Signed-off-by: Tobin C. Harding <me@tobin.cc>
> ---
> 
> Unsure why adding declaration quiets sparse.

Because sparse finds a declaration before the definition.

> This may not be the correct solution.

Right, it's not.

> Only testing done is building and booting kernel.  Since 'purgatory' is
> called from assembler and does not need forward declaration the only
> advantage to this patch seems to be to save the next newbie from
> investigating the sparse warning.

Well, yes. But just quietening a checker by slapping a pointless forward
declaration into the code is not pretty either. A smarter checker might
catch that.

The proper solution is to have a local include file 'purgatory.h' and put
the declaration there. Include it in both files even if that's not required
for the ASM file. But that documents, that the function is used outside of
purgatory.c

Thanks,

	tglx

[toc] | [prev] | [next] | [standalone]


#1580062

FromTobin Harding <me@tobin.cc>
Date2017-02-13 21:30 +0100
Message-ID<tavq2-6i-21@gated-at.bofh.it>
In reply to#1579195
On Sun, Feb 12, 2017 at 12:06:47PM +0100, Thomas Gleixner wrote:
> On Sun, 12 Feb 2017, Tobin C. Harding wrote:
> 
> > This patch adds function declaration in order to quiet sparse symbol
> > not declared warning.
> 
> Same comment vs. 'This patch' as before. Hint, we already know that this is
> a patch, otherwise it would be mislabeled.
> 
> > 
> > Signed-off-by: Tobin C. Harding <me@tobin.cc>
> > ---
> > 
> > Unsure why adding declaration quiets sparse.
> 
> Because sparse finds a declaration before the definition.
> 
> > This may not be the correct solution.
> 
> Right, it's not.
> 
> > Only testing done is building and booting kernel.  Since 'purgatory' is
> > called from assembler and does not need forward declaration the only
> > advantage to this patch seems to be to save the next newbie from
> > investigating the sparse warning.
> 
> Well, yes. But just quietening a checker by slapping a pointless forward
> declaration into the code is not pretty either. A smarter checker might
> catch that.
> 
> The proper solution is to have a local include file 'purgatory.h' and put
> the declaration there. Include it in both files even if that's not required
> for the ASM file. But that documents, that the function is used outside of
> purgatory.c

Blindly following instructions led to the bone headed patch I
submitted yesterday (without building). Is there some way to include a
C header in an ASM file that I do not know about?

Thanks for patiently pointing out how to write a commit log. May I
please bother you with another small etiquette question. Should I
have replayed to you as I have done so or should I have re-sent another
patch (v3) with the mistakes fixed (and stated in the log that I did
not know how to implement the suggestions).

thanks,
Tobin.

[toc] | [prev] | [next] | [standalone]


#1580086

FromThomas Gleixner <tglx@linutronix.de>
Date2017-02-13 22:30 +0100
Message-ID<tawm6-JH-25@gated-at.bofh.it>
In reply to#1580062
On Tue, 14 Feb 2017, Tobin Harding wrote:
> On Sun, Feb 12, 2017 at 12:06:47PM +0100, Thomas Gleixner wrote:
> > The proper solution is to have a local include file 'purgatory.h' and put
> > the declaration there. Include it in both files even if that's not required
> > for the ASM file. But that documents, that the function is used outside of
> > purgatory.c
> 
> Blindly following instructions led to the bone headed patch I
> submitted yesterday (without building). Is there some way to include a
> C header in an ASM file that I do not know about?

Yes, you have to guard the function declaration with

#ifndef __ASSEMBLY__

I did not think about that when I suggested this. Brainslip :)

So yes, it's kinda pointless, but it still has documentatory value and
keeps the sparse build clean.

> Thanks for patiently pointing out how to write a commit log. May I
> please bother you with another small etiquette question. Should I
> have replayed to you as I have done so or should I have re-sent another
> patch (v3) with the mistakes fixed (and stated in the log that I did
> not know how to implement the suggestions).

All good. Either way works as long as you notice your own mistakes. It's
also fine to tell me that I suggested nonsense. :)

Thanks,

	tglx

[toc] | [prev] | [next] | [standalone]


#1585104

FromTobin Harding <me@tobin.cc>
Date2017-02-21 09:20 +0100
Message-ID<tddPY-8nM-11@gated-at.bofh.it>
In reply to#1580086
On Tue, Feb 14, 2017, at 08:24 AM, Thomas Gleixner wrote:
> On Tue, 14 Feb 2017, Tobin Harding wrote:
> > On Sun, Feb 12, 2017 at 12:06:47PM +0100, Thomas Gleixner wrote:
> > > The proper solution is to have a local include file 'purgatory.h' and put
> > > the declaration there. Include it in both files even if that's not required
> > > for the ASM file. But that documents, that the function is used outside of
> > > purgatory.c
> > 
> > Blindly following instructions led to the bone headed patch I
> > submitted yesterday (without building). Is there some way to include a
> > C header in an ASM file that I do not know about?
> 
> Yes, you have to guard the function declaration with
> 
> #ifndef __ASSEMBLY__
> 
> I did not think about that when I suggested this. Brainslip :)
> 
> So yes, it's kinda pointless, but it still has documentatory value and
> keeps the sparse build clean.
> 
> > Thanks for patiently pointing out how to write a commit log. May I
> > please bother you with another small etiquette question. Should I
> > have replayed to you as I have done so or should I have re-sent another
> > patch (v3) with the mistakes fixed (and stated in the log that I did
> > not know how to implement the suggestions).
> 
> All good. Either way works as long as you notice your own mistakes. It's
> also fine to tell me that I suggested nonsense. :)
> 

It has been pointed out to me that I could have approached the dev
process of this patch better. In the name of learning the correct method
I am now replying to your comments Thomas. Thanks for being patient, if
you could please slap me if I slip I should be able to blossom into a
decent contributor.

After sending an incorrect version (v3) with the __ASSEMBLY__
preprocessor guard in the wrong place, I re-sent v4 with what I believe
is all of your comments implemented and functioning.

Thanks for taking the time to review my annoying multi-version almost
trivial patch series.

thanks,
Tobin.

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web