breed@almaden.ibm.com wrote:
>
> 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...
Well I said I had not been there. Here is an additional $0.02 worth.
After thinking on my reply of yesterday (see below) I think one should
use one of the exported interfaces. These include wait_event() and its
companion wake_up(). Used properly these functions take care of the
case where the event to be waited for has already occured. There is
also a semaphore interface that is exported. I am sure somebody has
written a nice short how_to on these, if only I/you/we could find it.
(If not, maybe I will do one.) In any case the principle is simple, the
code short and the total overhead to do the tasks we are discussing is
the task structure and stack.
George
>
> 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/
-
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:22 EST