Re: Running out of bits p_flag (sys/sys/proc.h)

On Sun, Feb 17, 2013 at 04:25:22AM +0100, Davide Italiano wrote:
> On Sun, Feb 17, 2013 at 2:58 AM, hiren panchasara
> <hiren.panchasara_at_gmail.com> wrote:
> > With revision=246484, it seems we have hit the limit.
> > At $WORK we have one more flag and to accommodate that we need to bump this up.
> >
> > Can p_flag be bumped up to u_long?
> >
> > Index: proc.h
> > ===================================================================
> > --- proc.h      (revision 245937)
> > +++ proc.h      (working copy)
> > _at__at_ -497,7 +497,7 _at__at_
> >          * The following don't make too much sense.
> >          * See the td_ or ke_ versions of the same flags.
> >          */
> > -       int             p_flag;         /* (c) P_* flags. */
> > +       u_long          p_flag;         /* (c) P_* flags. */
> >         enum {
> >                 PRS_NEW = 0,            /* In creation */
> >                 PRS_NORMAL,             /* threads can be run. */
> >
> > Thanks,
> > Hiren
> > _______________________________________________
> > freebsd-current_at_freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
> 
> I see at least two problems here:
> - The change you propose may result in a KBI breakage.
> - sizeof(unsigned long) == 4 on some archs, e.g. my i386 Atom, which
> makes the change uneffective.

You are right. The solution is to add one more flags member, e.g.
p_flag2. They are free.

The issue I see with the approach, is with the kinfo and userspace
reporting of the flag2. I think that some uninteresting (for
usermode) flag could be moved to flag2 outright.