[U-Boot-Users] RFC: hidden environment variables

[U-Boot-Users] RFC: hidden environment variables

[Timur Tabi]

WD et al:

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:

1) Doesn't show up via "print" or "echo"
2) Can't be referenced via a $
3) Can't be set via setenv

Only internal U-Boot code can modify/query these variables.  This way, internal code can 
use the existing environment data structure without having to expose this data to the user 
(and giving him the impression that he can access/manipulate this data directly).

The only drawback to this plan is that, after modifying a hidden environment variable, the 
user would need to be told to issue "saveenv" if he wants his changes saved permanently.

One advantage of this feature is that we can develop new commands that store data 
permanently without having to add hooks into _do_setenv().

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] RFC: hidden environment variables

[Grant Likely]

On 4/23/07, Timur Tabi <timur@freescale.com> wrote:
> WD et al:
>
> 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:
>
> 1) Doesn't show up via "print" or "echo"
> 2) Can't be referenced via a $
> 3) Can't be set via setenv
>
> Only internal U-Boot code can modify/query these variables.  This way, internal code can
> use the existing environment data structure without having to expose this data to the user
> (and giving him the impression that he can access/manipulate this data directly).

What use cases do you envision?  Do you have any specific examples?
Are you looking for globaly available data values; or things that
typically will be used locally by a driver or a command?

g.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] RFC: hidden environment variables

[Ulf Samuelsson]

> WD et al:
> 
> 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:
> 
> 1) Doesn't show up via "print" or "echo"
> 2) Can't be referenced via a $
> 3) Can't be set via setenv
> 

I think an attribute byte for each variable would be nice.
Then you can have attributes like:

hidden
user editable
locked
exectuable

I would for instance like to treat ethaddr differently.
This should be freely changeable until it is locked.

I would also like to get rid of the "run" command
and execute commands directly.
These commands would be referencing commands which does not need to be visible.

> Only internal U-Boot code can modify/query these variables.  This way, internal code can 
> use the existing environment data structure without having to expose this data to the user 
> (and giving him the impression that he can access/manipulate this data directly).
> 
> The only drawback to this plan is that, after modifying a hidden environment variable, the 
> user would need to be told to issue "saveenv" if he wants his changes saved permanently.
> 
> One advantage of this feature is that we can develop new commands that store data 
> permanently without having to add hooks into _do_setenv().
> 
> -- 
> Timur Tabi
> Linux Kernel Developer @ Freescale
> 


Best Regards
Ulf Samuelsson                ulf at atmel.com
Atmel Nordic AB
Mail:  Box 2033, 174 02 Sundbyberg, Sweden
Visit:  Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22     Fax +46 (8) 441 54 29
GSM    +46 (706) 22 44 57

Technical support when I am not available:
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
AVR32 Applications Group        mailto:avr32 at atmel.com
http://www.avrfreaks.net/;            http://avr32linux.org/
http://www.at91.com/ ;                ftp://at91dist:distrib at 81.80.104.162/

[U-Boot-Users] RFC: hidden environment variables

[Wolfgang Denk]

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?

> 1) Doesn't show up via "print" or "echo"
> 2) Can't be referenced via a $
> 3) Can't be set via setenv

I think you should explain in a bit more detail what you  would  like
to  use  this for; at the moment I think by hiding them you just lose
potential flexibility.

> The only drawback to this plan is that, after modifying a hidden environment variable, the 
> user would need to be told to issue "saveenv" if he wants his changes saved permanently.

There are other drawbacks:

* The environment  variable  data  structure  is  intentionally  very
  simple.  Any  such extension would probably break backward compati-
  bility.

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

* 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.

* The environment is also accessable from Linux user space tools.  No
  real "hiding" can be one there either.

> One advantage of this feature is that we can develop new commands that store data 
> permanently without having to add hooks into _do_setenv().

I'm not sure what you have in mind.

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?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It's a small world, but I wouldn't want to paint it.

[U-Boot-Users] RFC: hidden environment variables

[Scott Wood]

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

[U-Boot-Users] RFC: hidden environment variables

