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