On Sun, 2005-02-27 at 23:39 -0800, Andrew Morton wrote:

Guillaume Thouvenin [off-list ref] wrote:

quoted

   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