[Wolfgang Denk]

In message <462D1703.9000907@freescale.com> you wrote:
>
> > 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.

What would be bad about this? If I want to know the format, I just
look it up in the source code. You cannot hide that.

> > * 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.

So why making it unnecessarily complicated?

> 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.

There are many ways to break a board. If you feel that this is a
likely case, you should try and make sure you either not chage the
format or only in compatible ways.

But seriously: if youy write in the docs: Don't  mess  with  variable
XXX,  and  they  do, is their fault in exactly the same way like when
they mess with the source code. Where's the difference?

> 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?

Yes. Because you cannot stop idiots anyway. So please do't make  life
harder than absolutely necessary for clever users.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
This cultural mystique surrounding the  biological  function  --  you
realize humans are overly preoccupied with the subject.
	-- Kelinda the Kelvan, "By Any Other Name", stardate 4658.9

[U-Boot-Users] RFC: hidden environment variables

[Timur Tabi]

Wolfgang Denk wrote:
> In message <462D1703.9000907@freescale.com> you wrote:
>>> 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.
> 
> What would be bad about this? If I want to know the format, I just
> look it up in the source code. You cannot hide that.

The level of hiding that you're talking about is more extreme than the level we're talking 
about.  We're just talking about not having the variable show up when you do "print", so 
that it doesn't pollute the list of variables that the user does want to interact with.

> So why making it unnecessarily complicated?

Hidden variables aren't complicated.  I think the idea is elegant and useful.

> But seriously: if youy write in the docs: Don't  mess  with  variable
> XXX,  and  they  do, is their fault in exactly the same way like when
> they mess with the source code. Where's the difference?

Again, this is a user interface issue.  Why expose a variable to a user that he shouldn't 
touch and can't use?

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] RFC: hidden environment variables

[Wolfgang Denk]

In message <462D3F5A.1040307@freescale.com> you wrote:
>
> The level of hiding that you're talking about is more extreme than the level we're talking 
> about.  We're just talking about not having the variable show up when you do "print", so 
> that it doesn't pollute the list of variables that the user does want to interact with.

You cannot know what the user wants.

> Hidden variables aren't complicated.  I think the idea is elegant and useful.

I disagree. See my the example in my previous message why they are
evil.

> Again, this is a user interface issue.  Why expose a variable to a user that he shouldn't 
> touch and can't use?

It's not up to you to decide that he should not touch it or  that  he
cannot  use it. He can do *everything* on this system. Including very
stupid things, but maybe also a few pretty clever things.


This is why I love U-Boot and always feel frustrated when I  have  to
deal with things like a x86 BIOS (ah, great, it offers serial console
access, so I can do remote administration easily; now what - the RAID
controller needs ALT + F1 ... on the serial line... grrrrghhh).

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The best things in life are for a fee.

[U-Boot-Users] RFC: hidden environment variables

[Rune Torgersen]

> -----Original Message-----
> From: Wolfgang Denk
> > The level of hiding that you're talking about is more 
> extreme than the level we're talking 
> > about.  We're just talking about not having the variable 
> show up when you do "print", so 
> > that it doesn't pollute the list of variables that the user 
> does want to interact with.
> 
> You cannot know what the user wants.
> 
> > Hidden variables aren't complicated.  I think the idea is 
> elegant and useful.

A solution could be to have a env variable, say hide_env. If it is set,
hide variables starting with a dot (or starting with whatever hide _env
is set to), it it is not set, behave normally.

That way it won't break any exisiting boards/systems as they won't have
that variable set, and it can be turned on/off.

[U-Boot-Users] RFC: hidden environment variables

[Ben Warren]

