From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by ozlabs.org (Postfix) with ESMTP id 06FAEDDF09 for ; Sat, 23 Feb 2008 02:50:40 +1100 (EST) Received: by an-out-0708.google.com with SMTP id c37so109795anc.78 for ; Fri, 22 Feb 2008 07:50:39 -0800 (PST) Message-ID: Date: Fri, 22 Feb 2008 08:50:39 -0700 From: "Grant Likely" Sender: glikely@secretlab.ca To: "David Woodhouse" Subject: Re: [PATCH] Add support for binary includes. In-Reply-To: <1203670971.5771.41.camel@shinybook.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: <20080220191941.GA2062@ld0162-tx32.am.freescale.net> <1203670971.5771.41.camel@shinybook.infradead.org> Cc: Scott Wood , linuxppc-dev@ozlabs.org, jdl@jdl.com List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Fri, Feb 22, 2008 at 2:02 AM, David Woodhouse wrote: > > On Thu, 2008-02-21 at 23:05 -0700, Grant Likely wrote: > > Can I ask; what is the intended usage of such a thing? How large > > would a typical binary blob be? > > Device firmware? That's what I was wondering about. Is this really a good idea? Effectively, in the Linux kernel the device tree is being used as a big blob of initdata, except that it cannot free the memory allocated by the device tree when it is complete. As it is right now, device trees seem to weigh in between 4-8kB, a pretty insignificant size for memory that cannot be reclaimed. However, if firmware blobs start getting added to the tree that size could balloon pretty quickly. I'm not actually opposed to the feature, and I understand that it is needed for the new u-boot image format, but I think we need some usage guidelines in place when this feature is merged. As much as possible I think we should be directing developers to use the existing firmware loading facilities in the Linux kernel. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd.