Hi all,
I have had these warnings for ages:
kernel/power/pm.c:241: warning: `pm_register' is deprecated (declared at
kernel/power/pm.c:64)
kernel/power/pm.c:241: warning: `pm_register' is deprecated (declared at
kernel/power/pm.c:64)
kernel/power/pm.c:242: warning: `pm_unregister_all' is deprecated (declared at
kernel/power/pm.c:97)
kernel/power/pm.c:242: warning: `pm_unregister_all' is deprecated (declared at
kernel/power/pm.c:97)
kernel/power/pm.c:243: warning: `pm_send_all' is deprecated (declared at
kernel/power/pm.c:216)
kernel/power/pm.c:243: warning: `pm_send_all' is deprecated (declared at
kernel/power/pm.c:216)
and I think at one time there was a fix about that I applied, but it seems it
never made it into kernel.org.
Or is this my ggc problem?
Thanks,
Nick
--
Every program has two purposes:
one for which it was written and another for which it wasn't.
On Tue, 8 Aug 2006 21:48:11 +0100 Nick Warne wrote:
> Hi all,
>
> I have had these warnings for ages:
>
> kernel/power/pm.c:241: warning: `pm_register' is deprecated (declared at
> kernel/power/pm.c:64)
> kernel/power/pm.c:241: warning: `pm_register' is deprecated (declared at
> kernel/power/pm.c:64)
> kernel/power/pm.c:242: warning: `pm_unregister_all' is deprecated (declared at
> kernel/power/pm.c:97)
> kernel/power/pm.c:242: warning: `pm_unregister_all' is deprecated (declared at
> kernel/power/pm.c:97)
> kernel/power/pm.c:243: warning: `pm_send_all' is deprecated (declared at
> kernel/power/pm.c:216)
> kernel/power/pm.c:243: warning: `pm_send_all' is deprecated (declared at
> kernel/power/pm.c:216)
>
> and I think at one time there was a fix about that I applied, but it seems it
> never made it into kernel.org.
>
> Or is this my ggc problem?
It's not a gcc (nor ggc) problem. Those functions are just deprecated.
Current 2.6.18-rc4 and 2.6.18-rc3-mm2 still have those same warnings.
fwiw, I don't seem to have any patches to fix/remove them.
---
~Randy
On Tue, Aug 08, 2006 at 02:12:46PM -0700, Randy.Dunlap wrote:
> It's not a gcc (nor ggc) problem. Those functions are just deprecated.
> Current 2.6.18-rc4 and 2.6.18-rc3-mm2 still have those same warnings.
>
> fwiw, I don't seem to have any patches to fix/remove them.
I have saved following patch from Arnd for ages.
First I was worried about the use of weak - but we do that in other
places. And then I just forgot it until now.
Should be easy to adopt to current kernel - but too late for me today.
Sam
From: Arnd Bergmann <[email protected]>
Subject: Re: EXPORT_SYMBOL generates "is deprecated" noise
Date: Mon, 8 Aug 2005 15:46:22 +0200
User-Agent: KMail/1.7.2
Cc: linux-kernel <[email protected]>
Message-Id: <[email protected]>
On Sünndag 07 August 2005 20:26, Martin J. Bligh wrote:
> Oh, I'm being an idiot and looking at the wrong tree. It's __deprecated,
> but I still can't think of a clean way to locally undefine that for
> just EXPORT_SYMBOL.
We could in theory create a new EXPORT_SYMBOL variant that does not
reference the symbol directly. This does a little less compile-time
checks but helps reduce the noise. The big advantage of this
would be that we could once again build kernels with -Werror on
developer machines.
Signed-off-by: Arnd Bergmann <[email protected]>
diff --git a/include/linux/module.h b/include/linux/module.h
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -182,21 +182,26 @@ void *__symbol_get_gpl(const char *symbo
#endif
/* For every exported symbol, place a struct in the __ksymtab section */
-#define __EXPORT_SYMBOL(sym, sec) \
- __CRC_SYMBOL(sym, sec) \
- static const char __kstrtab_##sym[] \
+#define __EXPORT_SYMBOL(name, sym, sec) \
+ __CRC_SYMBOL(name, sec) \
+ static const char __kstrtab_##name[] \
__attribute__((section("__ksymtab_strings"))) \
- = MODULE_SYMBOL_PREFIX #sym; \
- static const struct kernel_symbol __ksymtab_##sym \
+ = MODULE_SYMBOL_PREFIX #name; \
+ static const struct kernel_symbol __ksymtab_##name \
__attribute_used__ \
__attribute__((section("__ksymtab" sec), unused)) \
- = { (unsigned long)&sym, __kstrtab_##sym }
+ = { (unsigned long)&sym, __kstrtab_##name }
#define EXPORT_SYMBOL(sym) \
- __EXPORT_SYMBOL(sym, "")
+ __EXPORT_SYMBOL(sym, sym, "")
#define EXPORT_SYMBOL_GPL(sym) \
- __EXPORT_SYMBOL(sym, "_gpl")
+ __EXPORT_SYMBOL(sym, sym, "_gpl")
+
+#define EXPORT_DEPRECATED_SYMBOL(sym) \
+ extern void __deprecated_ ## sym \
+ __attribute__((alias(#sym))); \
+ __EXPORT_SYMBOL(sym, __deprecated_ ## sym, "_gpl")
#endif
On Tue, Aug 08, 2006 at 02:12:46PM -0700, Randy.Dunlap wrote:
> On Tue, 8 Aug 2006 21:48:11 +0100 Nick Warne wrote:
>
> > Hi all,
> >
> > I have had these warnings for ages:
> >
> > kernel/power/pm.c:241: warning: `pm_register' is deprecated (declared at
> > kernel/power/pm.c:64)
> > kernel/power/pm.c:241: warning: `pm_register' is deprecated (declared at
> > kernel/power/pm.c:64)
> > kernel/power/pm.c:242: warning: `pm_unregister_all' is deprecated (declared at
> > kernel/power/pm.c:97)
> > kernel/power/pm.c:242: warning: `pm_unregister_all' is deprecated (declared at
> > kernel/power/pm.c:97)
> > kernel/power/pm.c:243: warning: `pm_send_all' is deprecated (declared at
> > kernel/power/pm.c:216)
> > kernel/power/pm.c:243: warning: `pm_send_all' is deprecated (declared at
> > kernel/power/pm.c:216)
> >
> > and I think at one time there was a fix about that I applied, but it seems it
> > never made it into kernel.org.
> >
> > Or is this my ggc problem?
>
> It's not a gcc (nor ggc) problem. Those functions are just deprecated.
> Current 2.6.18-rc4 and 2.6.18-rc3-mm2 still have those same warnings.
>
> fwiw, I don't seem to have any patches to fix/remove them.
pm_unregister_all is removed in the -mm tree, from a patch in my tree.
thanks,
greg k-h
On Wednesday 09 August 2006 00:19, Greg KH wrote:
> > fwiw, I don't seem to have any patches to fix/remove them.
>
> pm_unregister_all is removed in the -mm tree, from a patch in my tree.
>
OK, thanks all. For love nor money could I find the mail/patch somebody sent
me ages ago for this... but anyway, it's been sorted now.
Nick
--
Every program has two purposes:
one for which it was written and another for which it wasn't.