On Mon, 2007-04-23 at 11:46 -0500, Timur Tabi wrote:
> WD et al:
> 
> 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:
> 
> 1) Doesn't show up via "print" or "echo"
> 2) Can't be referenced via a $
> 3) Can't be set via setenv
> 
> Only internal U-Boot code can modify/query these variables.  This way, internal code can 
> use the existing environment data structure without having to expose this data to the user 
> (and giving him the impression that he can access/manipulate this data directly).
> 
> The only drawback to this plan is that, after modifying a hidden environment variable, the 
> user would need to be told to issue "saveenv" if he wants his changes saved permanently.
> 
This is a pretty serious drawback.  If you really want to have
persistent storage for autonomous code, maybe we should look at a way of
allocating a block of persistent storage (either flash or serial EEPROM)
outside of ENV that gets saved when modified.
> One advantage of this feature is that we can develop new commands that store data 
> permanently without having to add hooks into _do_setenv().
> 
I guess I don't see why anything needs to be hidden.  If somebody has
access to the U-boot prompt, they control the board anyway.  From my
perspective, it's for expert use only.  Anything going to 'the field' as
an end product should have the countdown disabled, booting straight to
OS.  Of course, that's the perspective from my point of view.  Over the
last few days it's become clear to me that people here have a wide
variety of use cases and expectations regarding U-boot.

regards,
Ben

[U-Boot-Users] RFC: hidden environment variables

[Ulf Samuelsson]

> I guess I don't see why anything needs to be hidden.  If somebody has
> access to the U-boot prompt, they control the board anyway.  From my
> perspective, it's for expert use only.  Anything going to 'the field' as
> an end product should have the countdown disabled, booting straight to
> OS.  Of course, that's the perspective from my point of view.  Over the
> last few days it's become clear to me that people here have a wide
> variety of use cases and expectations regarding U-boot.
> 

Too much information = information overload for many...
I really would like to see something much closer to a PC boot screen.
where people fill in fields of information, instead of doing setenv...

Best Regards
Ulf Samuelsson

[U-Boot-Users] RFC: hidden environment variables

[Ben Warren]

On Mon, 2007-04-23 at 21:32 +0200, Ulf Samuelsson wrote:
> > I guess I don't see why anything needs to be hidden.  If somebody has
> > access to the U-boot prompt, they control the board anyway.  From my
> > perspective, it's for expert use only.  Anything going to 'the field' as
> > an end product should have the countdown disabled, booting straight to
> > OS.  Of course, that's the perspective from my point of view.  Over the
> > last few days it's become clear to me that people here have a wide
> > variety of use cases and expectations regarding U-boot.
> > 
> 
> Too much information = information overload for many...
> I really would like to see something much closer to a PC boot screen.
> where people fill in fields of information, instead of doing setenv...

Sure, but I don't think info overload was Timur's primary concern.  I
thought he wanted to make the variables RO from the command prompt.
Maybe I misunderstood.

Ben

[U-Boot-Users] RFC: hidden environment variables

[Timur Tabi]

Ben Warren wrote:

> Sure, but I don't think info overload was Timur's primary concern.  I
> thought he wanted to make the variables RO from the command prompt.
> Maybe I misunderstood.

No, I just wanted a way for U-Boot code to store data in the environment without 
interference from the user.  The reason I want to use the environment is that it already 
exists, and it already has a mechanism for saving itself to flash.

So, the obvious question is, "well, what kind of data?".  I have an idea where the user 
can tell U-Boot how the board is jumpered, so that when it boots the kernel, it can modify 
the device tree on-the-fly based on the jumper settings.  I don't want to use the setenv 
command, however, to specify these jumper settings.  I want to use a new command that does 
some parameter checking and performs other operations.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] RFC: hidden environment variables

[Ben Warren]

On Mon, 2007-04-23 at 14:45 -0500, Timur Tabi wrote:
> Ben Warren wrote:
> 
> > Sure, but I don't think info overload was Timur's primary concern.  I
> > thought he wanted to make the variables RO from the command prompt.
> > Maybe I misunderstood.
> 
> No, I just wanted a way for U-Boot code to store data in the environment without 
> interference from the user.  The reason I want to use the environment is that it already 
> exists, and it already has a mechanism for saving itself to flash.
> 
> So, the obvious question is, "well, what kind of data?".  I have an idea where the user 
> can tell U-Boot how the board is jumpered, so that when it boots the kernel, it can modify 
> the device tree on-the-fly based on the jumper settings.  I don't want to use the setenv 
> command, however, to specify these jumper settings.  I want to use a new command that does 
> some parameter checking and performs other operations.
> 
Sorry for going OT briefly, but the settings of jumpers on Freescale
eval boards are usually reflected in the BCSR, aren't they?  If so, why
not just probe at boot-up.  If not, send this e-mail directly to TRASH.

