Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751544Ab2KGIHb (ORCPT ); Wed, 7 Nov 2012 03:07:31 -0500 Received: from li42-95.members.linode.com ([209.123.162.95]:59999 "EHLO li42-95.members.linode.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750761Ab2KGIHa (ORCPT ); Wed, 7 Nov 2012 03:07:30 -0500 Subject: Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Pantelis Antoniou In-Reply-To: Date: Wed, 7 Nov 2012 09:06:53 +0100 Cc: Rob Herring , Deepak Saxena , Benjamin Herrenschmidt , Scott Wood , Tony Lindgren , Russ Dill , Felipe Balbi , Benoit Cousson , linux-kernel , Koen Kooi , Matt Porter , linux-omap@vger.kernel.org, Kevin Hilman , Paul Walmsley , devicetree-discuss@lists.ozlabs.org Content-Transfer-Encoding: 7bit Message-Id: References: <02FF5400-9F97-4B8A-AEF0-267B01C8099F@antoniou-consulting.com> To: Grant Likely X-Mailer: Apple Mail (2.1085) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4343 Lines: 106 Hi Grant, On Nov 6, 2012, at 9:45 PM, Grant Likely wrote: > On Tue, Nov 6, 2012 at 7:34 PM, Pantelis Antoniou > wrote: >> On Nov 6, 2012, at 12:14 PM, Grant Likely wrote: >>> On Tue, Nov 6, 2012 at 10:30 AM, Pantelis Antoniou >>> wrote: >>>> For hot-plugging, you need it. Whether kernel code can deal with >>>> large parts of the DT going away... How about we use the dead >>>> properties method and move/tag the removed modes as such, and not >>>> really remove them. >>> >>> Nodes already use krefs, and I'm thinking about making them kobjects >>> so that they appear in sysfs and we'll have some tools to figure out >>> when reference counts don't get decremented properly. >>> >> >> From the little I've looked in the of code, and the drivers, it's going >> to be pretty bad. I don't think all users take references properly, and >> we have a big global lock for accessing the DT. > > I'm a lot more optimistic on this front... I wrote a patch today to > make the change and took some measurements: > > On the versatile express qemu model I measured the free memory with > /proc/device-tree, with /sys/device-tree, and with both. Here's what I > found: > > /proc/device-tree only: 114776kB free > /sys/device-tree only: 114792kB free > both enabled: 114716kB free > > The back of a napkin calculation indicates that on this platform > /proc/devicetree costs 76kB and /sys/device-tree costs 60kb. I'm happy > to see that using /sys instead of /proc appears to be slightly cheaper > which makes it easier to justify the change. The diffstat makes me > even happier: > > arch/arm/plat-omap/Kconfig | 1 - > arch/powerpc/platforms/pseries/dlpar.c | 23 ----------- > arch/powerpc/platforms/pseries/reconfig.c | 40 ------------------ > drivers/of/Kconfig | 8 ---- > drivers/of/base.c | 116 > ++++++++++++++++++++++++++++------------------------ > drivers/of/fdt.c | 5 ++- > fs/proc/Makefile | 1 - > fs/proc/proc_devtree.c | 13 +----- > fs/proc/root.c | 4 +- > include/linux/of.h | 35 ++++++++++++---- > include/linux/proc_fs.h | 16 -------- > include/linux/string.h | 11 +++++ > 12 files changed, 107 insertions(+), 166 deletions(-) > Interesting. Not so bad then. > There are still a few odds and ends that need to be tidied up, but > I'll get it out for review shortly. I've not touched the sparc code > yet, and I need to take another look over the existing OF_DYNAMIC > code. I think that CONFIG_OF_DYNAMIC will probably go away and the add > node/property functions will get used by fdt.c and pdt.c for initial > construction of the device tree. CONFIG_OF_DYNAMIC never made sense to me. Glad to see the config option gone. I'm not totally up to date with the -next dt stuff, but if we're there can we rename all the prom_ functions to something saner? > >> Adding and removing nodes at runtime as part of the normal operation of >> the system (and not as something that happens once in a blue moon under >> controlled conditions) will uncover lots of bugs. > > I'm hoping so! Its time to clean that mess up. :-) Fortunately adding > nodes is not where we're going to have problems. The problems will be > on node removal. Addition-only at least means we can have something > useful before hunting down and squashing all the bugs. I'll admit that removing nodes is going to be quite rare at least for me use cases. I did come across a couple of people that do hot-plugging (using something completely different) that could use it for sure. > >> So let's think about locking too > > Yes, the locking does need to be sorted out. > Perhaps come up with a dt-stress test tool/boot time validator? > g. Regards -- Pantelis P.S. Lots of teeth grinding in the ELCE about the lack of a DT preprocessor. The pinctrl arguments have been mentioned more than once. -- 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/