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

[Steven A. DuChene]

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?
-- 
Steven A. DuChene      linux-clusters@mindspring.com
                      sduchene@mindspring.com

        http://www.mindspring.com/~sduchene/

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

[Morten Helgesen]

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

== Morten

On Thu, Mar 07, 2002 at 08:45:14AM -0500, Steven A. DuChene wrote:
> 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?
> -- 
> Steven A. DuChene      linux-clusters@mindspring.com
>                       sduchene@mindspring.com
> 
>         http://www.mindspring.com/~sduchene/
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> 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
admin@nextframe.net / 93445641
http://www.nextframe.net

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

[Richard B. Johnson]

On Thu, 7 Mar 2002, Steven A. DuChene wrote:

> 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?
> -- 
> Steven A. DuChene      linux-clusters@mindspring.com
>                       sduchene@mindspring.com

You need to change loops that do something like:

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

    while(something)
        sys_sched_yield();


Reference:

On Tue, 26 Feb 2002, Richard B. Johnson wrote:

> On Tue, 26 Feb 2002, Davide Libenzi wrote:
> >
> > 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,
Dick Johnson

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

	Bill Gates? Who?

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

[Arjan van de Ven]

 
> 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)

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

[Steven A. DuChene]

On Thu, Mar 07, 2002 at 09:00:59AM -0500, Richard B. Johnson wrote:
> 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
-- 
Steven A. DuChene      linux-clusters@mindspring.com
                      sduchene@mindspring.com

        http://www.mindspring.com/~sduchene/

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

[Richard B. Johnson]

On Thu, 7 Mar 2002, Arjan van de Ven wrote:

>  
> > 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,
Dick Johnson

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

	Bill Gates? Who?