cheers,
Ben

[U-Boot-Users] RFC: hidden environment variables

[Timur Tabi]

Ben Warren wrote:

> Sorry for going OT briefly, but the settings of jumpers on Freescale
> eval boards are usually reflected in the BCSR, aren't they? 

Not all boards.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] RFC: hidden environment variables

[Ben Warren]

On Mon, 2007-04-23 at 16:49 -0500, Timur Tabi wrote:
> Ben Warren wrote:
> 
> > Sorry for going OT briefly, but the settings of jumpers on Freescale
> > eval boards are usually reflected in the BCSR, aren't they? 
> 
> Not all boards.
> 
OK.  I figured you guys would have thought of that, but sometimes I just
like the clicking sound my fingers make on the keyboard...

Sorry for the noise,
Ben 

[U-Boot-Users] RFC: hidden environment variables

[Wolfgang Denk]

In message <462D0CE7.1060009@freescale.com> you wrote:
>
> No, I just wanted a way for U-Boot code to store data in the environment without 
> interference from the user.  The reason I want to use the environment is that it already 
> exists, and it already has a mechanism for saving itself to flash.

Why do you worry about the "interference from  the  user"  part?  The
whole  idea  of  Free Software is thatit gives you all the freedom to
use the hardware and the software the way *you* want to use  it,  and
not  only  in  the restricted ways some manufacturer decided would be
good for you.

> So, the obvious question is, "well, what kind of data?".  I have an idea where the user 
> can tell U-Boot how the board is jumpered, so that when it boots the kernel, it can modify 
> the device tree on-the-fly based on the jumper settings.  I don't want to use the setenv 
> command, however, to specify these jumper settings.  I want to use a new command that does 
> some parameter checking and performs other operations.

Implement the command with all checkings yoiu want,  and  then  store
the information as a normal environment variable. Why hide it?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Unix is simple, but it takes a genius to understand the simplicity."
					             - Dennis Ritchie

[U-Boot-Users] RFC: hidden environment variables

[Timur Tabi]

Wolfgang Denk wrote:
> Why do you worry about the "interference from  the  user"  part?  The
> whole  idea  of  Free Software is thatit gives you all the freedom to
> use the hardware and the software the way *you* want to use  it,  and
> not  only  in  the restricted ways some manufacturer decided would be
> good for you.

That's a strawman argument.  We're not talking about free vs. proprietary, this is just a 
usability issue.  Obviously, the user can hack whatever he wants.  That doesn't mean that 
we shouldn't design features that make certain things easier to use.

This is really all about permanent storage without using setenv, but taking advantage of 
the environment infrastructure.  If some U-Boot module wants to store data in flash, then 
as a user I'm probably not interested in the layout of internal data structure.  I just 
want to piggy-back on the environment code without exposing two user interfaces to the user.

> Implement the command with all checkings yoiu want,  and  then  store
> the information as a normal environment variable. Why hide it?

To keep it simple from the user's perspective, and to avoid having to support setenv.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] RFC: hidden environment variables

[Wolfgang Denk]

In message <462D2B85.2010707@freescale.com> you wrote:
>
> > Why do you worry about the "interference from  the  user"  part?  The
> > whole  idea  of  Free Software is thatit gives you all the freedom to
> > use the hardware and the software the way *you* want to use  it,  and
> > not  only  in  the restricted ways some manufacturer decided would be
> > good for you.
> 
> That's a strawman argument.  We're not talking about free vs. proprietary, this is just a 
> usability issue.  Obviously, the user can hack whatever he wants.  That doesn't mean that 
> we shouldn't design features that make certain things easier to use.

