Trond Myklebust <[EMAIL PROTECTED]> writes:
> On Thu, 2007-04-19 at 14:40 -0700, Andrew Morton wrote:
>> Using signals to communicate with kernel threads is fairly unpleasant, IMO.
>> We have much simpler, faster and more idiomatic ways of communicating
>> between threads in-kernel and there are
Dave Hansen <[EMAIL PROTECTED]> writes:
> On Thu, 2007-04-19 at 17:19 -0400, Trond Myklebust wrote:
>> > With pid namespaces all kernel threads will disappear so how do
>> > we cope with the problem when the sysadmin can not see the kernel
>> > threads?
>
> Do they actually always disappear, or
Dave Hansen [EMAIL PROTECTED] writes:
On Thu, 2007-04-19 at 17:19 -0400, Trond Myklebust wrote:
With pid namespaces all kernel threads will disappear so how do
we cope with the problem when the sysadmin can not see the kernel
threads?
Do they actually always disappear, or do we keep them
Trond Myklebust [EMAIL PROTECTED] writes:
On Thu, 2007-04-19 at 14:40 -0700, Andrew Morton wrote:
Using signals to communicate with kernel threads is fairly unpleasant, IMO.
We have much simpler, faster and more idiomatic ways of communicating
between threads in-kernel and there are better
On Thu, 2007-04-19 at 14:40 -0700, Andrew Morton wrote:
> Using signals to communicate with kernel threads is fairly unpleasant, IMO.
> We have much simpler, faster and more idiomatic ways of communicating
> between threads in-kernel and there are better ways in which userspace can
> communicate
On Thu, 19 Apr 2007 17:19:24 -0400
Trond Myklebust <[EMAIL PROTECTED]> wrote:
> > Regardless kernel threads should be an implementation detail
> > not a part of the user interface. If kernel threads are part
> > of the user interface it makes them very hard to change.
> >
> > So it isn't that
On Thu, 2007-04-19 at 17:19 -0400, Trond Myklebust wrote:
> > With pid namespaces all kernel threads will disappear so how do
> > we cope with the problem when the sysadmin can not see the kernel
> > threads?
Do they actually always disappear, or do we keep them in the
init_pid_namespace?
--
On Thu, 2007-04-19 at 13:20 -0600, Eric W. Biederman wrote:
> Trond Myklebust <[EMAIL PROTECTED]> writes:
>
> > On Thu, 2007-04-19 at 01:58 -0600, Eric W. Biederman wrote:
> >> From: Eric W. Biederman <[EMAIL PROTECTED]>
> >>
> >> Start the reclaimer thread using kthread_run instead
> >> of a
Trond Myklebust <[EMAIL PROTECTED]> writes:
> On Thu, 2007-04-19 at 01:58 -0600, Eric W. Biederman wrote:
>> From: Eric W. Biederman <[EMAIL PROTECTED]>
>>
>> Start the reclaimer thread using kthread_run instead
>> of a combination of kernel_thread and daemonize.
>> The small amount of signal
On Thu, 2007-04-19 at 01:58 -0600, Eric W. Biederman wrote:
> From: Eric W. Biederman <[EMAIL PROTECTED]>
>
> Start the reclaimer thread using kthread_run instead
> of a combination of kernel_thread and daemonize.
> The small amount of signal handling code is also removed
> as it makes no sense
From: Eric W. Biederman <[EMAIL PROTECTED]>
Start the reclaimer thread using kthread_run instead
of a combination of kernel_thread and daemonize.
The small amount of signal handling code is also removed
as it makes no sense and is a maintenance problem to handle
signals in kernel threads.
Cc:
From: Eric W. Biederman <[EMAIL PROTECTED]> - unquoted
Start the reclaimer thread using kthread_run instead
of a combination of kernel_thread and daemonize.
The small amount of signal handling code is also removed
as it makes no sense and is a maintenance problem to handle
signals in kernel
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
Start the reclaimer thread using kthread_run instead
of a combination of kernel_thread and daemonize.
The small amount of signal handling code is also removed
as it makes no sense and is a maintenance problem to handle
signals in kernel
From: Eric W. Biederman [EMAIL PROTECTED]
Start the reclaimer thread using kthread_run instead
of a combination of kernel_thread and daemonize.
The small amount of signal handling code is also removed
as it makes no sense and is a maintenance problem to handle
signals in kernel threads.
Cc: Neil
On Thu, 2007-04-19 at 01:58 -0600, Eric W. Biederman wrote:
From: Eric W. Biederman [EMAIL PROTECTED]
Start the reclaimer thread using kthread_run instead
of a combination of kernel_thread and daemonize.
The small amount of signal handling code is also removed
as it makes no sense and is a
Trond Myklebust [EMAIL PROTECTED] writes:
On Thu, 2007-04-19 at 01:58 -0600, Eric W. Biederman wrote:
From: Eric W. Biederman [EMAIL PROTECTED]
Start the reclaimer thread using kthread_run instead
of a combination of kernel_thread and daemonize.
The small amount of signal handling code is
On Thu, 2007-04-19 at 13:20 -0600, Eric W. Biederman wrote:
Trond Myklebust [EMAIL PROTECTED] writes:
On Thu, 2007-04-19 at 01:58 -0600, Eric W. Biederman wrote:
From: Eric W. Biederman [EMAIL PROTECTED]
Start the reclaimer thread using kthread_run instead
of a combination of
On Thu, 2007-04-19 at 17:19 -0400, Trond Myklebust wrote:
With pid namespaces all kernel threads will disappear so how do
we cope with the problem when the sysadmin can not see the kernel
threads?
Do they actually always disappear, or do we keep them in the
init_pid_namespace?
-- Dave
-
On Thu, 19 Apr 2007 17:19:24 -0400
Trond Myklebust [EMAIL PROTECTED] wrote:
Regardless kernel threads should be an implementation detail
not a part of the user interface. If kernel threads are part
of the user interface it makes them very hard to change.
So it isn't that it doesn't
On Thu, 2007-04-19 at 14:40 -0700, Andrew Morton wrote:
Using signals to communicate with kernel threads is fairly unpleasant, IMO.
We have much simpler, faster and more idiomatic ways of communicating
between threads in-kernel and there are better ways in which userspace can
communicate with
20 matches
Mail list logo
