Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261505AbVDZSOO (ORCPT ); Tue, 26 Apr 2005 14:14:14 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261577AbVDZSOO (ORCPT ); Tue, 26 Apr 2005 14:14:14 -0400 Received: from relay.2ka.mipt.ru ([194.85.82.65]:8069 "EHLO 2ka.mipt.ru") by vger.kernel.org with ESMTP id S261505AbVDZSOI (ORCPT ); Tue, 26 Apr 2005 14:14:08 -0400 Date: Tue, 26 Apr 2005 22:13:25 +0400 From: Evgeniy Polyakov To: johnpol@2ka.mipt.ru Cc: dtor_core@ameritech.net, dmitry.torokhov@gmail.com, netdev@oss.sgi.com, Greg KH , Jamal Hadi Salim , Kay Sievers , Herbert Xu , James Morris , Guillaume Thouvenin , linux-kernel@vger.kernel.org, Andrew Morton , Thomas Graf , Jay Lan Subject: Re: [1/1] connector/CBUS: new messaging subsystem. Revision number next. Message-ID: <20050426221325.20fbba58@zanzibar.2ka.mipt.ru> In-Reply-To: <20050426221026.108f3698@zanzibar.2ka.mipt.ru> References: <20050411125932.GA19538@uganda.factory.vocord.ru> <20050426202437.234e7d45@zanzibar.2ka.mipt.ru> <20050426220354.5dd619bf@zanzibar.2ka.mipt.ru> <20050426221026.108f3698@zanzibar.2ka.mipt.ru> Reply-To: johnpol@2ka.mipt.ru Organization: MIPT X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.7.5 (2ka.mipt.ru [194.85.82.65]); Tue, 26 Apr 2005 22:13:38 +0400 (MSD) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1724 Lines: 41 On Tue, 26 Apr 2005 22:10:26 +0400 Evgeniy Polyakov wrote: > > > > There may not be the same work with different data. > > > > > > > > > > Ugh, that really blows. Now every user of a particular message type > > > has to coordinate efforts with other users of the same message type... > > > > > > Imability to "fire and forget" undermines usefulness of whole > > > connector. How will you for example implement hotplug notification > > > over connector? Have kobject_hotplug wait and block other instances? > > > But wait on what? > > > > This is a simple load balancing schema. > > Netlink messages may be dropped in socket queue when > > they are bing delivered to userspace - this is the same - > > if work queue can not be scheduled, message will be dropped, > > but in this case userspace also can not be scheduled > > and message will be dropped. > > Btw, I belive we see that it is reverse direction... > So we have reverse load balancing schema here - > exactly like userspace socket queueing. > We basically can not sleep here - it will be DOS. And yet another btw - netlink is unreliable protocol, that is why there are seq and ack fields in connector's header - connector's users must implement some check on top of raw connector messages - it could be returned message with timeout resending and so on. I wrote it several times and it is in connector's documentation. Evgeniy Polyakov Only failure makes us experts. -- Theo de Raadt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/