Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756049Ab2BMAML (ORCPT ); Sun, 12 Feb 2012 19:12:11 -0500 Received: from mail-we0-f174.google.com ([74.125.82.174]:39900 "EHLO mail-we0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754757Ab2BMAMJ convert rfc822-to-8bit (ORCPT ); Sun, 12 Feb 2012 19:12:09 -0500 MIME-Version: 1.0 In-Reply-To: References: <1328425088-6562-1-git-send-email-yinghai@kernel.org> <1328425088-6562-5-git-send-email-yinghai@kernel.org> From: Bjorn Helgaas Date: Sun, 12 Feb 2012 16:11:48 -0800 Message-ID: Subject: Re: [PATCH 04/24] PCI: Add busn_res operation functions To: Yinghai Lu Cc: Jesse Barnes , Benjamin Herrenschmidt , Tony Luck , Dominik Brodowski , Andrew Morton , Linus Torvalds , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-System-Of-Record: true Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1548 Lines: 35 On Sun, Feb 12, 2012 at 4:03 PM, Yinghai Lu wrote: > On Sun, Feb 12, 2012 at 3:51 PM, Bjorn Helgaas wrote: >>> >>>> >>>> I think it would be better to remove the bus resource from the tree, >>>> change its "end," then re-insert it. >>> >>> how about parent buses that have extended top? >> >> I don't understand your question. ?I assume you mean there's a case >> where remove/update/reinsert doesn't work, but I don't see why that >> would be a problem. ?Can you show an example? > > I mean parent busn_res already had several level's children busn_res. > and every level may have some siblings. > before remove will need to record those resources, to later to put them back. > > that just increase not necessary complexity. because we already know > those resource could be extended safely. You're doing surgery on the middle of a relatively complicated data structure. Now readers of the code have to trust that not only does kernel/resource.c work correctly, but they also have to examine this PCI code to make sure that these alterations are safe. I know this is all crystal-clear in your mind, and no doubt it is correct right now, but I don't think it is a reader-friendly approach. But I don't expect to convince you, so I'll stop trying :) Bjorn -- 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/