On Monday 16 February 2009 18:13:25 Wolfgang Denk wrote: > In message Mike Frysinger wrote: > > > And even renaming is BAD as it breaks compatibility with the Linux > > > kernel. It's bad enough that we have a binary data structure as a > > > critical interface, but suing different variable names for the same > > > fields would make it definitely worse. > > > > that doesnt make any sense at all. the kernel isnt passed the structure > > as seen in the C language, it gets passed a binary blob. how the kernel > > chooses to interpret it is up to the kernel. > > And how do you check for problems? At least initially by comparing > the source code. Why making this more difficult than necessary?
yes, comparing the linux source and the u-boot source would be marginally more difficult. but as you've highlighted many times, no new code should be using these fields, so the likely hood of people having to do that is pretty low imo. the flip side of what i wrote to Scott is that people are actively porting code from older u-boot versions (how often do we see people saying that using u-boot-<some old version> isnt working) and if the field isnt renamed, things will appear to "just work". so there is no way for them to know that they need to fix their code which means they wont. otherwise, people hitting a build failure will know immediately that they need to update something. again, generally i could care less because this is ppc code, but considering how many abusers we've had in common network drivers, people testing drivers on ppc will not notice this issue and instead, it'll make every other arch maintainers' life annoying. perhaps if u-boot looked at importing and extending the check patch script from the kernel, then i would worry a lot less as we could make usage of this field a failure. -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
