From mboxrd@z Thu Jan 1 00:00:00 1970 From: Detlev Zundel Date: Wed, 04 Jun 2008 19:36:09 +0200 Subject: [U-Boot-Users] [PATCH/review] Blackfin: add support for BF538/BF539 In-Reply-To: <200806040618.27408.vapier@gentoo.org> (Mike Frysinger's message of "Wed, 4 Jun 2008 06:18:26 -0400") References: <20080601220555.04F222430A@gemini.denx.de> <200806011903.42442.vapier@gentoo.org> <200806040618.27408.vapier@gentoo.org> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 <20030607122005.GA1086@gnu.org> -- 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: dzu at denx.de