From: Pantelis Antoniou <panto@intracom.gr>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] dynamic setting of CONFIG_SYS_CLK_FREQ
Date: Mon, 26 Apr 2004 14:32:57 +0300 [thread overview]
Message-ID: <408CF369.9050907@intracom.gr> (raw)
In-Reply-To: <20040426111307.26810C109F@atlas.denx.de>
Wolfgang Denk wrote:
>In message <408CE1D9.1080201@intracom.gr> you wrote:
>
>>We can do the same with environment variables.
>>
>>Let's partition the variables to two categories.
>>
>
>I see what you mean. But it might be not as easy.
>
>
>>One will be the normal variables as we have now.
>>The other we can refer to them as phantom variables;
>>they are never written to persistant storage but live in
>>RAM only. The version variable you refer is one of them.
>>
>>IMHO it's a more consistent interface.
>>
>
>Well, but how do you present it to the user? Will "printenv" show all
>variables mixed? So how does the user know which get saved and which
>not? How do you merge both with the standard CLI and hush in a
>consistent way? And allthis without (significantly) increasing the
>memory footprint _and_ keeping the code readable?
>
>
Well, will the user care?
Why should he know that the version or the clock variable is real?
If he tries to change a read only variable it should be denied.
If the variable is writable the action should take place immediately.
If the action should be persistent it should be saved to storage.
Since the variables are present at RAM but not in persistent storage
the size of the environment is the same. As for the code footprint
this is debatable. If someone needs this "feature" he can enable
it explicitly. If not enabled everything should work as it were.
>>As for the state of Linux, we can try to migrate 2.6 to
>>this interface.
>>
>
>Good idea.
>
>Best regards,
>
>Wolfgang Denk
>
>
Regards
Pantelis
next prev parent reply other threads:[~2004-04-26 11:32 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-22 16:02 [U-Boot-Users] dynamic setting of CONFIG_SYS_CLK_FREQ Kumar Gala
2004-04-22 17:14 ` Wolfgang Denk
2004-04-22 17:28 ` Kumar Gala
2004-04-22 19:44 ` Wolfgang Denk
2004-04-22 19:51 ` Kumar Gala
2004-04-25 14:03 ` Wolfgang Denk
2004-04-26 6:33 ` Pantelis Antoniou
2004-04-26 8:02 ` Wolfgang Denk
2004-04-26 8:16 ` Pantelis Antoniou
2004-04-26 9:14 ` Wolfgang Denk
2004-04-26 10:18 ` Pantelis Antoniou
2004-04-26 11:13 ` Wolfgang Denk
2004-04-26 11:32 ` Pantelis Antoniou [this message]
2004-04-26 13:03 ` Wolfgang Denk
2004-04-26 13:25 ` Pantelis Antoniou
2004-04-26 14:00 ` Wolfgang Denk
2004-04-22 17:58 ` Dan Malek
-- strict thread matches above, loose matches on Subject: below --
2004-04-22 17:52 VanBaren, Gerald
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=408CF369.9050907@intracom.gr \
--to=panto@intracom.gr \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox