> 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.thiba...@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 > >
