Hi Mike,
>> Um actually, caring that a project stears clean of copyright violations
>
> copyright violations != licensing violations
Yes of course, you are right here.
>> that may later be used to take down the whole project has got zero to do
>> with subscribing to "the FSF mentatlity". Thinking about it, it doesn't
>> even make sense to me that you express your distaste of the FSF from
>> such a non-correlated topic.
>
> i dont think people really care what my opinion is on the matter and it is
> certainly off topic on this list
Indeed, why did you bring it up then?
>> As I did not follow this discussion, can you enlighten me to what the
>> *actual* positive effect of defines like the following is (random pick)?
>>
>> #define pVR_CTL ((uint16_t volatile *)VR_CTL) /*
>> Voltage Regulator Control Register (16-bit) */ #define bfin_read_VR_CTL()
>> bfin_read16(VR_CTL)
>> #define bfin_write_VR_CTL(val) bfin_write16(VR_CTL, val)
>>
>> To me (as a simple code reader), this will ultimately only make the end
>> c code harder to read. As it does not contain all the details any more
>> I potentially have to lookup every single define if I want to understand
>> what is going on.
>>
>> Thinking hard, I cannot see a positive result. At first I thought you
>> may hide the actual data sizes in this define layer (disregarding the
>> fact whether this is a good or bad thing to do), but this is not the
>> case, as the types will permeate the layer. So can you please tell me
>> what positive effects this is supposed to have?
>
> the data sizes are hidden from the developer (in so much that they dont need
> to worry about it in the important cases),
Even if I don't like hiding data sizes at such a place, I cannot follow
your argument. If you have correct typing on the called functions,
surely these types are in no way encapsulated by these shim-macros.
> we use functions to read/write values rather than pointers (which is
> common convention) and really is easier to read/manage), people dont
> have to look up random addresses in the HRM for their particular
> variant, etc...
I also cannot follow this. The macro substitution uses a symbolic
constant named exactly like the macro. What _exactly_ is that giving
you?
To be honest, as far as I can see, all other architectures get by
without such "macros" without loosing anything and the arguments you
gave this far did not convince me that they are needed.
I do not even want to think about e.g. the 4xx maintainers coming up
with one macro per soc register...
Cheers
Detlev
--
It's like manually inflatable airbags -- people will never
think to use it in time to actually get any help from it.
-- Miles Bader in <[EMAIL PROTECTED]>
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
