Serge E. Hallyn wrote:
>
> But note that in either case we need to deal with a bunch of locking.
> So getting back to Pierre's patchset, IIRC 1-8 are cleanups worth
> doing no matter 1. 9-11 sound like they are contentuous until
> we decide whether we want to go with a create_with_id() type
Serge E. Hallyn wrote:
But note that in either case we need to deal with a bunch of locking.
So getting back to Pierre's patchset, IIRC 1-8 are cleanups worth
doing no matter 1. 9-11 sound like they are contentuous until
we decide whether we want to go with a create_with_id() type
Quoting Oren Laadan ([EMAIL PROTECTED]):
>
>
> Serge E. Hallyn wrote:
>> Quoting Oren Laadan ([EMAIL PROTECTED]):
>>> I strongly second Kirill on this matter.
>>>
>>> IMHO, we should _avoid_ as much as possible exposing internal kernel
>>> state to applications, unless a _real_ need for it is
Serge E. Hallyn wrote:
Quoting Oren Laadan ([EMAIL PROTECTED]):
I strongly second Kirill on this matter.
IMHO, we should _avoid_ as much as possible exposing internal kernel
state to applications, unless a _real_ need for it is _clearly_
demonstrated. The reasons for this are quite obvious.
Quoting Oren Laadan ([EMAIL PROTECTED]):
>
> I strongly second Kirill on this matter.
>
> IMHO, we should _avoid_ as much as possible exposing internal kernel
> state to applications, unless a _real_ need for it is _clearly_
> demonstrated. The reasons for this are quite obvious.
Hmm, sure, but
On Tue, 2008-02-05 at 04:51 -0500, Oren Laadan wrote:
> That said, I suggest the following method instead (this is the method
> we use in Zap to determine the desired resource identifier when a new
> resource is allocated; I recall that we had discussed it in the past,
> perhaps the mini-summit in
I strongly second Kirill on this matter.
IMHO, we should _avoid_ as much as possible exposing internal kernel
state to applications, unless a _real_ need for it is _clearly_
demonstrated. The reasons for this are quite obvious.
It isn't strictly necessary to export a new interface in order to
I strongly second Kirill on this matter.
IMHO, we should _avoid_ as much as possible exposing internal kernel
state to applications, unless a _real_ need for it is _clearly_
demonstrated. The reasons for this are quite obvious.
It isn't strictly necessary to export a new interface in order to
On Tue, 2008-02-05 at 04:51 -0500, Oren Laadan wrote:
That said, I suggest the following method instead (this is the method
we use in Zap to determine the desired resource identifier when a new
resource is allocated; I recall that we had discussed it in the past,
perhaps the mini-summit in
Quoting Oren Laadan ([EMAIL PROTECTED]):
I strongly second Kirill on this matter.
IMHO, we should _avoid_ as much as possible exposing internal kernel
state to applications, unless a _real_ need for it is _clearly_
demonstrated. The reasons for this are quite obvious.
Hmm, sure, but this
Serge E. Hallyn wrote:
Quoting Oren Laadan ([EMAIL PROTECTED]):
I strongly second Kirill on this matter.
IMHO, we should _avoid_ as much as possible exposing internal kernel
state to applications, unless a _real_ need for it is _clearly_
demonstrated. The reasons for this are quite obvious.
Quoting Oren Laadan ([EMAIL PROTECTED]):
Serge E. Hallyn wrote:
Quoting Oren Laadan ([EMAIL PROTECTED]):
I strongly second Kirill on this matter.
IMHO, we should _avoid_ as much as possible exposing internal kernel
state to applications, unless a _real_ need for it is _clearly_
Daniel Lezcano wrote:
> Pavel Emelyanov wrote:
>> Kirill Korotaev wrote:
>>> Cedric Le Goater wrote:
Hello Kirill !
Kirill Korotaev wrote:
> Pierre,
>
> my point is that after you've added interface "set IPCID", you'll need
> more and more for checkpointing:
> -
Pavel Emelyanov wrote:
Kirill Korotaev wrote:
Cedric Le Goater wrote:
Hello Kirill !
Kirill Korotaev wrote:
Pierre,
my point is that after you've added interface "set IPCID", you'll need
more and more for checkpointing:
- "create/setup conntrack" (otherwise connections get dropped),
- "set
Kirill Korotaev wrote:
>
> Cedric Le Goater wrote:
>> Hello Kirill !
>>
>> Kirill Korotaev wrote:
>>> Pierre,
>>>
>>> my point is that after you've added interface "set IPCID", you'll need
>>> more and more for checkpointing:
>>> - "create/setup conntrack" (otherwise connections get dropped),
>>>
Cedric Le Goater wrote:
> Hello Kirill !
>
> Kirill Korotaev wrote:
>> Pierre,
>>
>> my point is that after you've added interface "set IPCID", you'll need
>> more and more for checkpointing:
>> - "create/setup conntrack" (otherwise connections get dropped),
>> - "set task start time" (needed
Cedric Le Goater wrote:
Hello Kirill !
Kirill Korotaev wrote:
Pierre,
my point is that after you've added interface set IPCID, you'll need
more and more for checkpointing:
- create/setup conntrack (otherwise connections get dropped),
- set task start time (needed for Oracle
Daniel Lezcano wrote:
Pavel Emelyanov wrote:
Kirill Korotaev wrote:
Cedric Le Goater wrote:
Hello Kirill !
Kirill Korotaev wrote:
Pierre,
my point is that after you've added interface set IPCID, you'll need
more and more for checkpointing:
- create/setup conntrack (otherwise connections
Pavel Emelyanov wrote:
Kirill Korotaev wrote:
Cedric Le Goater wrote:
Hello Kirill !
Kirill Korotaev wrote:
Pierre,
my point is that after you've added interface set IPCID, you'll need
more and more for checkpointing:
- create/setup conntrack (otherwise connections get dropped),
- set task
Kirill Korotaev wrote:
Cedric Le Goater wrote:
Hello Kirill !
Kirill Korotaev wrote:
Pierre,
my point is that after you've added interface set IPCID, you'll need
more and more for checkpointing:
- create/setup conntrack (otherwise connections get dropped),
- set task start time (needed
Hello Kirill !
Kirill Korotaev wrote:
Pierre,
my point is that after you've added interface "set IPCID", you'll need more and
more for checkpointing:
- "create/setup conntrack" (otherwise connections get dropped),
- "set task start time" (needed for Oracle checkpointing BTW),
- "set some
Pierre,
my point is that after you've added interface "set IPCID", you'll need more and
more for checkpointing:
- "create/setup conntrack" (otherwise connections get dropped),
- "set task start time" (needed for Oracle checkpointing BTW),
- "set some statistics counters (e.g. networking or
Kirill Korotaev wrote:
> Why user space can need this API? for checkpointing only?
I would say "at least for checkpointing"... ;) May be someone else may find an
interest about this for something else.
In fact, I'm sure that you have some interest in checkpointing; and thus, you
have probably
Why user space can need this API? for checkpointing only?
Then I would not consider it for inclusion until it is clear how to implement
checkpointing.
As for me personally - I'm against exporting such APIs, since they are not
needed in real-life user space applications and maintaining it
Hi again,
Thinking more about this, I think I must clarify why I choose this way.
In fact, the idea of these patches is to provide the missing user APIs (or
extend the existing ones) that allow to set or update _all_ properties of all
IPCs, as needed in the case of the checkpoint/restart
Hi again,
Thinking more about this, I think I must clarify why I choose this way.
In fact, the idea of these patches is to provide the missing user APIs (or
extend the existing ones) that allow to set or update _all_ properties of all
IPCs, as needed in the case of the checkpoint/restart
Why user space can need this API? for checkpointing only?
Then I would not consider it for inclusion until it is clear how to implement
checkpointing.
As for me personally - I'm against exporting such APIs, since they are not
needed in real-life user space applications and maintaining it
Kirill Korotaev wrote:
Why user space can need this API? for checkpointing only?
I would say at least for checkpointing... ;) May be someone else may find an
interest about this for something else.
In fact, I'm sure that you have some interest in checkpointing; and thus, you
have probably some
Pierre,
my point is that after you've added interface set IPCID, you'll need more and
more for checkpointing:
- create/setup conntrack (otherwise connections get dropped),
- set task start time (needed for Oracle checkpointing BTW),
- set some statistics counters (e.g. networking or taskstats)
-
Hello Kirill !
Kirill Korotaev wrote:
Pierre,
my point is that after you've added interface set IPCID, you'll need more and
more for checkpointing:
- create/setup conntrack (otherwise connections get dropped),
- set task start time (needed for Oracle checkpointing BTW),
- set some statistics
Alexey Dobriyan wrote:
> On Tue, Jan 29, 2008 at 05:02:38PM +0100, [EMAIL PROTECTED] wrote:
>> This patch provides three new API to change the ID of an existing
>> System V IPCs.
>>
>> These APIs are:
>> long msg_chid(struct ipc_namespace *ns, int id, int newid);
>> long
Alexey Dobriyan wrote:
On Tue, Jan 29, 2008 at 05:02:38PM +0100, [EMAIL PROTECTED] wrote:
This patch provides three new API to change the ID of an existing
System V IPCs.
These APIs are:
long msg_chid(struct ipc_namespace *ns, int id, int newid);
long sem_chid(struct
On Tue, Jan 29, 2008 at 05:02:38PM +0100, [EMAIL PROTECTED] wrote:
> This patch provides three new API to change the ID of an existing
> System V IPCs.
>
> These APIs are:
> long msg_chid(struct ipc_namespace *ns, int id, int newid);
> long sem_chid(struct ipc_namespace *ns, int id,
From: Pierre Peiffer <[EMAIL PROTECTED]>
This patch provides three new API to change the ID of an existing
System V IPCs.
These APIs are:
long msg_chid(struct ipc_namespace *ns, int id, int newid);
long sem_chid(struct ipc_namespace *ns, int id, int newid);
long
From: Pierre Peiffer [EMAIL PROTECTED]
This patch provides three new API to change the ID of an existing
System V IPCs.
These APIs are:
long msg_chid(struct ipc_namespace *ns, int id, int newid);
long sem_chid(struct ipc_namespace *ns, int id, int newid);
long
35 matches
Mail list logo
