From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wolfgang Denk Date: Mon, 19 Oct 2020 16:54:50 +0200 Subject: [PATCH 11/11] bootm: Support string substitution in bootargs In-Reply-To: <20201019135602.3943835-12-sjg@chromium.org> References: <20201019135602.3943835-1-sjg@chromium.org> <20201019135602.3943835-12-sjg@chromium.org> Message-ID: <283890.1603119290@gemini.denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Dear Simon, In message <20201019135602.3943835-12-sjg@chromium.org> you wrote: > In some cases it is necessary to pass parameters to Linux so that it will > boot correctly. For example, the rootdev parameter is often used to > specify the root device. However the root device may change depending on > whence U-Boot loads the kernel. At present it is necessary to build up > the command line by adding device strings to it one by one. > > It is often more convenient to provide a template for bootargs, with > U-Boot doing the substitution from other environment variables. > > Add a way to substitute strings in the bootargs variable. This allows > things like "rootdev=%U" to be used in bootargs, with the %U substitution > providing the UUID of the root device. Argh, no, please don't. You add something unconditionally to common code which very few people need. U-Boot size is growing all the time because of such ... features. This may be acceptable on the systems you have in mind, but I consider this selfish. Why do we have to add yet another non-standard way of substituting variables in a string? Can we not use alreay existing methonds instead? Why do you have to use "%U" in your template instead of for example "${uuid}" ? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de If you use modules, you pay the price. Sane embedded solutions running in "tight" environments don't use modules :-) -- Benjamin Herrenschmidt in <1258234866.2140.451.camel@pasglop>