Messages in this thread | | | Subject | Re: [Lse-tech] Re: A common layer for Accounting packages | From | Evgeniy Polyakov <> | Date | Mon, 28 Feb 2005 11:04:36 +0300 |
| |
On Sun, 2005-02-27 at 23:39 -0800, Andrew Morton wrote: > Guillaume Thouvenin <guillaume.thouvenin@bull.net> 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 [unhandled content-type:application/pgp-signature] | |