From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from AGRXSUSMAILB.smiths.aero (host241-chi.smiths-group.com [65.216.75.241]) by ozlabs.org (Postfix) with ESMTP id A49AFDE031 for ; Sat, 24 Mar 2007 02:48:34 +1100 (EST) Message-ID: <4603F6CE.6060805@smiths-aerospace.com> Date: Fri, 23 Mar 2007 11:48:30 -0400 From: Jerry Van Baren MIME-Version: 1.0 To: Scott Wood Subject: Re: [PATCH] Remove bogus errors from check_chosen. References: <20070322161109.GA20512@ld0162-tx32.am.freescale.net> <20070323033158.GG28006@localhost.localdomain> <20070323150517.GB6060@ld0162-tx32.am.freescale.net> <4603F077.9090905@smiths-aerospace.com> <20070323153609.GE6060@ld0162-tx32.am.freescale.net> In-Reply-To: <20070323153609.GE6060@ld0162-tx32.am.freescale.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Cc: linuxppc-dev@ozlabs.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Scott Wood wrote: > On Fri, Mar 23, 2007 at 11:21:27AM -0400, Jerry Van Baren wrote: >> The -q[q[q]] I added cuts down/eliminates the moaning, but you still >> have to -f force the output which doesn't match what Scott is advocating >> if I understand him. >> >> The gcc -Wall is backwards to what we should have, perhaps adding --no* >> options like: >> --nochosen >> --nocpu >> --noarmyboots >> to tell dtc that lonely barefoot blobs are OK. > > There should also be a --no-validate option to turn everything off, if > the user is confident that the tree is right and doesn't want to get > broken by new dtcs that have new error categories (or if the user is > using dtc to compile some other type of tree than an OF-ish device tree). > > In other words, there should be a clear separation between the structural > layer and the semantic layer, even if the same binary can do both. > > -Scott Unless I'm missing an error scenario (entirely possible), --no-validate is nothing more than -f -qqq which forces the output and quiets the moaning. Just not as pretty... I would still advocate being able to disable individual warning/errors. For instance, for u-boot, the chosen (and other) nodes are generated by u-boot so it is OK to not have them in the source. If something new comes along that _is_ needed, and I would feel better if only the chosen node warning was suppressed and dtc _would_ complain about the new missing node. Either way you pick it there will be hypothetical, and probably eventually real, scenarios the that wrong choice will be made. gvb