On Wed, 2007-06-20 at 18:22 +0200, Cedric Le Goater wrote:
> 
> I would be in favor of adding a new c/r signal like other operating systems 
> have done today and in the past. This is something to discuss. 

There was some talk of doing a new signal for CPU hotplug.  But, that
was shot down because it really requires library changes to work right.
But, would this signal be completely kernel handled?  What good is
having a signal if userspace *isn't* going to handle it ever?

-- Dave

_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers

Dave Hansen wrote:
> On Wed, 2007-06-20 at 18:22 +0200, Cedric Le Goater wrote:
>> I would be in favor of adding a new c/r signal like other operating systems 
>> have done today and in the past. This is something to discuss. 
> 
> There was some talk of doing a new signal for CPU hotplug.  But, that
> was shot down because it really requires library changes to work right.
> But, would this signal be completely kernel handled?  What good is 
> having a signal if userspace *isn't* going to handle it ever?

There are 2 reasons for such a signal. 

The first is to be able to freeze a group of tasks before checkpointing 
it. the swsusp freezer does that already, with a stealth signal by 
faking it. 

The second is to be able to run some code in the context of the current 
task. There's plenty of simple ways to get/set process and kernel states 
through syscalls. Why not use them ? Of course, we cannot do everything 
in user and, whenever needed ,we would use a kernel helper. memory is
one requiring a big helper (swap).

It would also require to have a user space handler in some lib. 

I'd like to address that topic at the C/R bof.

Thanks,

C.
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers