From: Jeff Garzik <jgarzik@mandrakesoft.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: torvalds@transmeta.com, dhinds@valinux.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] pcmcia event thread. (fwd)
Date: Mon, 13 Nov 2000 10:33:47 -0500 [thread overview]
Message-ID: <3A1009DB.CC98CE06@mandrakesoft.com> (raw)
In-Reply-To: <3A10031B.79D8A9B5@mandrakesoft.com> <3A0FF138.A510B45@mandrakesoft.com> <7572.974120930@redhat.com> <20554.974126251@redhat.com> <26373.974128444@redhat.com>
David Woodhouse wrote:
> jgarzik@mandrakesoft.com said:
> > In any case, we -really- need a wait_for_kernel_thread_to_die()
> > function.
>
> up_and_exit() would do it. Or preferably passing the address of the
> semaphore as an extra argument to kernel_thread() in the first place.
Any solution which involves a function being called from a kernel
thread, and/or passing another arg to a kernel thread, is a non-starter
... See the discussion about timer_exit() a while ago. This sort of
thing should be done at a higher level. Not only does that eliminate
any possibility of a race between thread function calling
MOD_DEC_USE_COUNT/up_and_exit and module unload, but it also allows us
to more easily implement wait_for_kernel_thread_to_die() without having
to do silly stuff like pass extra args to threads (...modifying the
thread API in the process).
IMHO it is possible to solve this in a generic way without having to
change the code for every single kernel thread.
Thanks for all the explanation, I think I now understand all the stuff
your kernel thread is doing. Your solution sounds like a decent
solution for the problem described. I have not looked at the socket
driver code observe parse_events() usage, so I cannot say whether your
problem description is accurate however :)
Jeff
--
Jeff Garzik |
Building 1024 | The chief enemy of creativity is "good" sense
MandrakeSoft | -- Picasso
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2000-11-13 15:34 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-11-13 13:08 [PATCH] pcmcia event thread. (fwd) David Woodhouse
2000-11-13 13:48 ` Jeff Garzik
2000-11-16 13:28 ` Alan Cox
2000-11-13 14:37 ` David Woodhouse
2000-11-13 15:04 ` Jeff Garzik
2000-11-13 15:14 ` David Woodhouse
2000-11-13 15:33 ` Jeff Garzik [this message]
2000-11-16 13:39 ` Alan Cox
2000-11-16 14:14 ` David Woodhouse
2000-11-16 16:28 ` Tobias Ringstrom
2000-11-18 11:24 ` Pavel Machek
2000-11-13 15:42 ` David Woodhouse
2000-11-13 18:59 ` David Hinds
2000-11-13 21:52 ` David Woodhouse
2000-11-13 21:57 ` David Hinds
2000-11-13 22:30 ` David Woodhouse
2000-11-13 22:47 ` Jeff Garzik
2000-01-01 2:54 ` Pavel Machek
2000-11-16 21:26 ` tytso
2000-11-16 21:42 ` David Hinds
2000-11-13 23:04 ` David Woodhouse
2000-11-16 16:08 ` Alan Cox
2000-11-16 16:15 ` Jeff Garzik
2000-11-16 16:20 ` Alan Cox
2000-11-17 0:51 ` Russell King
2000-11-17 10:54 ` Alan Cox
2000-11-17 16:21 ` Linus Torvalds
2000-11-17 16:29 ` Alan Cox
2000-11-17 16:35 ` Linus Torvalds
2000-11-17 16:39 ` Alan Cox
2000-11-17 16:34 ` Russell King
2000-11-17 16:17 ` Linus Torvalds
2000-11-17 16:34 ` David Woodhouse
2000-11-17 16:40 ` Jeff Garzik
2000-11-17 16:47 ` Linus Torvalds
2000-11-17 16:49 ` David Woodhouse
2000-11-17 20:01 ` David Hinds
2000-11-17 16:43 ` David Woodhouse
2000-11-17 20:30 ` 2.4's internal PCMCIA works for me (was Re: [PATCH] pcmcia event thread) Barry K. Nathan
2000-11-17 21:07 ` David Hinds
2000-11-18 9:55 ` [PATCH] pcmcia event thread. (fwd) David Ford
2000-11-18 16:03 ` Linus Torvalds
2000-11-18 22:16 ` David Hinds
2000-11-19 5:32 ` David Ford
2000-11-19 5:36 ` Linus Torvalds
2000-11-19 6:30 ` [FIXED!] " David Ford
2000-11-19 7:03 ` neighbour table? Andrew Park
2000-11-19 6:57 ` David Ford
2000-11-19 7:45 ` Eric W. Biederman
2000-11-19 10:40 ` David Ford
2000-11-16 13:40 ` [PATCH] pcmcia event thread. (fwd) Alan Cox
2000-11-15 0:01 ` Russell King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3A1009DB.CC98CE06@mandrakesoft.com \
--to=jgarzik@mandrakesoft.com \
--cc=dhinds@valinux.com \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox