public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
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

  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