It's a matter of taste. Some find it  easier  to  navigate  with  the
mouse  through  drop-down  menues,  others prefer to type a few magic
characters at a command line interface. Making  things  easy  to  use
means allowing both.

> This is really all about permanent storage without using setenv, but taking advantage of 
> the environment infrastructure.  If some U-Boot module wants to store data in flash, then 
> as a user I'm probably not interested in the layout of internal data structure.  I just 
> want to piggy-back on the environment code without exposing two user interfaces to the user.

You don't  expose  two  user  interfaces.  Make  it  clear  from  the
documentation  that  the  user is not supposed to manually chage this
variable. Heck, if you really want then make it difficult by using  a
non-printing  character in the variable name. But please don't try to
tell your users that you know better than they what's good for them.

> > Implement the command with all checkings yoiu want,  and  then  store
> > the information as a normal environment variable. Why hide it?
> 
> To keep it simple from the user's perspective, and to avoid having to support setenv.

The user will probably not care much about  a few more cryptic
environment variables. And you don't have to support setenv.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It is your destiny.                                     - Darth Vader

[U-Boot-Users] RFC: hidden environment variables

[Timur Tabi]

Wolfgang Denk wrote:

Obviously, at this point you're not going to allow support for hidden variables, so this 
discussion is academic.  With that in mind ...

> You don't  expose  two  user  interfaces.  Make  it  clear  from  the
> documentation  that  the  user is not supposed to manually chage this
> variable. 

I don't like the idea of an environment variable that the user can edit but shouldn't. 
Every times the user does 'print', it shows up.  "Look, but don't touch" is not a good 
user interface paradigm.

> Heck, if you really want then make it difficult by using  a
> non-printing  character in the variable name. But please don't try to
> tell your users that you know better than they what's good for them.

If I write code that stores data in an internal format, especially one that's subject to 
change, of course I know better than the user what's good for him.  If the user 
manipulates the data incorrectly when he's been told (via the documentation) not to touch 
it, then the code is just exposing itself to more crashes.

> The user will probably not care much about  a few more cryptic
> environment variables. And you don't have to support setenv.

How do I not support setenv() if the data is in an environment variable?  If the variable 
I need is called "jumpers", then what's to stop the user from just doing "setenv jumpers 
'blablabla'" and breaking my code?

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] RFC: hidden environment variables

[Wolfgang Denk]

In message <462D3F00.10103@freescale.com> you wrote:
> 
> I don't like the idea of an environment variable that the user can edit but shouldn't. 
> Every times the user does 'print', it shows up.  "Look, but don't touch" is not a good 
> user interface paradigm.

Actually it may be useful, though.

> If I write code that stores data in an internal format, especially one that's subject to 
> change, of course I know better than the user what's good for him.  If the user 

Sorry, but this is a pretty arrogant position. You  don't  know  what
the  user  want's  to do. You cannot know that. And you stop him from
doing clever things.

Just to give you one example: we use a linear search for  environment
variables.  Some  of  them  are  important  for the initialization of
U-Boot (like "baudrate"), others are probably completely  unused  for
normal  boot operations. Especially on slow devices like EEPROM on an
I2C bus the boot time depends a lot on the order of the  variables  -
ther  ecan be differences of 5...10 seconds between having "baudrate"
the first or the last variable  in  your  envrionment.  So  it  is  a
perfectly  sensible  optimization  procedure  to  run  a  script that
performs a "printenv" command, sort the variables by  some  criteria,
and  uses  a  series  of "setenv" commands to erase and re-create the
environment.

Maybe this is not a very good example; only few people  (perfromance-
crazy beancounters like me) will ever do that. But it explains what I
mean:  I don't intend to do anything to your variables, I'm not going
to change them in any way, yet I need to be able to display  them  by
using printenv and re-writing them using setenv.

Otherwise your modification will restict my freedom to work with  the
system like I want to do it.


> manipulates the data incorrectly when he's been told (via the documentation) not to touch 
> it, then the code is just exposing itself to more crashes.

No, not the code. The user.

With the same argument we could demand that the protect and the erase
commands be disabled, because the user can be so stupid to erase  the
U-Boot image in flash.

