lkml.org 
[lkml]   [2000]   [Jul]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: C issues with spinlocks and preemption
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:57    [from the cache]
    ©2003-2014 Jasper Spaans. Advertise on this site