On Thu, Apr 19, 2007 at 01:58:45AM -0600, Eric W. Biederman wrote:
> From: Eric W. Biederman <[EMAIL PROTECTED]>
>
> This patch modifies the startup of eehd to use kthread_run
> not a combination of kernel_thread and daemonize. Making
> the code slightly simpler and more maintainable.
For the
On Tue, Apr 24, 2007 at 11:38:53AM +1000, Benjamin Herrenschmidt wrote:
> > The only reason for using threads here is to get the error recovery
> > out of an interrupt context (where errors may be detected), and then,
> > an hour later, decrement a counter (which is how we limit these to
> > 6
On Tue, Apr 24, 2007 at 03:55:06PM +1000, Paul Mackerras wrote:
> Christoph Hellwig writes:
>
> > The first question is obviously, is this really something we want?
> > spawning kernel thread on demand without reaping them properly seems
> > quite dangerous.
>
> What specifically has to be done
On Tue, 24 Apr 2007 15:00:42 +1000,
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> Like anything else, modules should have separated the entrypoints for
>
> - Initiating a removal request
> - Releasing the module
>
> The former is use did "rmmod", can unregister things from subsystems,
>
Christoph Hellwig writes:
> The first question is obviously, is this really something we want?
> spawning kernel thread on demand without reaping them properly seems
> quite dangerous.
What specifically has to be done to reap a kernel thread? Are you
concerned about the number of threads, or
> Since we need to have some way to track them having an explicit data
> structure that the callers manage seems to make sense.
Oh sure, I wasn't arguing against that at all...
It might be handy to have a release() callback (optional) that gets
called after the kthread stops/exits, once we know
Christoph Hellwig writes:
The first question is obviously, is this really something we want?
spawning kernel thread on demand without reaping them properly seems
quite dangerous.
What specifically has to be done to reap a kernel thread? Are you
concerned about the number of threads, or about
On Tue, 24 Apr 2007 15:00:42 +1000,
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
Like anything else, modules should have separated the entrypoints for
- Initiating a removal request
- Releasing the module
The former is use did rmmod, can unregister things from subsystems,
etc...
On Tue, Apr 24, 2007 at 03:55:06PM +1000, Paul Mackerras wrote:
Christoph Hellwig writes:
The first question is obviously, is this really something we want?
spawning kernel thread on demand without reaping them properly seems
quite dangerous.
What specifically has to be done to reap a
On Tue, Apr 24, 2007 at 11:38:53AM +1000, Benjamin Herrenschmidt wrote:
The only reason for using threads here is to get the error recovery
out of an interrupt context (where errors may be detected), and then,
an hour later, decrement a counter (which is how we limit these to
6 per hour).
On Thu, Apr 19, 2007 at 01:58:45AM -0600, Eric W. Biederman wrote:
From: Eric W. Biederman [EMAIL PROTECTED]
This patch modifies the startup of eehd to use kthread_run
not a combination of kernel_thread and daemonize. Making
the code slightly simpler and more maintainable.
For the patch
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
>> Further in general it doesn't make sense to grab a module reference
>> and call that sufficient because we would like to request that the
>> module exits.
>
> Which is, btw, I think a total misdesign of our module stuff, but heh, I
> remember
> Further in general it doesn't make sense to grab a module reference
> and call that sufficient because we would like to request that the
> module exits.
Which is, btw, I think a total misdesign of our module stuff, but heh, I
remember that lead to some flamewars back then...
Like anything
Paul Mackerras <[EMAIL PROTECTED]> writes:
> Eric W. Biederman writes:
>
>> Well the basic problem is that for any piece of code that can be modular
>> we need a way to ensure all threads it has running are shutdown when we
>> remove the module.
>
> The EEH code can't be modular, and wouldn't
Eric W. Biederman writes:
> Well the basic problem is that for any piece of code that can be modular
> we need a way to ensure all threads it has running are shutdown when we
> remove the module.
The EEH code can't be modular, and wouldn't make any sense to be
modular, since it's part of the
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
> Not sure... I can see places where I might want to spawn an arbitrary
> number of these without having to preallocate structures... and if I
> allocate on the fly, then I need a way to free that structure when the
> kthread is reaped which I
On Mon, 2007-04-23 at 20:08 -0600, Eric W. Biederman wrote:
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
>
> >> The only reason for using threads here is to get the error recovery
> >> out of an interrupt context (where errors may be detected), and then,
> >> an hour later, decrement a
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
>> The only reason for using threads here is to get the error recovery
>> out of an interrupt context (where errors may be detected), and then,
>> an hour later, decrement a counter (which is how we limit these to
>> 6 per hour). Thread reaping
> The only reason for using threads here is to get the error recovery
> out of an interrupt context (where errors may be detected), and then,
> an hour later, decrement a counter (which is how we limit these to
> 6 per hour). Thread reaping is "trivial", the thread just exits
> after an hour.
On Sun, Apr 22, 2007 at 01:31:55PM +0100, Christoph Hellwig wrote:
> On Thu, Apr 19, 2007 at 01:58:45AM -0600, Eric W. Biederman wrote:
> > From: Eric W. Biederman <[EMAIL PROTECTED]>
> >
> > This patch modifies the startup of eehd to use kthread_run
> > not a combination of kernel_thread and
On Sun, Apr 22, 2007 at 01:31:55PM +0100, Christoph Hellwig wrote:
On Thu, Apr 19, 2007 at 01:58:45AM -0600, Eric W. Biederman wrote:
From: Eric W. Biederman [EMAIL PROTECTED]
This patch modifies the startup of eehd to use kthread_run
not a combination of kernel_thread and daemonize.
The only reason for using threads here is to get the error recovery
out of an interrupt context (where errors may be detected), and then,
an hour later, decrement a counter (which is how we limit these to
6 per hour). Thread reaping is trivial, the thread just exits
after an hour.
In
Benjamin Herrenschmidt [EMAIL PROTECTED] writes:
The only reason for using threads here is to get the error recovery
out of an interrupt context (where errors may be detected), and then,
an hour later, decrement a counter (which is how we limit these to
6 per hour). Thread reaping is
On Mon, 2007-04-23 at 20:08 -0600, Eric W. Biederman wrote:
Benjamin Herrenschmidt [EMAIL PROTECTED] writes:
The only reason for using threads here is to get the error recovery
out of an interrupt context (where errors may be detected), and then,
an hour later, decrement a counter (which
Benjamin Herrenschmidt [EMAIL PROTECTED] writes:
Not sure... I can see places where I might want to spawn an arbitrary
number of these without having to preallocate structures... and if I
allocate on the fly, then I need a way to free that structure when the
kthread is reaped which I don't
Eric W. Biederman writes:
Well the basic problem is that for any piece of code that can be modular
we need a way to ensure all threads it has running are shutdown when we
remove the module.
The EEH code can't be modular, and wouldn't make any sense to be
modular, since it's part of the
Paul Mackerras [EMAIL PROTECTED] writes:
Eric W. Biederman writes:
Well the basic problem is that for any piece of code that can be modular
we need a way to ensure all threads it has running are shutdown when we
remove the module.
The EEH code can't be modular, and wouldn't make any sense
Further in general it doesn't make sense to grab a module reference
and call that sufficient because we would like to request that the
module exits.
Which is, btw, I think a total misdesign of our module stuff, but heh, I
remember that lead to some flamewars back then...
Like anything else,
Benjamin Herrenschmidt [EMAIL PROTECTED] writes:
Further in general it doesn't make sense to grab a module reference
and call that sufficient because we would like to request that the
module exits.
Which is, btw, I think a total misdesign of our module stuff, but heh, I
remember that lead
On Thu, Apr 19, 2007 at 01:58:45AM -0600, Eric W. Biederman wrote:
> From: Eric W. Biederman <[EMAIL PROTECTED]>
>
> This patch modifies the startup of eehd to use kthread_run
> not a combination of kernel_thread and daemonize. Making
> the code slightly simpler and more maintainable.
This one
On Thu, Apr 19, 2007 at 01:58:45AM -0600, Eric W. Biederman wrote:
From: Eric W. Biederman [EMAIL PROTECTED]
This patch modifies the startup of eehd to use kthread_run
not a combination of kernel_thread and daemonize. Making
the code slightly simpler and more maintainable.
This one has the
On Thu, 19 Apr 2007 01:58:45 -0600
"Eric W. Biederman" <[EMAIL PROTECTED]> wrote:
> This patch modifies the startup of eehd to use kthread_run
> not a combination of kernel_thread and daemonize. Making
> the code slightly simpler and more maintainable.
>
You're making me look at a lot of
From: Eric W. Biederman <[EMAIL PROTECTED]>
This patch modifies the startup of eehd to use kthread_run
not a combination of kernel_thread and daemonize. Making
the code slightly simpler and more maintainable.
Cc: Paul Mackerras <[EMAIL PROTECTED]>
Signed-off-by: Eric W. Biederman <[EMAIL
From: Eric W. Biederman <[EMAIL PROTECTED]> - unquoted
This patch modifies the startup of eehd to use kthread_run
not a combination of kernel_thread and daemonize. Making
the code slightly simpler and more maintainable.
Cc: Paul Mackerras <[EMAIL PROTECTED]>
Signed-off-by: Eric W. Biederman
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
This patch modifies the startup of eehd to use kthread_run
not a combination of kernel_thread and daemonize. Making
the code slightly simpler and more maintainable.
Cc: Paul Mackerras [EMAIL PROTECTED]
Signed-off-by: Eric W. Biederman [EMAIL
From: Eric W. Biederman [EMAIL PROTECTED]
This patch modifies the startup of eehd to use kthread_run
not a combination of kernel_thread and daemonize. Making
the code slightly simpler and more maintainable.
Cc: Paul Mackerras [EMAIL PROTECTED]
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
On Thu, 19 Apr 2007 01:58:45 -0600
Eric W. Biederman [EMAIL PROTECTED] wrote:
This patch modifies the startup of eehd to use kthread_run
not a combination of kernel_thread and daemonize. Making
the code slightly simpler and more maintainable.
You're making me look at a lot of things which
37 matches
Mail list logo
