From: Geert Uytterhoeven <[email protected]>
For some m68k configs, I get:
| net/rfkill/rfkill-input.c: In function 'rfkill_start':
| net/rfkill/rfkill-input.c:208: error: dereferencing pointer to incomplete type
As the incomplete type is `struct task_struct', including <linux/sched.h> fixes
it.
Signed-off-by: Geert Uytterhoeven <[email protected]>
---
net/rfkill/rfkill-input.c | 1 +
1 file changed, 1 insertion(+)
--- a/net/rfkill/rfkill-input.c
+++ b/net/rfkill/rfkill-input.c
@@ -16,6 +16,7 @@
#include <linux/workqueue.h>
#include <linux/init.h>
#include <linux/rfkill.h>
+#include <linux/sched.h>
#include "rfkill-input.h"
--
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Mon, 13 Oct 2008, Geert Uytterhoeven wrote:
> From: Geert Uytterhoeven <[email protected]>
>
> For some m68k configs, I get:
>
> | net/rfkill/rfkill-input.c: In function 'rfkill_start':
> | net/rfkill/rfkill-input.c:208: error: dereferencing pointer to incomplete type
>
> As the incomplete type is `struct task_struct', including <linux/sched.h> fixes
> it.
Line 208 is this (in latest Linus mainline and also v2.6.27):
spin_unlock_irq(&handle->dev->event_lock);
So we need to include sched.h to everything that uses spin_unlock_irq? If
only some variants of m68k need that, shouldn't it have been added on the
header that defines spin_unlock_irq() on those arches, instead?
Or am I looking at a different version of rfkill-input.c than what you based
that error message on?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
On Mon, 13 Oct 2008, Henrique de Moraes Holschuh wrote:
> On Mon, 13 Oct 2008, Geert Uytterhoeven wrote:
> > | net/rfkill/rfkill-input.c: In function 'rfkill_start':
> > | net/rfkill/rfkill-input.c:208: error: dereferencing pointer to incomplete type
> >
> > As the incomplete type is `struct task_struct', including <linux/sched.h> fixes
> > it.
>
> Line 208 is this (in latest Linus mainline and also v2.6.27):
>
> spin_unlock_irq(&handle->dev->event_lock);
>
> So we need to include sched.h to everything that uses spin_unlock_irq? If
Never mind, I didn't check if the problem is with the argument to
spin_unlock_irq(), but the question remains...
> only some variants of m68k need that, shouldn't it have been added on the
> header that defines spin_unlock_irq() on those arches, instead?
>
> Or am I looking at a different version of rfkill-input.c than what you based
> that error message on?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
On Mon, 13 Oct 2008, Henrique de Moraes Holschuh wrote:
> On Mon, 13 Oct 2008, Geert Uytterhoeven wrote:
> > From: Geert Uytterhoeven <[email protected]>
> >
> > For some m68k configs, I get:
> >
> > | net/rfkill/rfkill-input.c: In function 'rfkill_start':
> > | net/rfkill/rfkill-input.c:208: error: dereferencing pointer to incomplete type
> >
> > As the incomplete type is `struct task_struct', including <linux/sched.h> fixes
> > it.
>
> Line 208 is this (in latest Linus mainline and also v2.6.27):
>
> spin_unlock_irq(&handle->dev->event_lock);
>
> So we need to include sched.h to everything that uses spin_unlock_irq? If
> only some variants of m68k need that, shouldn't it have been added on the
> header that defines spin_unlock_irq() on those arches, instead?
Unfortunately that's not possible, due to Include Hell(tm).
Therefore, including <linux/sched.h> is the way this has been fixed in
the past.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Tue, 14 Oct 2008, Geert Uytterhoeven wrote:
> Unfortunately that's not possible, due to Include Hell(tm).
> Therefore, including <linux/sched.h> is the way this has been fixed in
> the past.
I see. Well, when doing this I'd suggest adding a comment, otherwise the
include could end up getting removed sooner or later without anyone asking
linux-m68k first (I seriously douby anyone will do git blame to find out why
an #include line exists before removing it).
Something like:
#include <sched.h> /* m68k needs task_struct for <whatever> */
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
On Wed, 15 Oct 2008, Henrique de Moraes Holschuh wrote:
> On Tue, 14 Oct 2008, Geert Uytterhoeven wrote:
> > Unfortunately that's not possible, due to Include Hell(tm).
> > Therefore, including <linux/sched.h> is the way this has been fixed in
> > the past.
>
> I see. Well, when doing this I'd suggest adding a comment, otherwise the
> include could end up getting removed sooner or later without anyone asking
> linux-m68k first (I seriously douby anyone will do git blame to find out why
> an #include line exists before removing it).
>
> Something like:
> #include <sched.h> /* m68k needs task_struct for <whatever> */
Probably we should start looking again into extracting struct
task_struct into its own header file, cfr. what Roman Zippel did a long
time ago...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Wed, Oct 15, 2008 at 12:10:18AM -0300, Henrique de Moraes Holschuh wrote:
> On Tue, 14 Oct 2008, Geert Uytterhoeven wrote:
> > Unfortunately that's not possible, due to Include Hell(tm).
> > Therefore, including <linux/sched.h> is the way this has been fixed in
> > the past.
>
> I see. Well, when doing this I'd suggest adding a comment, otherwise the
> include could end up getting removed sooner or later without anyone asking
> linux-m68k first (I seriously douby anyone will do git blame to find out why
> an #include line exists before removing it).
>
> Something like:
> #include <sched.h> /* m68k needs task_struct for <whatever> */
Such comments in the kernel tend to be old ones you cannot trust.
And #include removals are not really a common case - sometimes someone
cleans up something specific, but I don't think anyone will remove
#include's of sched.h from random .c files (considering how much
sched.h pulls in the fallout of such #include removals would be many
build breakages) unless someone seriously reorganizes sched.h itself.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed