Dear Joe Hershberger,
In message you
wrote:
>
> So this means all aspects of the env handling would be under "env *"
> including such things as printenv and setenv? I like this so long as
> the current commands remain for compatibility.
That's what I'm doing.
> That sounds interesting. Is th
On Tue, Jun 22, 2010 at 4:18 PM, Wolfgang Denk wrote:
>> > Taking this one step further, we should then also rename "editenv"
>> > into "env edit".
>>
>> Why rename one existing command? Why not rename askenv and the rest?
>> I don't think I would rename any of them or I would have a clear
>> sep
Dear Joe Hershberger,
In message you
wrote:
>
> > Taking this one step further, we should then also rename "editenv"
> > into "env edit".
>
> Why rename one existing command? Why not rename askenv and the rest?
> I don't think I would rename any of them or I would have a clear
> separation and
On Wed, May 12, 2010 at 4:34 AM, Wolfgang Denk wrote:
>> > There has been discussion about such a feature in the past. I even
>> > tried to define the user interface for such a command set, but
>> > unfortunately I didn't have enough time myself and nobody else took
>> > the bait either.
>>
>> Ok.
Dear Joe Hershberger,
In message you
wrote:
>
> >> I ran into the same situation, where I needed set of environment
> >> variables for in house testing, and a different set for when products
> >> actually go out to customers. So we were erasing the flash quite often,
> >> but in this scenario, t
On Tue, May 11, 2010 at 5:03 PM, Wolfgang Denk wrote:
> In message <67bfaf42e016fc40ade4ee73e07b706004668...@pks5.kanatek.com>
> you wrote:
>> I ran into the same situation, where I needed set of environment
>> variables for in house testing, and a different set for when products
>> actually
Dear "Craig Millen",
In message <67bfaf42e016fc40ade4ee73e07b706004668...@pks5.kanatek.com> you
wrote:
> I ran into the same situation, where I needed set of environment
> variables for in house testing, and a different set for when products
> actually go out to customers. So we were erasing
e necessary if you would like.
-Original Message-
From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On
Behalf Of Joe Hershberger
Sent: Monday, May 10, 2010 5:34 PM
To: Wolfgang Denk
Cc: u-boot
Subject: Re: [U-Boot] Read-only env variables
On Mon, May 10, 2010 at 3:43 PM
On Mon, May 10, 2010 at 3:43 PM, Wolfgang Denk wrote:
>> l - list delimited by ';' (special behavior for setenv)
>
> Don't do this. ';' has a clear meaning. Using it for other purposes
Fair enough... ',' then.
>> That seems pretty reasonable. I think I'd like to see the access
>> control
Dear Joe Hershberger,
In message you
wrote:
> On Mon, May 10, 2010 at 1:56 AM, Wolfgang Denk wrote:
> > Well, we could go for a simple type scheme, something like
> >
> >d - decimal number
> >i - IP address
> >m - mac address
> >s - string
> >x - hex numb
On Mon, May 10, 2010 at 1:56 AM, Wolfgang Denk wrote:
> Well, we could go for a simple type scheme, something like
>
> d - decimal number
> i - IP address
> m - mac address
> s - string
> x - hex number
> ...
l - list delimited by ';' (special beha
Dear Joe Hershberger,
In message you
wrote:
>
> > You might also go one step further and define variable types -
> > numeric, string, MAC addr, IP addr, ...
> >
> I'm guessing the reason for this being that the value can be validated on
> set instead of on use? I can see some interactive usabil
On Thu, May 6, 2010 at 4:58 PM, Wolfgang Denk wrote:
>
> You might also go one step further and define variable types -
> numeric, string, MAC addr, IP addr, ...
>
I'm guessing the reason for this being that the value can be validated on
set instead of on use? I can see some interactive usabilit
Dear Joe Hershberger,
In message you
wrote:
>
> I see u-boot supports readonly serial# and ethaddr, but I have a few
> other variables that I need to be read-only. I'm planning to
> implement a generic list of variables that cannot be changed or
> deleted.
Good idea, and thanks in advance!
>
Hi u-boot,
I see u-boot supports readonly serial# and ethaddr, but I have a few
other variables that I need to be read-only. I'm planning to
implement a generic list of variables that cannot be changed or
deleted.
I'm interested to know what sort of specification people would find
most appropria
15 matches
Mail list logo