RFC: hidden environment variables
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().
Signature · 2 lines
Timur Tabi Linux Kernel Developer @ Freescale
Quoted 6 lines · 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:
Quoted 7 lines
1) Doesn't show up via "print" or "echo"
2) Can't be referenced via a $
3) Can't be set via setenvOnly 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.
Signature · 4 lines
Grant Likely, B.Sc. P.Eng. Secret Lab Technologies Ltd. grant.likely at secretlab.ca (403) 399-0195
Quoted 10 lines
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.
Quoted 4 lines
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).
Quoted 10 lines
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().Signature · 2 lines
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/
Quoted 4 lines · In message <[email protected]> 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?
Quoted 3 lines
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.
Quoted 2 lines
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.
Quoted 2 lines
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
Signature · 4 lines
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.
Quoted 10 lines · 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
Quoted 7 lines
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.
Quoted 3 lines
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
Quoted 8 lines
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
Quoted 9 lines · Ulf Samuelsson
Quoted 8 lines
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.
Quoted 3 lines
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
Quoted 3 lines · Ben Warren
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.
Signature · 2 lines
Timur Tabi Linux Kernel Developer @ Freescale
Quoted 5 lines · Ben Warren
Quoted 3 lines · Timur Tabi
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.
Quoted 4 lines
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.
Quoted 7 lines
Quoted 4 lines
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
Quoted 4 lines · Ben Warren
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.
Quoted 4 lines
Quoted 3 lines
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.
Signature · 2 lines
Timur Tabi Linux Kernel Developer @ Freescale
Quoted 10 lines · Timur Tabi
Quoted 3 lines · Ben Warren
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.
Quoted 6 lines
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
Quoted 1 line
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
Quoted 8 lines · Wolfgang Denk
Quoted 3 lines · In message <[email protected]> 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.
Quoted 2 lines
* 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.
Quoted 3 lines
* 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?
Quoted 3 lines
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
Quoted 4 lines · In message <[email protected]> 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
Signature · 7 lines
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
Quoted 4 lines · In message <[email protected]> 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.
Quoted 5 lines
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
Signature · 5 lines
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
Quoted 5 lines · In message <[email protected]> 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.
Quoted 2 lines
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
Signature · 6 lines
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.
Quoted 6 lines · In message <[email protected]> you wrote:
Quoted 2 lines
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
Signature · 5 lines
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)
Quoted 11 lines · In message <1628E43D99629C46988BE46087A3FBB997ACAA@ep-01.EmbeddedPlanet.local>…
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_variblesoption 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
Signature · 6 lines
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
Quoted 2 lines · Ben Warren
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.
Signature · 2 lines
Timur Tabi Linux Kernel Developer @ Freescale
Quoted 2 lines · Jeff Mann
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.
Signature · 2 lines
Timur Tabi Linux Kernel Developer @ Freescale
Quoted 6 lines · In message <[email protected]> you wrote:
Quoted 2 lines
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.
Quoted 5 lines
Quoted 2 lines
* 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?
Quoted 3 lines
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?
Quoted 8 lines
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_touchor 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
Signature · 6 lines
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
Quoted 5 lines · Wolfgang Denk
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.
Quoted 2 lines
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.
Signature · 2 lines
Timur Tabi Linux Kernel Developer @ Freescale
Quoted 7 lines · Timur Tabi
Quoted 2 lines · Ben Warren
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
Quoted 6 lines · In message <[email protected]> you wrote:
Quoted 3 lines
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
Signature · 6 lines
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.
Quoted 10 lines · In message <[email protected]> you wrote:
Quoted 6 lines
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.
Quoted 4 lines
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.
Quoted 4 lines
Quoted 2 lines
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
Signature · 4 lines
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
Quoted 3 lines · Wolfgang Denk
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.
Signature · 2 lines
Timur Tabi Linux Kernel Developer @ Freescale
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 ...
Quoted 3 lines
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.
Quoted 3 lines
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.
Quoted 2 lines
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?
Signature · 2 lines
Timur Tabi Linux Kernel Developer @ Freescale
Quoted 8 lines · Wolfgang Denk
Quoted 4 lines · In message <[email protected]> you wrote:
Quoted 1 line
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.
Quoted 1 line
So why making it unnecessarily complicated?
Hidden variables aren't complicated. I think the idea is elegant and useful.
Quoted 3 lines
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?
Signature · 2 lines
Timur Tabi Linux Kernel Developer @ Freescale
Quoted 10 lines · In message <[email protected]> you wrote:
Quoted 4 lines
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
Signature · 5 lines
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.
Quoted 4 lines · In message <[email protected]> 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.
Quoted 2 lines
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.
Quoted 2 lines
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.
Quoted 1 line
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.
Quoted 2 lines
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
Signature · 5 lines
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
Quoted 4 lines · In message <[email protected]> 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.
Quoted 1 line
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.
Quoted 2 lines
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
Signature · 4 lines
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.
Quoted 3 lines · Ulf Samuelsson
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
Truong
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: [email protected] [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
Quoted 2 lines · In message <[email protected]> you wrote:
Quoted 2 lines
If you don't want to break compatibility with existing systems
you
Quoted 1 line
Quoted 1 line
ill have to maintain a separate list anyway - either in the
source
Quoted 3 lines
Quoted 1 line
code, or in the environment ;-)
Well, the point behind having hidden variables is that the source code
which needs to use
Quoted 1 line
a hidden variable can just call
_do_setenv()(or whatever) and have it
set an environment
Quoted 1 line
variable that is hidden. My preference would be that any variable
that starts with a dot
Quoted 1 line
(.) is hidden. That way, the source code doesn't really need to have
a separate list. It
Quoted 1 line
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
Signature · 16 lines
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
Quoted 5 lines
-----Original Message-----
From: Wolfgang DenkQuoted 1 line
The level of hiding that you're talking about is more
extreme than the level we're talking
Quoted 1 line
about. We're just talking about not having the variable
Quoted 8 lines
show up when you do "print", so
Quoted 1 line
that it doesn't pollute the list of variables that the user
does want to interact with.
You cannot know what the user wants.
Quoted 1 line
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.