[Bug 1607] __RTEMS_SIZEOF_VOID_P__ flawed design

[bugzilla-daemon at rtems.org]

https://www.rtems.org/bugzilla/show_bug.cgi?id=1607

--- Comment #16 from Joel Sherrill <joel.sherrill at oarcorp.com> 2010-07-15 11:54:48 CDT ---
(In reply to comment #15)
> (In reply to comment #14)
> > Changing the ISR assembler code to inline assembly is not a mechanical task.
> Wrong. It is.
> 
> > With the recent changes we have to access a structure from assembly code.
> The your crappy code you have infected RTEMS with.
> 
> > I am strongly against to force the ISR code out of the Cpukit.
> Please understand that getting rid of your flawed code is not negociable and
> that I am willing to take drastic consequences.
> 
> As an initial step,  I will remove __RTEMS_SIZEOF_VOID_P__ and leave you guys
> alone with your mess, because I am tired of wiping up the mess behind you
> folks.
> Also please understand that I consider Joel deliberately having ignored the
> advice I gave him to be an hostile and violent act against me.

Ralf, I have deliberately not been hostile.  You are saying "I don't like it
and will break the entire world if you don't play by my rules." I just haven't
caved and thrown away SMP work because you don't like this one small part.
A long discussion is OK and I have been open to a workable long term solution.

If you can show the conversion of the ISR code for a port (say x86 or sparc) to
C, I am willing to take a swing at the conversion.  I don't see it as a
mechanical translation.  If you do, great.  Moving to C will be an improvement
IFF it does not negatively impact performance or understandability.

> Period - Be lucky that I am currently on vacation and don't have access to the
> source tree, otherwise I would already have done what I outlined above.

I have been on vacation also and have tried to come up with alternative
solutions.  I fail to see what is wrong with moving the code out of
the CPU Kit since it is already out of the cpukit for at least x86 and powerpc
already. We could take a consistent approach to the placement of this code for
the future.  AND generate the sizeof constant into .h file that is only present 
during the build.

This could be done (I think) in libcpu in a consistent manner across all
ports without much effort or disruption.

-- 
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.