From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754077AbXDRQGi (ORCPT ); Wed, 18 Apr 2007 12:06:38 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754093AbXDRQGi (ORCPT ); Wed, 18 Apr 2007 12:06:38 -0400 Received: from wr-out-0506.google.com ([64.233.184.232]:39640 "EHLO wr-out-0506.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754077AbXDRQGh (ORCPT ); Wed, 18 Apr 2007 12:06:37 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=qvtA0FOUsvhj2RKej52l1705yjq3ebrvCTQkF4XtT2bQx4F/pO7z6REvrwJ8N4mXL5MwCvw8C6Yed+ptOymVKWnNZhDnTotrsF0Vo1rctNLemUevr6AsGQbvLY7WyiGL9AXdsmVjesNZgxuYr3V0eaS7Hqv0LCuiDMyOK6umcOc= Message-ID: <46264201.3060007@gmail.com> Date: Thu, 19 Apr 2007 01:06:25 +0900 From: Tejun Heo User-Agent: Icedove 1.5.0.10 (X11/20070307) MIME-Version: 1.0 To: Cornelia Huck CC: linux-kernel , Alan Stern , Greg K-H , Rusty Russell , dmitry.torokhov@gmail.com Subject: Re: [PATCH RFD] alternative kobject release wait mechanism References: <20070416193619.4659a847@gondolin.boeblingen.de.ibm.com> <20070417184110.GJ10619@htj.dyndns.org> <20070418170652.7bee0952@gondolin.boeblingen.de.ibm.com> In-Reply-To: <20070418170652.7bee0952@gondolin.boeblingen.de.ibm.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Cornelia Huck wrote: > On Wed, 18 Apr 2007 03:41:10 +0900, > Tejun Heo wrote: > > > > OK, I hit a bit on the code. Once I saved a reference to the completion > in kobject_cleanup, it seemed to survive a load/unload testloop for a > module registering a device. However, I still dislike this "list of > waiters" approach, it looks too complex... Heh heh, I'm amazed it actually works. Agreed that the list walking isn't pretty but adding completion to each kobject still feels like too much of overhead just for release waiting. Any better ideas? Thanks. -- tejun