* [U-Boot] MAC Address reading procedure in board.c
@ 2009-05-25 15:56 Drasko DRASKOVIC
2009-05-25 18:32 ` Wolfgang Denk
0 siblings, 1 reply; 3+ messages in thread
From: Drasko DRASKOVIC @ 2009-05-25 15:56 UTC (permalink / raw
To: u-boot
Hi all,
I have been looking at MAC addr obtaining procedure in lib_arm/board.c and I
am puzzled with this implementation :
/* MAC Address */
{
int i;
ulong reg;
char *s, *e;
char tmp[64];
i = getenv_r ("ethaddr", tmp, sizeof (tmp));
s = (i > 0) ? tmp : NULL;
*for (reg = 0; reg < 6; ++reg) {
gd->bd->bi_enetaddr[reg] = s ? simple_strtoul (s, &e, 16) : 0;
if (s)
s = (*e) ? e + 1 : e;*
}
}
Here are my questions:
1) In which format is kept the addr in environment (i.e. why do we allocate
64 byte buffer tmp)? This is a little bit tricky to see from the code, so I
thought maybe somebody will know.
2) In my opinion - there should be some delimiters (maybe ':') in this eth
addr string in environment, so we are here jumping over them :*
if (s)
s = (*e) ? e + 1 : e;
*but I still cannot see - how long are these strings between delimiters?
(Because when you call simple_strtoul(), it will proceed to the first
non-digit character, so who knows how long. As long as simple_stroul() is
concerned, if it do not meet nonhexdigit char, it can go to Moon and
beyond). Why we did not took two chars to represent each of 6 bytes +
delimiters (':'), which would make 6*2 + 5 = 11, which should be the length
of the tmp buffer. Then take two-by-two chars and transform them into
number.
What am I missing here?
Thanks and best regards,
Drasko
^ permalink raw reply [flat|nested] 3+ messages in thread
* [U-Boot] MAC Address reading procedure in board.c
2009-05-25 15:56 [U-Boot] MAC Address reading procedure in board.c Drasko DRASKOVIC
@ 2009-05-25 18:32 ` Wolfgang Denk
2009-05-26 8:47 ` Drasko DRASKOVIC
0 siblings, 1 reply; 3+ messages in thread
From: Wolfgang Denk @ 2009-05-25 18:32 UTC (permalink / raw
To: u-boot
Dear Drasko DRASKOVIC,
In message <5ec3d7930905250856k6cffb4ber261bd99f15868c19@mail.gmail.com> you wrote:
>
> I have been looking at MAC addr obtaining procedure in lib_arm/board.c and I
> am puzzled with this implementation :
>
>
> /* MAC Address */
> {
> int i;
> ulong reg;
> char *s, *e;
> char tmp[64];
>
> i = getenv_r ("ethaddr", tmp, sizeof (tmp));
> s = (i > 0) ? tmp : NULL;
>
> *for (reg = 0; reg < 6; ++reg) {
> gd->bd->bi_enetaddr[reg] = s ? simple_strtoul (s, &e, 16) : 0;
> if (s)
> s = (*e) ? e + 1 : e;*
> }
> }
That must be very old code. Please update to a recent version before
trying to understand this.
> Here are my questions:
> 1) In which format is kept the addr in environment (i.e. why do we allocate
> 64 byte buffer tmp)? This is a little bit tricky to see from the code, so I
> thought maybe somebody will know.
It's stored as a string "aa:bb:cc:dd:ee:ff". 64 is sufficiently large
to catch most (acccidential) incorrect input.
> 2) In my opinion - there should be some delimiters (maybe ':') in this eth
> addr string in environment, so we are here jumping over them :*
> if (s)
> s = (*e) ? e + 1 : e;
> *but I still cannot see - how long are these strings between delimiters?
Usually these are 2 characters long, but they can be aby size. You
can write "0:1:2:3:4:5" or "0000:1:0002:2:04:000000005" as well, as
long as you don't exceed the maximum of sizeof(tmp).
> beyond). Why we did not took two chars to represent each of 6 bytes +
> delimiters (':'), which would make 6*2 + 5 = 11, which should be the length
> of the tmp buffer. Then take two-by-two chars and transform them into
> number.
> What am I missing here?
Why should we make such a restriction? Why do you want to force me to
type two characters when one may be sufficient?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Hello! I'm from outer space, and I've made myself look like a signa-
ture. While you are reading this, I'm having sex with your eyes. I
know it feels good to you, because you're smiling. I'm very horny, so
send me to someone else when you've had enough. Thanks!
Sincerely, A Stranger in a Strange Land
^ permalink raw reply [flat|nested] 3+ messages in thread
* [U-Boot] MAC Address reading procedure in board.c
2009-05-25 18:32 ` Wolfgang Denk
@ 2009-05-26 8:47 ` Drasko DRASKOVIC
0 siblings, 0 replies; 3+ messages in thread
From: Drasko DRASKOVIC @ 2009-05-26 8:47 UTC (permalink / raw
To: u-boot
Hi Wolfgang,
first of all thanks a lot for your answers.
On Mon, May 25, 2009 at 8:32 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Drasko DRASKOVIC,
>
> In message <5ec3d7930905250856k6cffb4ber261bd99f15868c19@mail.gmail.com>
> you wrote:
> >
> > I have been looking at MAC addr obtaining procedure in lib_arm/board.c
> and I
> > am puzzled with this implementation :
> >
> >
> > /* MAC Address */
> > {
> > int i;
> > ulong reg;
> > char *s, *e;
> > char tmp[64];
> >
> > i = getenv_r ("ethaddr", tmp, sizeof (tmp));
> > s = (i > 0) ? tmp : NULL;
> >
> > *for (reg = 0; reg < 6; ++reg) {
> > gd->bd->bi_enetaddr[reg] = s ? simple_strtoul (s, &e, 16) :
> 0;
> > if (s)
> > s = (*e) ? e + 1 : e;*
> > }
> > }
>
> That must be very old code. Please update to a recent version before
> trying to understand this.
>
I know that you are strongly suggesting that newes code should be used, but
sometimes it is just not my choice (although I always advocate for the newes
version).
>
> > Here are my questions:
> > 1) In which format is kept the addr in environment (i.e. why do we
> allocate
> > 64 byte buffer tmp)? This is a little bit tricky to see from the code, so
> I
> > thought maybe somebody will know.
>
> It's stored as a string "aa:bb:cc:dd:ee:ff". 64 is sufficiently large
> to catch most (acccidential) incorrect input.
Perfect! I started jumping through the tags and got lost in the see of code.
"Go to the lists...", the inner voice was telling me.
> > 2) In my opinion - there should be some delimiters (maybe ':') in this
> eth
> > addr string in environment, so we are here jumping over them :*
> > if (s)
> > s = (*e) ? e + 1 : e;
> > *but I still cannot see - how long are these strings between delimiters?
>
> Usually these are 2 characters long, but they can be aby size. You
> can write "0:1:2:3:4:5" or "0000:1:0002:2:04:000000005" as well, as
> long as you don't exceed the maximum of sizeof(tmp).
Aaah. Now I get it ;)
>
>
> > beyond). Why we did not took two chars to represent each of 6 bytes +
> > delimiters (':'), which would make 6*2 + 5 = 11, which should be the
> length
> > of the tmp buffer. Then take two-by-two chars and transform them into
> > number.
> > What am I missing here?
>
> Why should we make such a restriction? Why do you want to force me to
> type two characters when one may be sufficient?
You are absolutly right (I guess that was frustration of the moment talking
here).
>
> Best regards,
>
> Wolfgang Denk
>
Once again, thanks for your valuable answers. Perfect support - as always
;).
Best regards,
Drasko
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2009-05-26 8:47 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-05-25 15:56 [U-Boot] MAC Address reading procedure in board.c Drasko DRASKOVIC
2009-05-25 18:32 ` Wolfgang Denk
2009-05-26 8:47 ` Drasko DRASKOVIC
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.