svn commit: r216634 - in head/sys/amd64: amd64 ia32 include linux32

[Jung-uk Kim]

On Wednesday 22 December 2010 08:03 am, John Baldwin wrote:
> On Tuesday, December 21, 2010 7:18:42 pm Jung-uk Kim wrote:
> > Author: jkim
> > Date: Wed Dec 22 00:18:42 2010
> > New Revision: 216634
> > URL: http://svn.freebsd.org/changeset/base/216634
> >
> > Log:
> >   Improve PCB flags handling and make it more robust.  Add two
> > new functions for manipulating pcb_flags.  These inline functions
> > are very similar to atomic_set_char(9) and atomic_clear_char(9)
> > but without unnecessary LOCK prefix for SMP.  Add comments about
> > the rationale[1].  Use these functions wherever possible. 
> > Although there are some places where it is not strictly necessary
> > (e.g., a PCB is copied to create a new PCB), it is done across
> > the board for sake of consistency.  Turn pcb_full_iret into a PCB
> > flag as it is safe now.  Move rarely used fields before pcb_flags
> > and reduce size of pcb_flags to one byte.  Fix some style(9) nits
> > in pcb.h while I am in the neighborhood.
> >
> >   Reviewed by:	kib
> >   Submitted by:	kib[1]
> >   MFC after:	2 months
>
> Is there really a need to have the flags field be a char instead of
> an int or long?  It seems to me that flags fields in general should
> be an int unless there is a strong need otherwise (e.g.
> hardware-defined flag).  'orl' will work just as well as 'orb'.

Actually, there was little disagreement between kib and me and 
committed version was fifth reincarnation of original patch.  I 
originally used 'u_int pcb_flags' but used byte byte opcodes for 
assembly to make it consistent with compiler generated code.  kib 
disliked the inconsistencies and told me to reconsider.  After 
several versions, I proposed we use char and move forward for now, 
then we increase the size if it ever grows more than 8 bits.  So, we 
settled.  I have no problem with int version if there is no 
measurable performance change.  I'll test it soon.

Jung-uk Kim