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 [email protected]
[email protected]
http://www.mindspring.com/~sduchene/
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 [email protected]
> [email protected]
>
> http://www.mindspring.com/~sduchene/
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> 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
[email protected] / 93445641
http://www.nextframe.net
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 [email protected]
> [email protected]
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?
> 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)
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 [email protected]
[email protected]
http://www.mindspring.com/~sduchene/
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?