SCHED_YIELD undeclared with Trond's NFS patch w/2.4.19-pre2-ac2

SCHED_YIELD undeclared with Trond's NFS patch w/2.4.19-pre2-ac2

Post by Steven A. DuChen » Fri, 08 Mar 2002 22:50:13



I am attempting to apply Trond's linux-2.4.18-NFS_ALL.dif patch to 2.4.19-pre2-ac2
I get the patch to apply once I massage fs/nfs/inode.c a little bit but when I try
to compile it I get:

svcsock.c: In function `svc_recv':
svcsock.c:987: `SCHED_YIELD' undeclared (first use in this function)
svcsock.c:987: (Each undeclared identifier is reported only once
svcsock.c:987: for each function it appears in.)
make[3]: *** [svcsock.o] Error 1
make[3]: Leaving directory `/usr/src/linux-2.4.X/net/sunrpc'
make[2]: *** [first_rule] Error 2

Now I know there were some changes because of the O(1) stuff in the ac2 patch but
what is the process for eliminating references to SCHED_YIELD?
--


        http://www.mindspring.com/~sduchene/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

SCHED_YIELD undeclared with Trond's NFS patch w/2.4.19-pre2-ac2

Post by Morten Helgese » Fri, 08 Mar 2002 23:00:13


Unless my memory is corrupt, you can just replace the 'let`s set the SCHED_YIELD bit' with 'yield()' ...

== Morten


> I am attempting to apply Trond's linux-2.4.18-NFS_ALL.dif patch to 2.4.19-pre2-ac2
> I get the patch to apply once I massage fs/nfs/inode.c a little bit but when I try
> to compile it I get:

> svcsock.c: In function `svc_recv':
> svcsock.c:987: `SCHED_YIELD' undeclared (first use in this function)
> svcsock.c:987: (Each undeclared identifier is reported only once
> svcsock.c:987: for each function it appears in.)
> make[3]: *** [svcsock.o] Error 1
> make[3]: Leaving directory `/usr/src/linux-2.4.X/net/sunrpc'
> make[2]: *** [first_rule] Error 2

> Now I know there were some changes because of the O(1) stuff in the ac2 patch but
> what is the process for eliminating references to SCHED_YIELD?
> --


>         http://www.mindspring.com/~sduchene/
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

--

"Livet er ikke for nybegynnere" - sitat fra en klok person.

mvh
Morten Helgesen
UNIX System Administrator & C Developer
Nextframe AS

http://www.nextframe.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

SCHED_YIELD undeclared with Trond's NFS patch w/2.4.19-pre2-ac2

Post by Richard B. Johnso » Fri, 08 Mar 2002 23:10:06



> I am attempting to apply Trond's linux-2.4.18-NFS_ALL.dif patch to 2.4.19-pre2-ac2
> I get the patch to apply once I massage fs/nfs/inode.c a little bit but when I try
> to compile it I get:

> svcsock.c: In function `svc_recv':
> svcsock.c:987: `SCHED_YIELD' undeclared (first use in this function)
> svcsock.c:987: (Each undeclared identifier is reported only once
> svcsock.c:987: for each function it appears in.)
> make[3]: *** [svcsock.o] Error 1
> make[3]: Leaving directory `/usr/src/linux-2.4.X/net/sunrpc'
> make[2]: *** [first_rule] Error 2

> Now I know there were some changes because of the O(1) stuff in the ac2 patch but
> what is the process for eliminating references to SCHED_YIELD?
> --



You need to change loops that do something like:

    while(something)
    {
        current->policy |= SCHED_YIELD;
        schedule();
    }

    to:

    while(something)
        sys_sched_yield();

Reference:



> > In 2.5 yield() maps to sys_sched_yield(). You can handle it in the same
> > way in your includes if version <= 2.4.

> It's not exported as well as not defined in a header! It results in
> an undefined symbol in the module.

You can try to ask Marcelo to add a line in include/linux/sched.h and one
in kernel/ksym.c
In this way a compatibility interface can be achieved for code that needs it.

- Davide

Cheers,
* Johnson

Penguin : Linux version 2.4.18 on an i686 machine (799.53 BogoMips).

        Bill Gates? Who?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://www.veryComputer.com/
Please read the FAQ at  http://www.veryComputer.com/

 
 
 

SCHED_YIELD undeclared with Trond's NFS patch w/2.4.19-pre2-ac2

Post by Arjan van de Ve » Fri, 08 Mar 2002 23:30:08


Quote:> You need to change loops that do something like:

>     while(something)
>     {
>         current->policy |= SCHED_YIELD;
>         schedule();
>     }

>     to:

>     while(something)
>         sys_sched_yield();

such loops are a great way to create livelock and other nasties in the
kernel
and should be avoided at all cost (esp if you use preemptable kernels)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
 
 
 

SCHED_YIELD undeclared with Trond's NFS patch w/2.4.19-pre2-ac2

Post by Steven A. DuChen » Fri, 08 Mar 2002 23:30:11



> You need to change loops that do something like:

>     while(something)
>     {
>         current->policy |= SCHED_YIELD;
>         schedule();
>     }

>     to:

>     while(something)
>         sys_sched_yield();

Thanks Richard! that did the trick
--


        http://www.mindspring.com/~sduchene/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

SCHED_YIELD undeclared with Trond's NFS patch w/2.4.19-pre2-ac2

Post by Richard B. Johnso » Sat, 09 Mar 2002 00:10:05



Quote:

> > You need to change loops that do something like:

> >     while(something)
> >     {
> >         current->policy |= SCHED_YIELD;
> >         schedule();
> >     }

> >     to:

> >     while(something)
> >         sys_sched_yield();

> such loops are a great way to create livelock and other nasties in the
> kernel
> and should be avoided at all cost (esp if you use preemptable kernels)
> -

Hardly.  The "something" is a bit in some hardware port that is
guaranteed to come true sometime. The driver should not spin on
the port, wasting valuable CPU cycles.

That said, if the kernel wants to control everything about how
it uses otherwise wasted CPU cycles, then we need a kernel
procedure that will execute a user-defined procedure, sort
of like wait_for_timeout(), but not waiting for a semaphore
because there are no CPU cycles available to change the semaphore.
Instead, the procedure takes a pointer to a procedure to be
executed. The procedure returns TRUE or FALSE. When true, the
wait_for_procedure() returns, when FALSE, it will be executed
again (or timeout). The actual procedure should be defined as
something that takes a (void *) to user's parameters and returns
an int. This makes it universal.

Also, it is well understood that these 'wait_for' thingies are
NOT executed in interrupt context.

Cheers,
* Johnson

Penguin : Linux version 2.4.18 on an i686 machine (799.53 BogoMips).

        Bill Gates? Who?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://www.veryComputer.com/
Please read the FAQ at  http://www.veryComputer.com/