All of lore.kernel.org
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] RFC: hidden environment variables
Date: Mon, 23 Apr 2007 15:28:51 -0500	[thread overview]
Message-ID: <462D1703.9000907@freescale.com> (raw)
In-Reply-To: <20070423192221.BCC70353A40@atlas.denx.de>

Wolfgang Denk wrote:
> In message <462CE302.7030302@freescale.com> you wrote:
> 
>>I'd like to propose a new feature for U-Boot: hidden environment variables.  These are 
>>variables that are stored in environment but are normally not visible to the user. 
>>Specifically, a hidden environment variable would have these properties:
> 
> 
> Why would you want to hide them?

To provide internal storage for functionality (in this case, a command 
to manage non-probeable jumpers and such) without exposing the storage 
format.

> * You cannot really "hide" information; for example, I often use the
>   "md" command to dump the environmentsector(s).

We're not trying to hide information; it'll all be available through the 
hwoption command anyway.

> * Your users would probably just change the code to unhide these
>   variables. Speaking for me - if I was running such a system that
>   would be one of the first things I'd change.

Sure, but then it'd be their fault if we need/want to change the storage 
format and their scripts were directly accessing the environment 
variable, and break.

It's not hugely necessary, but in general it's nicer to expose an API 
rather than a data structure where practical.  If we were to instead 
document the variable as being for internal use only (possibly 
emphasizing it with a name such as hwoptions_internal_dont_touch or 
something), would that be considered a sufficient warning that we 
wouldn't have to maintain compatibility at the environment level in the 
future, and wouldn't have to hook into setenv to make the resulting 
device tree changes if the user ignored the warning and did a setenv anyway?

> If you think about dynamically configuring U-Boot, there is  probably
> another  route  to  go  -  device  trees.  Did you happen to read the
> related discussion on #mklinux a few days ago?

Indeed, that's a potential reason to change the storage format, if we 
end up wanting to move the data into a dtb instead.

-Scott

  reply	other threads:[~2007-04-23 20:28 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-23 16:46 [U-Boot-Users] RFC: hidden environment variables Timur Tabi
2007-04-23 17:29 ` Grant Likely
2007-04-23 18:47 ` Ulf Samuelsson
2007-04-23 19:22 ` Wolfgang Denk
2007-04-23 20:28   ` Scott Wood [this message]
2007-04-23 21:51     ` Wolfgang Denk
2007-04-23 23:20       ` Timur Tabi
2007-04-24  0:12         ` Wolfgang Denk
2007-04-24 18:58           ` Rune Torgersen
2007-04-23 19:28 ` Ben Warren
2007-04-23 19:32   ` Ulf Samuelsson
2007-04-23 19:39     ` Ben Warren
2007-04-23 19:45       ` Timur Tabi
2007-04-23 19:53         ` Ben Warren
2007-04-23 21:49           ` Timur Tabi
2007-04-23 22:04             ` Ben Warren
2007-04-23 21:37         ` Wolfgang Denk
2007-04-23 21:56           ` Timur Tabi
2007-04-23 22:13             ` Wolfgang Denk
2007-04-23 23:19               ` Timur Tabi
2007-04-24  0:06                 ` Wolfgang Denk
2007-04-23 21:34     ` Wolfgang Denk
2007-04-24  9:05     ` Ladislav Michl
2007-04-23 19:49   ` Scott Wood
2007-04-23 21:40     ` Wolfgang Denk
2007-04-23 19:50   ` Timur Tabi
2007-04-23 20:05     ` Jeff Mann
2007-04-23 21:46       ` Wolfgang Denk
2007-04-23 21:51       ` Timur Tabi
2007-04-23 22:05         ` Wolfgang Denk
2007-04-23 23:14           ` Timur Tabi
2007-04-23 23:52             ` Wolfgang Denk
2007-04-24 13:43               ` Truong, Loc
2007-04-23 21:43     ` Wolfgang Denk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=462D1703.9000907@freescale.com \
    --to=scottwood@freescale.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.