Re: C issues with spinlocks and preemption

From: George Anzinger (george@pioneer.net)
Date: Tue Jul 18 2000 - 21:06:23 EST


Tom Leete wrote:
>
> 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
> >
>
> This is the same situation that has broken 3DNow!+SMP all
> through the -testx series.
>
> I fix that here by moving the offending inline functions
> into mmx.c, and declaring them 'extern inline' in mmx.h.
> That cleans up asm/string.h pretty well.
>
> A header cleanup would be better.
>
I agree, but, under what rules? Are there any? I might even find some
time to help if I know the rules.

On the above problem, because of circular includes and the don't include
twice location, i.e. the whole file, not just the body (which circular
includes require) we often get the body of the file we are trying to
include below the actual body of the including file.

I also had a problem with the kgdb.h moving from 2.2.x to 2.4.x. Seems
one of the include files started using typedefs for ints, you know, like
u32, etc. This is fine my me, but PLEASE include the defining file(s).
It should not be up to the user (even if he is a kernel jock) to sort
these things out!

George

> Tom

-
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:12 EST