> How do I not support setenv() if the data is in an environment variable?  If the variable 

You do not support it, it's just there.

> I need is called "jumpers", then what's to stop the user from just doing "setenv jumpers 
> 'blablabla'" and breaking my code?

He doesn't break your code. He breaks his board. He has many other
ways to do this already.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"There are things that are so serious that you can  only  joke  about
them"                                                    - Heisenberg

[U-Boot-Users] RFC: hidden environment variables

[Wolfgang Denk]

In message <009701c785de$2e8a7bd0$9003960a@atmel.com> you wrote:
>
> Too much information = information overload for many...
> I really would like to see something much closer to a PC boot screen.
> where people fill in fields of information, instead of doing setenv...

There are obviously many different views on that topic...

But if you want to have it that way, why not enable  the  hush  shell
and  implement a simple menu based entry system which you run as boot
command. It's straightforward. And it's all there. No changes needed.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Ein weiser Herrscher kann in einem gro?en Land  mehr  Gutes  bewirken
als  in  einem kleinen - ein dummer Herrscher aber auch viel mehr Un-
fug. Da weise Herrscher seltener sind als dumme, war ich schon  immer
gegen gro?e Reiche skeptisch.                   - Herbert Rosendorfer

[U-Boot-Users] RFC: hidden environment variables

[Ladislav Michl]

On Mon, Apr 23, 2007 at 09:32:43PM +0200, Ulf Samuelsson wrote:
> Too much information = information overload for many...
> I really would like to see something much closer to a PC boot screen.
> where people fill in fields of information, instead of doing setenv...

Well, I agree here. Simple menu driven configuration is nice to have for
average user. But it is pretty easy to add without changing anything.
What stops you from running your custom board specific command from
'bootcmd' ? Here you can show menu and do configuration in your way.
And store data in environment. For power users, there could be "exit to
shell" menu option. You can even require password to be able to use
u-boot's command line. But once user gains command line interface,
she/he could be allowed to do pretty much everything.

Once again, either offer simple and idiot proof menu driven
configuration *or* give user command line and do not try to guess what
he may want to do.

U-Boot could have framework for constructing menus... Anyone still
remembers TurboVision? ;-)

Best regards,
	ladis

[U-Boot-Users] RFC: hidden environment variables

[Scott Wood]

On Mon, Apr 23, 2007 at 03:28:12PM -0400, Ben Warren wrote:
> On Mon, 2007-04-23 at 11:46 -0500, Timur Tabi wrote:
> > The only drawback to this plan is that, after modifying a hidden environment variable, the 
> > user would need to be told to issue "saveenv" if he wants his changes saved permanently.
> > 
> This is a pretty serious drawback.

In the use case we're thinking of (non-probeable jumper/dip-switch/etc.
settings that are managed through a "hwoption" command), I don't think
it's that unreasonable to require the user to saveenv after making
changes if they want the change to persist across a reset.

> If you really want to have persistent storage for autonomous code,
> maybe we should look at a way of allocating a block of persistent
> storage (either flash or serial EEPROM) outside of ENV that gets saved
> when modified.

Possibly, though whatever form it takes should be createable by build
scripts the way an environment is.

> > One advantage of this feature is that we can develop new commands
> > that store data permanently without having to add hooks into
> > _do_setenv().
> > 
> I guess I don't see why anything needs to be hidden.  If somebody has
> access to the U-boot prompt, they control the board anyway.  From my
> perspective, it's for expert use only.

It's not a security mechanism; it's to emphasize that the public
interface to the functionality is the command, not the variable.  That
way, people don't access the variable directly from scripts, and complain
that it breaks if the storage format changes.

All the information in the variable can be viewed and/or modified by
going through the command that uses it.

-Scott

[U-Boot-Users] RFC: hidden environment variables

[Wolfgang Denk]

In message <20070423194937.GA11358@ld0162-tx32.am.freescale.net> you wrote:
>
> It's not a security mechanism; it's to emphasize that the public
> interface to the functionality is the command, not the variable.  That
> way, people don't access the variable directly from scripts, and complain
> that it breaks if the storage format changes.

