ludovic fernandez wrote:
>
> Funny, I was doing the same thing....
> I ran into the same problem and give up trying to make the
> preemption functions inline.
> The problem is that the structure task is not defined at the
> point you declare your function. Defining them after the
> declaration of task struct doesn't work either because some
> header files need the spinlock definition very early (chicken and
> eggs problem).
>
I think the problem is a bit bigger than this. This problem in a nut
shell is that cc compiles the inline code when it sees it, not when it
is referenced. This means inline functions should _NOT_ be in header
files _PERIOD_. Of the two possible fixes, I vote for fixing cc, but I
am not holding my breath.
I suppose that this could also be fixed by cleaning up the header files
to remove the circular includes, but again, I am not holding my breath.
I am not trying to write inline code, just trying to modify the spinlock
macros to reference the tast_struct, ooh bad me.
> Note that I'm more or less done making the system preemptable
> (I modified the interrupt path for i386 platform and the locking
> stubs), but I also gave up trying to make it work on 2.4.XXX because
> the SMP locking is not stable yet. Try to compile the kernel in UP with
> the locking in debug mode and you'll see.
>
> Ludo.
>
> George Anzinger wrote:
>
> > In the persuit of trying to use spinlocks macros for UP preemption I
> > have come up with an interesting C problem and the way header files are
> > being coded in the kernel. In particular:
> >
> > #include <linux/sched.h>
> > #include <asm/current.h>
> >
> > static inline int foo(void)
> > {
> > int bar;
> >
> > bar = current->need_resched;
> > return bar;
> > }
> >
> > Works fine as a .c file, but if it is in a header file that is included
> > by sched.h (such as tty.h) or indirectly included by sched.h (such as
> > tqueue.h) cc complains about an incomplete type on the "current"
> > reference.
> >
> > The problem is that sched.h, in such a case, actually has its body
> > included after the above code and thus all cc has is a promise (i.e.
> > struct task_struct;) and not the real task_struct. It appears that cc
> > is compiling the "inline" function when it sees it, not when it is
> > referenced.
> >
> > This is proving to be a tough nut to crack. Any thoughts?
> >
> > George
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.rutgers.edu
> > Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jul 23 2000 - 21:00:11 EST