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 pa
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
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 t
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 abo
> 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 t
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 t
> 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
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
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 infr
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
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 cou
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 i
> 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
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 daem
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 h
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
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 PROTECT
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 <[EM
19 matches
Mail list logo