Just document that this is how it's to be used, but leave the user the
freedom to do what he wants.

> All the information in the variable can be viewed and/or modified by
> going through the command that uses it.

U-Boot follows the goold old principle:

"UNIX was not designed to stop you from doing stupid things,  because
that would also stop you from doing clever things."       - Doug Gwyn

Let's keep it that way. There are some of your users out there who
appreciate if they can do clever things.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Our way is peace.
	-- Septimus, the Son Worshiper, "Bread and Circuses",
	   stardate 4040.7.

[U-Boot-Users] RFC: hidden environment variables

[Timur Tabi]

Ben Warren wrote:

> This is a pretty serious drawback.  If you really want to have
> persistent storage for autonomous code, maybe we should look at a way of
> allocating a block of persistent storage (either flash or serial EEPROM)
> outside of ENV that gets saved when modified.

I'm looking for something that's much more generic.  I want to use an existing 
infrastructure, and I want something that's not hardware-specific.

>> One advantage of this feature is that we can develop new commands that store data 
>> permanently without having to add hooks into _do_setenv().
>>
> I guess I don't see why anything needs to be hidden.

Well, it doesn't *have* to be hidden, it just makes things simpler that way.  If the 
variable can't be touched by the user, then I don't have to hook into the _do_setenv() 
command.


-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] RFC: hidden environment variables

[Jeff Mann]

>Well, it doesn't *have* to be hidden, it just makes things simpler that
way.  If the variable can't be touched by the user, then I don't have to
hook into the _do_setenv() command.

You can implement an option that keeps a list of variables that should
be hidden. That way, each variable can be checked against the list
before printing it or allowing a user to change it from the prompt. With
an implementation like this, everything continues to work if the
hide_some_varibles option is not enabled. For example, variable
'hide_variable' could contain a list of other variables that are hidden.
Of course, 'hide_variable' would have to be in its own list too. Then
each variable can be searched for within 'hide_variable' before it is
printed or changed. That does not sound that dificult and is completely
backward compatable. 

-JM

[U-Boot-Users] RFC: hidden environment variables

[Wolfgang Denk]

In message <1628E43D99629C46988BE46087A3FBB997ACAA@ep-01.EmbeddedPlanet.local> you wrote:
> 
> You can implement an option that keeps a list of variables that should
> be hidden. That way, each variable can be checked against the list
> before printing it or allowing a user to change it from the prompt. With
> an implementation like this, everything continues to work if the
> hide_some_varibles option is not enabled. For example, variable
> 'hide_variable' could contain a list of other variables that are hidden.
> Of course, 'hide_variable' would have to be in its own list too. Then
> each variable can be searched for within 'hide_variable' before it is
> printed or changed. That does not sound that dificult and is completely
> backward compatable. 

... and will soon  become  terribly  slow.  Already  now  environment
variable  lookup  can  make  for a significant part of the total boot
time, especially on systems where the environment is  not  stored  in
flash memory (i. e. in EEPROM or data flash etc.).

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
When a man sits with a pretty girl for  an  hour,  it  seems  like  a
minute.  But let him sit on a hot stove for a minute -- and it's lon-
ger than any hour. That's relativity.              -- Albert Einstein

[U-Boot-Users] RFC: hidden environment variables

[Timur Tabi]

Jeff Mann wrote:

> You can implement an option that keeps a list of variables that should
> be hidden. 

That's dual-maintenance.  It would be a lot easier if the environment had support for 
generic hidden variables, so I wouldn't need to update that list.



-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] RFC: hidden environment variables

[Wolfgang Denk]

In message <462D2A6F.5090306@freescale.com> you wrote:
> 
> > You can implement an option that keeps a list of variables that should
> > be hidden. 
> 
> That's dual-maintenance.  It would be a lot easier if the environment had support for 
> generic hidden variables, so I wouldn't need to update that list.

