Re: [PATCH] Make task_info.h structs more portable

[Samuel Thibault]

Flavio Cruz, le jeu. 01 déc. 2022 00:10:19 -0500, a ecrit:
> On Wed, Nov 30, 2022 at 10:21:28PM +0100, Samuel Thibault wrote:
> > Flavio Cruz, le mer. 30 nov. 2022 02:10:16 -0500, a ecrit:
> > >  @table @code
> > > -@item natural_t faults
> > > +@item unsigned int faults
> > >  number of page faults
> > > 
> > > -@item natural_t zero_fills
> > > +@item unsigned int zero_fills
> > >  number of zero fill pages
> > > 
> > > -@item natural_t reactivations
> > > +@item unsigned int reactivations
> > >  number of reactivated pages
> > > 
> > > -@item natural_t pageins
> > > +@item unsigned int pageins
> > >  number of actual pageins
> > > 
> > > -@item natural_t cow_faults
> > > +@item unsigned int cow_faults
> > >  number of copy-on-write faults
> > > 
> > > -@item natural_t messages_sent
> > > +@item unsigned int messages_sent
> > >  number of messages sent
> > > 
> > > -@item natural_t messages_received
> > > +@item unsigned int messages_received
> > 
> > It would be more convenient for these to be 64bit on 64bit systems?
> > 
> > Of course 64bit can overflow as well, but at least it makes it easy to
> > write simple programs to get it and have very little probability of
> > overflowing.
> 
> I think that should fine. Would it be ok to define a new type called
> rpc_unsigned_long to define those counters? It would be 32 bits or 64 bits
> long depending on the userland.

Mmm, I'm not sure about the name.

natural_t and integer_t were supposed to be "the size of a register",
and castable to a pointer. It seems that xnu dropped the pointer part,
just like you seem to imply here, i.e. natural_t and integer_t would
remain "just an integer that's not too small".

It seems they kept events_info using integer_t rather than a large
number. But I'd still rather upgrade to 64bit. I'd also say we'd rather
keep coherent with the historical natural/integer names.

I would thus say we could go with long_natural_t and long_integer_t,
and be very explicit about the status of natural/integer_t and
long_natural/integer_t, something like:

- natural/integer_t are integer types which are reasonably small, making
  them suitable for most counters, while possibly be subject to
  overflows.

- long_natural/integer_t are integer types which are possibly larger than
  natural/integer, whenever the processor supports it, making them less
  subject to overflows.

And explicit that all of these types are not related to the size of
pointers, offsets, sizes.

Samuel