[Top] [All Lists]

Re: [Lse-tech] Re: A common layer for Accounting packages

To: Andrew Morton <akpm@xxxxxxxx>
Subject: Re: [Lse-tech] Re: A common layer for Accounting packages
From: Evgeniy Polyakov <johnpol@xxxxxxxxxxx>
Date: Mon, 28 Feb 2005 11:04:36 +0300
Cc: Guillaume Thouvenin <guillaume.thouvenin@xxxxxxxx>, kaigai@xxxxxxxxxxxxx, marcelo.tosatti@xxxxxxxxxxxx, davem@xxxxxxxxxx, jlan@xxxxxxx, lse-tech@xxxxxxxxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx, elsa-devel@xxxxxxxxxxxxxxxxxxxxx
In-reply-to: <20050227233943.6cb89226.akpm@xxxxxxxx>
Organization: MIPT
References: <42168D9E.1010900@xxxxxxx> <20050218171610.757ba9c9.akpm@xxxxxxxx> <421993A2.4020308@xxxxxxxxxxxxx> <421B955A.9060000@xxxxxxx> <421C2B99.2040600@xxxxxxxxxxxxx> <421CEC38.7010008@xxxxxxx> <421EB299.4010906@xxxxxxxxxxxxx> <20050224212839.7953167c.akpm@xxxxxxxx> <20050227094949.GA22439@xxxxxxxxxx> <4221E548.4000008@xxxxxxxxxxxxx> <20050227140355.GA23055@xxxxxxxxxx> <42227AEA.6050002@xxxxxxxxxxxxx> <1109575236.8549.14.camel@xxxxxxxxxxxxxxxxxxxxxxxx> <20050227233943.6cb89226.akpm@xxxxxxxx>
Reply-to: johnpol@xxxxxxxxxxx
Sender: netdev-bounce@xxxxxxxxxxx
On Sun, 2005-02-27 at 23:39 -0800, Andrew Morton wrote:
> Guillaume Thouvenin <guillaume.thouvenin@xxxxxxxx> wrote:
> >
> >    Ok the protocol is maybe too "basic" but with this mechanism the user
> >  space application that uses the fork connector can start and stop the
> >  send of messages. This implementation needs somme improvements because
> >  currently, if two application are using the fork connector one can
> >  enable it and the other don't know if it is enable or not, but the idea
> >  is here I think.
> Yes.  But this problem can be solved in userspace, with a little library
> function and a bit of locking.
> IOW: use the library to enable/disable the fork connector rather than
> directly doing syscalls.
> It has the problem that if a client of that library crashes, the counter
> gets out of whack, but really, it's not all _that_ important, and to handle
> this properly in-kernel each client would need an open fd against some
> object so we can do the close-on-exit thing properly.  You'd need to create
> a separate netlink socket for the purpose.

Why dont just extend protocol a bit?
Add header after cn_msg, which will have get/set field and that is all.
Properly using seq/ack fields userspace can avoid locks.

        Evgeniy Polyakov

Crash is better than data corruption -- Arthur Grabowski

Attachment: signature.asc
Description: This is a digitally signed message part

<Prev in Thread] Current Thread [Next in Thread>