Hi Wolfgang,
On 03/09/11 22:13, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message <1315048903-23217-1-git-send-email-graeme.r...@gmail.com> you
> wrote:
[snip]
I know that this patch is essentially dead given the fact that standalone
applications should not access gd directly, but a few points for future
reference....
>> The CRC is generated by:
>> - Pre-processing common.h (which includes global_data.h after all the
>> board, arch and SoC defines are set)
>> - Searches for a chunk of text delimited by 'typedef struct global_data {'
>> and '} gd_t;'
>> - Strips all blank lines and whitespaces (pre-processor already took care
>> of comments)
>> - Pipes the result through 'tools/gencrc32header/gencrc32header'
>
> Sorry, but I don't consider this an even halfway robust or reliable
> method. Minor changes to the text formatting, changes to remove for
> example the typedef, renames of fields or appending additional fields
> will all break this, while tere will actually be no problems with the
> code.
The CRC could be calculated just on the struct members, but my sed-fu is
not that good. If it was done that way, the only way the CRC would change
is by either:
1) Members being added
2) Members being removed
3) Members being moved around
4) Members type being changes(*)
5) Members being renamed
Comments and white spaces have no impact on the CRC as they are stripped.
(*)For CRC calculateion, member types are reduced to their ANSI C
equivalent unless typedef'd, so some member type changes will not trigger a
CRC change
Now apart from #5, we would want a new CRC for any of those modifications,
and how likely is #5 without some other change to gd along the way?
> THis is a level of make-believe security that is fragile, and I doubt
> if it's really useful, or needed.
Not needed as long as only core U-Boot code accessed gd
> It's a nice idea, but the problem it addresses is mostly a theoretical
> one - has anybody seen any actual bug reports that this has ever been
> a real problem?
Don't know - As I said in the commit message, this came about from idle
curiosity about the relationship between gd and XF_VERSION
As an aside, maybe we could expose gd members to standalone applications
via getenv - create psuedo environment variables that are actually tied to
gd members? But then again, I really do not know if standalone applications
*ever* use gd, but getenv may be a nice safe way of exporting gd to
standalone applications
Regards,
Graeme
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
