[Bug 1910] An option for architecture-specific SMP locks
bugzilla-daemon at rtems.org
bugzilla-daemon at rtems.org
Fri Oct 28 14:19:49 UTC 2011
https://www.rtems.org/bugzilla/show_bug.cgi?id=1910
--- Comment #1 from Joel Sherrill <joel.sherrill at oarcorp.com> 2011-10-28 09:19:49 CDT ---
I think this is the first patch to knock out. So let's focus on this one
first.
I can see needing this for conceptual reasons. But I have a few concerns:
+ Simple: Fix the spacing in the i386 cpu file. There are some extraneous
blank lines.
+ The CPU ports are not allowed to redefine score types. They can define
base types and helper methods. The bitfield implementation is probably
the simplest to see this in action on. But it just redefines the
CPU helper methods and types for the most part. We probably need to
be more flexible about which classes of operations a CPU supports. See
below.
+ Redefining the entire SMP_lock_spinlock_nested_Control seems heavy handed
and breaks the bookkeeping. If this is just about compare and swap, then
it seems that a single CPU dependent lock field is all we are talking
about. That is the SMP_lock_spinlock_nested_Control type.
typedef struct {
SMP_lock_spinlock_simple_Control lock;
uint32_t count;
int cpu_id;
} SMP_lock_spinlock_nested_Control;
The count and and cpu_id of the holding CPU should still be valid independent
of the locking method. Right now, that is a uint32_t.
typedef uint32_t SMP_lock_spinlock_simple_Control;
So it should be simple to have that be based upon a CPU type and
then the CPU may or may not define helpers that implement the middle
of the _SMP_lock_spinlock_simple_XXX methods.
I think generic option A is "CPU has cmp/swap". Your CPU must have
option B. There is not an infinite set of types of instructions to
implement for this type of atomic operation. Can we generalize your
option B to have a name so another CPU with that operation just
defines the low level instructions. The score/src/smplock.c simple
lock code then just has CPU has option A, option B, etc.
Since we don't know what type of instruction you have, we may be
proposing the wrong solution. So you need to tell us what type of
instruction we are working with.
Generally speaking, RTEMS porting is very fine-grained. So reimplementing
an entire score method or structure that has generic information has to
be justified.
Two things documentation wise.
+ There is a CPU architecture porting guide. These new options need to be
discussed there. When porting to an architecture or adding SMP to an existing
architecture, you would need the rationale and helpful hints added here.
--
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
More information about the bugs
mailing list