From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roland Dreier Subject: Re: idr_get_new_exact ? Date: Mon, 20 Sep 2010 13:35:42 -0700 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: In-Reply-To: (Ohad Ben-Cohen's message of "Mon, 20 Sep 2010 16:11:31 +0200") Sender: linux-i2c-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Ohad Ben-Cohen Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, "Jean Delvare (PC drivers, core)" , "Ben Dooks (embedded platforms)" , Roland Dreier , Sean Hefty , Hal Rosenstock , Steve Wise , Neil Brown , Paul Mackerras , linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, dm-devel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, linux-raid-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-ppp-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org List-Id: dm-devel.ids > Occasionally, drivers care about the value that idr associates with > their pointers. > > Today we have idr_get_new_above() which allocates a new idr entry > above or equal to a given starting id, but sometimes drivers need to > force an exact value. > > To overcome this small API gap, drivers are wrapping idr_get_new_above > and then either BUG_ON() or just call idr_remove() and returns -EBUSY > when idr allocates them an id which is different than their requested > value. Looks fine to me as an improvement over the status quo, but I wonder how many of these places could use the radix_tree stuff instead? If you're not using the ability of the idr code to assign an id for you, then it seems the radix_tree API is a better fit. - R. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roland Dreier Date: Mon, 20 Sep 2010 20:35:42 +0000 Subject: Re: idr_get_new_exact ? Message-Id: List-Id: References: In-Reply-To: (Ohad Ben-Cohen's message of "Mon, 20 Sep 2010 16:11:31 +0200") MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Ohad Ben-Cohen Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, "Jean Delvare (PC drivers, core)" , "Ben Dooks (embedded platforms)" , Roland Dreier , Sean Hefty , Hal Rosenstock , Steve Wise , Neil Brown , Paul Mackerras , linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, dm-devel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, linux-raid-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-ppp-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org > Occasionally, drivers care about the value that idr associates with > their pointers. > > Today we have idr_get_new_above() which allocates a new idr entry > above or equal to a given starting id, but sometimes drivers need to > force an exact value. > > To overcome this small API gap, drivers are wrapping idr_get_new_above > and then either BUG_ON() or just call idr_remove() and returns -EBUSY > when idr allocates them an id which is different than their requested > value. Looks fine to me as an improvement over the status quo, but I wonder how many of these places could use the radix_tree stuff instead? If you're not using the ability of the idr code to assign an id for you, then it seems the radix_tree API is a better fit. - R. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757505Ab0ITUfx (ORCPT ); Mon, 20 Sep 2010 16:35:53 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]:48529 "EHLO sj-iport-6.cisco.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753042Ab0ITUfv (ORCPT ); Mon, 20 Sep 2010 16:35:51 -0400 Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.56,395,1280707200"; d="scan'208";a="592247779" From: Roland Dreier To: Ohad Ben-Cohen Cc: linux-kernel@vger.kernel.org, "Jean Delvare \(PC drivers\, core\)" , "Ben Dooks \(embedded platforms\)" , Roland Dreier , Sean Hefty , Hal Rosenstock , Steve Wise , Neil Brown , Paul Mackerras , linux-i2c@vger.kernel.org, linux-rdma@vger.kernel.org, dm-devel@redhat.com, linux-raid@vger.kernel.org, linux-ppp@vger.kernel.org, netdev@vger.kernel.org, akpm@linux-foundation.org Subject: Re: idr_get_new_exact ? References: X-Message-Flag: Warning: May contain useful information Date: Mon, 20 Sep 2010 13:35:42 -0700 In-Reply-To: (Ohad Ben-Cohen's message of "Mon, 20 Sep 2010 16:11:31 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Occasionally, drivers care about the value that idr associates with > their pointers. > > Today we have idr_get_new_above() which allocates a new idr entry > above or equal to a given starting id, but sometimes drivers need to > force an exact value. > > To overcome this small API gap, drivers are wrapping idr_get_new_above > and then either BUG_ON() or just call idr_remove() and returns -EBUSY > when idr allocates them an id which is different than their requested > value. Looks fine to me as an improvement over the status quo, but I wonder how many of these places could use the radix_tree stuff instead? If you're not using the ability of the idr code to assign an id for you, then it seems the radix_tree API is a better fit. - R. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roland Dreier Subject: Re: idr_get_new_exact ? Date: Mon, 20 Sep 2010 13:35:42 -0700 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, "Jean Delvare \(PC drivers\, core\)" , "Ben Dooks \(embedded platforms\)" , Roland Dreier , Sean Hefty , Hal Rosenstock , Steve Wise , Neil Brown , Paul Mackerras , linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, dm-devel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, linux-raid-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-ppp-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org To: Ohad Ben-Cohen Return-path: In-Reply-To: (Ohad Ben-Cohen's message of "Mon, 20 Sep 2010 16:11:31 +0200") Sender: linux-i2c-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: netdev.vger.kernel.org > Occasionally, drivers care about the value that idr associates with > their pointers. > > Today we have idr_get_new_above() which allocates a new idr entry > above or equal to a given starting id, but sometimes drivers need to > force an exact value. > > To overcome this small API gap, drivers are wrapping idr_get_new_above > and then either BUG_ON() or just call idr_remove() and returns -EBUSY > when idr allocates them an id which is different than their requested > value. Looks fine to me as an improvement over the status quo, but I wonder how many of these places could use the radix_tree stuff instead? If you're not using the ability of the idr code to assign an id for you, then it seems the radix_tree API is a better fit. - R.