Re: [PATCH] Add last processor to process stat

[Almudena Garcia]

> And it must set into *thread_info_count the actual amount being filled.

Ok. Then I must update this amount to the current amount of the structure (but only if It use the new header)

> Think about an old program built with the old header, running with

> the new GNU Mach.

Ok, then I have to detect if the program is using the old header or the new header. Maybe can I set a new #define to mark the new header?

> That's inconvenient so ideally it should be fixed in procfs by checking that the *thread_info_count count includes the last_processor field, and if
> not set it to 0.

This must be patched in Hurd, improving my previous patch.

El dom., 27 oct. 2019 a las 17:46, Samuel Thibault (<samuel.thibault@gnu.org>) escribió:

Samuel Thibault, le dim. 27 oct. 2019 17:39:26 +0100, a ecrit:
> Almudena Garcia, le dim. 27 oct. 2019 17:36:55 +0100, a ecrit:
> > > And as I mentioned, cope with caller passing either the old or the new
> > > value of THREAD_SCHED_INFO_COUNT in *thread_info_count
> >
> > > There, for backward compatibility with existing
> > > binaries, you have to handle both the case where the application
> > > passes the old count (built with the old GNU Mach header defining
> > > THREAD_SCHED_INFO_COUNT), and the case where the application passes the
> > > new count (built with the new header).
> >
> > I don't understand very well. Where is this? In gnumach or Hurd? 
>
> In gnumach.
>
> Really, grep is an extremely powerful tool.

Actually you had already found the place since you patched it.

I mean: thread_info() is passed a pointer to a buffer that it fills. The
caller passes the number of items of the buffer it allocated. GNU Mach
mustn't fill more than that. And it must set into *thread_info_count the
actual amount being filled.

Think about an old program built with the old header, running with
the new GNU Mach. And then conversely a program rebuilt with the new
header, running with the old GNU Mach. The first case really needs to be
fixed.  The second case is less of a concern, it'll just require people
to make sure to upgrade mach to get procfs working correctly. That's
inconvenient so ideally it should be fixed in procfs by checking that
the *thread_info_count count includes the last_processor field, and if
not set it to 0.

Samuel