On Fri, 2008-04-04 at 20:30 -0400, Oren Laadan wrote:
>
> Matt Helsley wrote:
> > I don't have an upper limit on how many more states we will need and I
> > think that number impacts the interface significantly. Can you give us
> > an estimate?
>
> In Zap there are (using the current term
Matt Helsley wrote:
> On Fri, 2008-04-04 at 11:56 -0400, Oren Laadan wrote:
>> Matt Helsley wrote:
>>> On Thu, 2008-04-03 at 16:49 -0700, Paul Menage wrote:
On Thu, Apr 3, 2008 at 2:03 PM, <[EMAIL PROTECTED]> wrote:
>* "freezer.kill"
>
> writing will send signal number
On Fri, 2008-04-04 at 11:56 -0400, Oren Laadan wrote:
>
> Matt Helsley wrote:
> > On Thu, 2008-04-03 at 16:49 -0700, Paul Menage wrote:
> >> On Thu, Apr 3, 2008 at 2:03 PM, <[EMAIL PROTECTED]> wrote:
> >>>* "freezer.kill"
> >>>
> >>> writing will send signal number to all tasks
> >>>
Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
> Serge E. Hallyn [EMAIL PROTECTED] wrote:
> | > +
> | > + /*
> | > + * What pts-ns do we want to use when opening "/dev/tty" ?
> | > + * Sounds like current_pts_ns(), but what should happen
> | > + * if parent pts ns does:
> | > + *
> | > + *
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Fri, 04 Apr 2008 11:45:58 +0200
> Pavel Emelyanov wrote:
> > These entries are allocated in vlan_dev_set_egress_priority,
> > but are never released and leaks on vlan device removal.
> >
> > Drop these in vlan's ->uninit callback - after the device
Serge E. Hallyn [EMAIL PROTECTED] wrote:
| > +
| > + /*
| > +* What pts-ns do we want to use when opening "/dev/tty" ?
| > +* Sounds like current_pts_ns(), but what should happen
| > +* if parent pts ns does:
| > +*
| > +* echo foo > /vs/vs1/dev/tty
|
| You'll want to re
Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
>
> From: Sukadev Bhattiprolu <[EMAIL PROTECTED]>
> Subject: [PATCH 6/7][v2]: Determine pts_ns from a pty's inode.
>
> The devpts interfaces currently operate on a specific pts namespace
> which they get from the 'current' task.
>
> With implementat
Matt Helsley wrote:
> On Thu, 2008-04-03 at 16:49 -0700, Paul Menage wrote:
>> On Thu, Apr 3, 2008 at 2:03 PM, <[EMAIL PROTECTED]> wrote:
>>>* "freezer.kill"
>>>
>>> writing will send signal number to all tasks
>>>
>> My first thought (not having looked at the code yet) is that sendin
[PATCH 02/04]
This patch proposes the procfs facilities needed to feed the id(s) for the
next task to be forked.
say n is the number of pids to be provided through procfs:
if an
echo "LONG X0 X1 ... X" > /proc/self/next_pids
is issued, the next task to be forked will have its upid nrs set as fol
[PATCH 04/04]
This patch makes use of the target ids specified by a previous write to
/proc/self/next_id as the ids to use to allocate the next upid nrs.
Upper levels upid nrs that are not specified in next_pids file are left to the
kernel choice.
Signed-off-by: Nadia Derbey <[EMAIL PROTECTED]>
[PATCH 03/04]
This patch makes use of the target id specified by a previous write into
/proc/self/next_id as the id to use to allocate the next IPC object.
Signed-off-by: Nadia Derbey <[EMAIL PROTECTED]>
---
include/linux/sysids.h |7 +++
ipc/util.c | 40 ++
Hi,
When restarting a process that has been previously checkpointed, that process
should keep on using some of its ids (such as its process id, or sysV ipc ids).
This patch provides a feature that can help ensuring this saved state reuse:
it makes it possible to create an object with a pre-defi
[PATCH 01/04]
This patch proposes the procfs facilities needed to feed the id for the
next object to be allocated.
if an
echo "LONG XX" > /proc/self/next_id
is issued, next object to be created will have XX as its id.
This applies to objects that need a single id, such as ipc objects.
Signed-of
Quoting Paul Menage ([EMAIL PROTECTED]):
> On Thu, Apr 3, 2008 at 2:03 PM, <[EMAIL PROTECTED]> wrote:
> >
> >* "freezer.kill"
> >
> > writing will send signal number to all tasks
> >
>
> My first thought (not having looked at the code yet) is that sending a
> signal doesn't really have
Hi,
>
> On Thu, Apr 3, 2008 at 11:20 PM, Satoshi UCHIDA <[EMAIL PROTECTED]>
> wrote:
> >
> > So that you say, root subsystem state maybe keep a reference locally.
> > For example, create a variable for root subsystem state and
> > store the pointer when making subsystem state first.
>
> Yes,
Pavel Emelyanov wrote:
These entries are allocated in vlan_dev_set_egress_priority,
but are never released and leaks on vlan device removal.
Drop these in vlan's ->uninit callback - after the device is
brought down and everyone is notified about it is going to
be unregistered.
Found during t
These entries are allocated in vlan_dev_set_egress_priority,
but are never released and leaks on vlan device removal.
Drop these in vlan's ->uninit callback - after the device is
brought down and everyone is notified about it is going to
be unregistered.
Found during testing vlan netnsization p
On Thu, Apr 3, 2008 at 11:20 PM, Satoshi UCHIDA <[EMAIL PROTECTED]> wrote:
>
> So that you say, root subsystem state maybe keep a reference locally.
> For example, create a variable for root subsystem state and
> store the pointer when making subsystem state first.
Yes, that's what I'm suggesti
18 matches
Mail list logo
