Interestingly enough, just yesterday I wanted to use wake_up_process and
found that it is not an exported symbol... Is there a reason for this? I
would like to use it in my module, and was wondering what the easiest way
of doing it was...
ben
George Anzinger <george@pioneer.net>@vger.rutgers.edu on 06/20/2000
04:42:24 PM
Sent by: owner-linux-kernel@vger.rutgers.edu
To: David Hinds <dhinds@valinux.com>
cc: David Woodhouse <dwmw2@infradead.org>, jmerkey@timpanogas.com,
linux-kernel@vger.rutgers.edu
Subject: Re: More PCI races...
David Hinds wrote:
>
> On Mon, Jun 19, 2000 at 02:56:04PM -0700, George Anzinger wrote:
> >
> > For this discussion, we could explore the problems with such a thread,
> > etc. In the timer case above, for example, we would want to impose all
> > the same restrictions as the bottom half code runs under, because it
> > needs to service all the timers. On the other hand, a thread that only
> > handled bottom half issues for one interface, might be able to relax
> > these restrictions. The key, I think, is knowing why the restrictions
> > are in place.
>
> For the situation I had in mind, I wanted an interrupt handler to be
> able to schedule something to run in thread context, without having a
> dedicated thread hanging around for that. I needed to do this to get
> around the interrupt context restrictions, and do things that might
> sleep. I wanted to do this for handling "hot eject" events for hot
> plug drivers, where the eject could be delivered to the driver in
> interrupt context, so the driver could schedule more complicated
> teardown code to run later. In this case, I don't care when the stuff
> gets scheduled as long as it is "soon".
>
> I saw that Jeff Merkey proposed something fairly similar about a month
> ago, in the context of improving network and filesystem performance,
> in the form of WorkToDo items that would be kept in a run queue and
> handed out to worker threads by the scheduler.
>
> For my purposes, I wouldn't need the filesystem hooks that Jeff talks
> about; all I need are the basic scheduling features.
Wish I could say I have been there, but, oh well, I will give my $0.02
worth anyway. I think all the bits and flops are already in place to do
this in the kernel. You will most likely have to have a kernel thread,
however. This is just the table and stack space, really. You start it
the same way init is started (see main.c). The thread would start a bit
of code that would call schedule() after setting:
p->state=TASK_UNINTERRUPTIBLE;
or
p->state=TASK_INTERRUPTIBLE;
You choose one of these based on if you want the task to be killable,
i.e. to handle signals.
The task will sleep until you call wake_up_process(p); where p here and
above is the task_struct address.
wake_up_process() can be called from your interrupt code with no
problems.
At this point, the system will sometime "soon" give control to the task
and it will "return" from the schedule() call. It would then do its
work and if more is to be done, go back to the above setting of p->state
etc.
As part of your set up you might want to adjust various things such at
the tasks priority, rtpriority etc. (This is best done via the provided
interfaces in sched.c as this way you are using a documented interface
and don't need to know if the actual entry in the task_struct changes
name etc.) You would do these things to give the task the required
priority and privileges. One neat way to do this is to make sure the
task that forks the kernel thread has what is needed. Then the fork
will just copy it over.
I have not looked into how to eliminate the task, but I would imagine
that the system exit call would be a good place to look.
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/
This archive was generated by hypermail 2b29 : Fri Jun 23 2000 - 21:00:21 EST