If you don't want to break compatibility with  existing  systems  you
ill  have  to  maintain a separate list anyway - either in the source
code, or in the environment ;-)

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
We, the unwilling, led by the unknowing, are doing the impossible for
the ungrateful. We have done so much, for so long, with so little, we
are now qualified to do anything with nothing.

[U-Boot-Users] RFC: hidden environment variables

[Timur Tabi]

Wolfgang Denk wrote:

> If you don't want to break compatibility with  existing  systems  you
> ill  have  to  maintain a separate list anyway - either in the source
> code, or in the environment ;-)

Well, the point behind having hidden variables is that the source code which needs to use 
a hidden variable can just call _do_setenv() (or whatever) and have it set an environment 
variable that is hidden.  My preference would be that any variable that starts with a dot 
(.) is hidden.  That way, the source code doesn't really need to have a separate list.  It 
just names its variables with a dot.  The rest is automatic.



-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] RFC: hidden environment variables

[Wolfgang Denk]

In message <462D3DD4.2090500@freescale.com> you wrote:
>
> > If you don't want to break compatibility with  existing  systems  you
> > ill  have  to  maintain a separate list anyway - either in the source
> > code, or in the environment ;-)
> 
> Well, the point behind having hidden variables is that the source code which needs to use 
> a hidden variable can just call _do_setenv() (or whatever) and have it set an environment 
> variable that is hidden.  My preference would be that any variable that starts with a dot 
> (.) is hidden.  That way, the source code doesn't really need to have a separate list.  It 
> just names its variables with a dot.  The rest is automatic.

So far, this is a perfectly legal variable name in U-Boot. You cannot
change the meaning of such names without breaking compatibility  with
existing systems that might use such names.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
One possible reason that things aren't going  according  to  plan  is
that there never was a plan in the first place.

[U-Boot-Users] RFC: hidden environment variables

[Truong, Loc]

As a u-boot user for product development I am siding with Wolfgang on
this. U-boot, as a bootloader, can be tailored with different
"personalities", but having these as "hidden" variables may polute the
simplicity of how u-boot works. There must be a cleaner way of doing
this so that special purpose data can be embedded as a data structure
w/o using "the environment".
Best regards,
Loc

-----Original Message-----
From: u-boot-users-bounces@lists.sourceforge.net
[mailto:u-boot-users-bounces at lists.sourceforge.net] On Behalf Of
Wolfgang Denk
Sent: Monday, April 23, 2007 6:52 PM
To: Timur Tabi
Cc: uboot
Subject: Re: [U-Boot-Users] RFC: hidden environment variables

In message <462D3DD4.2090500@freescale.com> you wrote:
>
> > If you don't want to break compatibility with  existing  systems
you
> > ill  have  to  maintain a separate list anyway - either in the
source
> > code, or in the environment ;-)
> 
> Well, the point behind having hidden variables is that the source code
which needs to use 
> a hidden variable can just call _do_setenv() (or whatever) and have it
set an environment 
> variable that is hidden.  My preference would be that any variable
that starts with a dot 
> (.) is hidden.  That way, the source code doesn't really need to have
a separate list.  It 
> just names its variables with a dot.  The rest is automatic.

So far, this is a perfectly legal variable name in U-Boot. You cannot
change the meaning of such names without breaking compatibility  with
existing systems that might use such names.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
One possible reason that things aren't going  according  to  plan  is
that there never was a plan in the first place.

------------------------------------------------------------------------
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] RFC: hidden environment variables

[Wolfgang Denk]

In message <462D0E17.20106@freescale.com> you wrote:
> 
> > I guess I don't see why anything needs to be hidden.
> 
> Well, it doesn't *have* to be hidden, it just makes things simpler that way.  If the 
> variable can't be touched by the user, then I don't have to hook into the _do_setenv() 
> command.

"Can't be touched by  the  user"  is  probably  pretty  difficult  to
implement. You can just make it more difficult. At the same time, you
make perfectly legal use cases much more difficult.

Don't do it. Forget about the hiding.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It is the quality rather than the quantity that matters.
- Lucius Annaeus Seneca (4 B.C. - A.D. 65)