I found a error in compilation. I add new patch to fix It. I'm sorry :-(
El jue., 31 oct. 2019 a las 1:59, Samuel Thibault ()
escribió:
> Almudena Garcia, le jeu. 31 oct. 2019 01:50:04 +0100, a ecrit:
> > Sent patch
>
> Applied, thanks!
>
> Samuel
>
Author: Almudena García Jurado-Centurión
Date:
Almudena Garcia, le jeu. 31 oct. 2019 01:50:04 +0100, a ecrit:
> Sent patch
Applied, thanks!
Samuel
Sent patch
El mar., 29 oct. 2019 a las 0:05, Almudena Garcia (<
liberamenso10...@gmail.com>) escribió:
> Fixed
>
> El lun., 28 oct. 2019 a las 23:54, Samuel Thibault (<
> samuel.thiba...@gnu.org>) escribió:
>
>> Almudena Garcia, le lun. 28 oct. 2019 20:16:33 +0100, a ecrit:
>> > + /* if the
Almudena Garcia, le lun. 28 oct. 2019 20:16:33 +0100, a ecrit:
> + /* if the structure read doesn't include last_processor field, set It
> to 0 */
> + if(thcount >= THREAD_SCHED_INFO_COUNT){
> + thds[i]->last_processor = 0;
> + }
That'd rather be if(thcount < THREA
Fixed
El lun., 28 oct. 2019 a las 23:54, Samuel Thibault ()
escribió:
> Almudena Garcia, le lun. 28 oct. 2019 20:16:33 +0100, a ecrit:
> > + /* if the structure read doesn't include last_processor field,
> set It to 0 */
> > + if(thcount >= THREAD_SCHED_INFO_COUNT){
> > +
Sent patch
El lun., 28 oct. 2019 a las 19:46, Almudena Garcia (<
liberamenso10...@gmail.com>) escribió:
> Something as this?
>
> El lun., 28 oct. 2019 a las 19:24, Samuel Thibault (<
> samuel.thiba...@gnu.org>) escribió:
>
>> Almudena Garcia, le lun. 28 oct. 2019 19:16:28 +0100, a ecrit:
>> > > A
> As I said, look for the thread_info() calls, to fill the field if the
> returned count doesn't include it.
*process_file_gc_stat()*, the function which write the *stat *structure,
doesn't calls to *thread_info()*.
So I can't compare with **thread_info_counter()*, because this doesn't
exists in t
Something as this?
El lun., 28 oct. 2019 a las 19:24, Samuel Thibault ()
escribió:
> Almudena Garcia, le lun. 28 oct. 2019 19:16:28 +0100, a ecrit:
> > > As I said, look for the thread_info() calls, to fill the field if the
> > > returned count doesn't include it.
> >
> > process_file_gc_stat(),
Almudena Garcia, le lun. 28 oct. 2019 19:16:28 +0100, a ecrit:
> > As I said, look for the thread_info() calls, to fill the field if the
> > returned count doesn't include it.
>
> process_file_gc_stat(), the function which write the stat structure, doesn't
> calls to thread_info().
Indeed, it get
Almudena Garcia, le dim. 27 oct. 2019 23:34:40 +0100, a ecrit:
> Now I have to continue working in Hurd patch. I don't know how to add backward
> compatibility in this
As I said, look for the thread_info() calls, to fill the field if the
returned count doesn't include it.
Samuel
Thanks yours!! :-)
Now I have to continue working in Hurd patch. I don't know how to add
backward compatibility in this
El dom., 27 oct. 2019 a las 23:15, Samuel Thibault ()
escribió:
> Almudena Garcia, le dim. 27 oct. 2019 23:03:45 +0100, a ecrit:
> > > Now you need to write a changelog. See gi
Almudena Garcia, le dim. 27 oct. 2019 23:03:45 +0100, a ecrit:
> > Now you need to write a changelog. See git log for instances: some
> > description at the top (can be just a one-liner), then the description
> > of the _source code changes_.
>
> Attached changelog
Applied, thanks!
Samuel
> Now you need to write a changelog. See git log for instances: some
> description at the top (can be just a one-liner), then the description
> of the _source code changes_.
Attached changelog
El dom., 27 oct. 2019 a las 21:00, Samuel Thibault ()
escribió:
> Almudena Garcia, le dim. 27 oct. 2019
fixed
El dom., 27 oct. 2019 a las 21:49, Samuel Thibault ()
escribió:
> Almudena Garcia, le dim. 27 oct. 2019 21:09:22 +0100, a ecrit:
> > Attached Hurd patch (without guards)
>
> It's still taking it from thbi, it should be thsi :)
>
> Samuel
>
>
--- hurd/procfs/process.c 2019-10-26 23:12:40.495
Almudena Garcia, le dim. 27 oct. 2019 21:09:22 +0100, a ecrit:
> Attached Hurd patch (without guards)
It's still taking it from thbi, it should be thsi :)
Samuel
Almudena Garcia, le dim. 27 oct. 2019 21:03:38 +0100, a ecrit:
> > Ok, that looks good :)
> Don't we need to patch Hurd with the new field?
Sure, but they can be handled separately. Precisely because they both
support backward compatibility.
Samuel
Attached Hurd patch (without guards)
El dom., 27 oct. 2019 a las 21:03, Almudena Garcia (<
liberamenso10...@gmail.com>) escribió:
> > Ok, that looks good :)
> Don't we need to patch Hurd with the new field?
> My previous Hurd patch is not good, I remember
>
>
> El dom., 27 oct. 2019 a las 21:00,
> Ok, that looks good :)
Don't we need to patch Hurd with the new field?
My previous Hurd patch is not good, I remember
El dom., 27 oct. 2019 a las 21:00, Samuel Thibault ()
escribió:
> Almudena Garcia, le dim. 27 oct. 2019 20:53:30 +0100, a ecrit:
> > Improved tabs.
>
> Ok, that looks good :)
>
Almudena Garcia, le dim. 27 oct. 2019 20:53:30 +0100, a ecrit:
> Improved tabs.
Ok, that looks good :)
Now you need to write a changelog. See git log for instances: some
description at the top (can be just a one-liner), then the description
of the _source code changes_.
Now, I'm realizing that y
Improved tabs.
El dom., 27 oct. 2019 a las 20:40, Samuel Thibault ()
escribió:
> We are getting somewhere :)
>
> Now please fix the indentation (tabs vs spaces) to make it match what is
> already there in the file.
>
> Samuel
>
--- gnumach/include/mach/thread_info.h 2019-09-03 01:22:10.920747802
We are getting somewhere :)
Now please fix the indentation (tabs vs spaces) to make it match what is
already there in the file.
Samuel
>
> You'd rather use 8 here, so that if somebody else adds yet another
> field things work correctly. Actually, looking at what is done for
> THREAD_BASIC_INFO, there is no check there. AIUI that's because the
> output message is allocated by the caller to the largest RPC size, so we
> can just fil
Almudena Garcia, le dim. 27 oct. 2019 20:20:49 +0100, a ecrit:
> + if(sizeof(thsi) >= THREAD_SCHED_INFO_COUNT){
No, that'll again only do a compile-time check: sizeof(thsi) will just
return the size of the structure, which is actually also what
THREAD_SCHED_INFO_COUNT is based on!
(and THREAD_SCH
Almudena Garcia, le dim. 27 oct. 2019 20:13:40 +0100, a ecrit:
> > Please really add it to thread_sched_info_t.
>
> Fixed. Now working in Hurd patch
> --- gnumach/kern/thread.c 2019-09-03 01:22:10.932747830 +0200
> +++ GNUMach_SMP/kern/thread.c 2019-10-27 20:09:10.515836242 +0100
> @@ -1609
Attached Hurd patch
El dom., 27 oct. 2019 a las 20:13, Almudena Garcia (<
liberamenso10...@gmail.com>) escribió:
> > Please really add it to thread_sched_info_t.
>
> Fixed. Now working in Hurd patch
>
> El dom., 27 oct. 2019 a las 19:56, Samuel Thibault (<
> samuel.thiba...@gnu.org>) escribió:
>
> Please really add it to thread_sched_info_t.
Fixed. Now working in Hurd patch
El dom., 27 oct. 2019 a las 19:56, Samuel Thibault ()
escribió:
> Almudena Garcia, le dim. 27 oct. 2019 19:44:23 +0100, a ecrit:
> > > + #if THREAD_BASIC_INFO_COUNT > 10
> >
> > That will be always true. What
Almudena Garcia, le dim. 27 oct. 2019 19:44:23 +0100, a ecrit:
> > + #if THREAD_BASIC_INFO_COUNT > 10
>
> That will be always true. What you want to check is *thread_info_count.
>
> --- gnumach/kern/thread.c 2019-09-03 01:22:10.932747830 +0200
> +++ GNUMach_SMP/kern/thread.c 2019-10-2
Attached new patch
El dom., 27 oct. 2019 a las 19:17, Samuel Thibault ()
escribió:
> Almudena Garcia, le dim. 27 oct. 2019 19:09:17 +0100, a ecrit:
> > --- gnumach/kern/thread.c 2019-09-03 01:22:10.932747830 +0200
> > +++ GNUMach_SMP/kern/thread.c 2019-10-27 19:00:17.577010318 +0100
> > @@ -1530,
Almudena Garcia, le dim. 27 oct. 2019 19:09:17 +0100, a ecrit:
> --- gnumach/kern/thread.c 2019-09-03 01:22:10.932747830 +0200
> +++ GNUMach_SMP/kern/thread.c 2019-10-27 19:00:17.577010318 +0100
> @@ -1530,6 +1530,16 @@
> read_time_stamp(&thread->creation_time,
> &basic_info->creation_tim
> That comes directly from the count it passes.
--- gnumach/kern/thread.c 2019-09-03 01:22:10.932747830 +0200
+++ GNUMach_SMP/kern/thread.c 2019-10-27 19:00:17.577010318 +0100
@@ -1530,6 +1530,16 @@
read_time_stamp(&thread->creation_time,
&basic_info->creation_time);
+ #if THREAD_BASIC
Almudena Garcia, le dim. 27 oct. 2019 19:09:17 +0100, a ecrit:
> --- hurd/procfs/process.c 2019-10-26 23:12:40.495359917 +0200
> +++ hurd~/procfs/process.c2019-10-27 19:06:33.648773329 +0100
> @@ -286,7 +286,11 @@
>(long unsigned) proc_stat_thread_rpc (ps), /* close enough */
>
> 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 dete
Almudena Garcia, le dim. 27 oct. 2019 18:18:46 +0100, a ecrit:
> > 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.
That comes directly from the count it passes.
> >
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 co
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
> 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
Almudena Garcia, le dim. 27 oct. 2019 17:17:52 +0100, a ecrit:
> Oops, I forgot the patch where I fill this field. I attach It now
> --- gnumach/kern/thread.c 2019-09-03 01:22:10.932747830 +0200
> +++ GNUMach_SMP/kern/thread.c 2019-10-27 17:14:32.851265452 +0100
> @@ -1530,6 +1530,10 @@
>
Oops, I forgot the patch where I fill this field. I attach It now
El dom., 27 oct. 2019 a las 16:44, Samuel Thibault ()
escribió:
> Almudena Garcia, le sam. 26 oct. 2019 23:38:56 +0200, a ecrit:
> > These patches isn't tested yet.
>
> They will surely not work, since you didn't put anything in th
Almudena Garcia, le sam. 26 oct. 2019 23:38:56 +0200, a ecrit:
> These patches isn't tested yet.
They will surely not work, since you didn't put anything in that new
field inside GNU Mach :)
See the function that fills it in GNU Mach: thread_info()'s
THREAD_SCHED_INFO case. There, for backward co
These patches add the last processor used by a thread.
The first patch add the field to the *thread_basic_info *structure in
gnumach
The second patch replace the *processor *value (previously hardcoded to 0)
in *stat *structure with the real value stored in *thbi . *This patch must
be applied over
40 matches
Mail list logo
