On Sun, Feb 17, 2013 at 04:25:22AM +0100, Davide Italiano wrote: > On Sun, Feb 17, 2013 at 2:58 AM, hiren panchasara > <[email protected]> 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) > > @@ -497,7 +497,7 @@ > > * 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 > > _______________________________________________ > > [email protected] mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "[email protected]" > > 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.
pgpW9urOqxPNr.pgp
Description: PGP signature
