Hello Hurd,
I made some changes to this patch:
1- I added a call to pci_system_cleanup(); in the shutdown RPC,
so libpciaccess is shutdown correctly.
2- As now we're using libpciaccess functions to read/write
from netfs_attempt_read/write, and these two libpciaccess
functions have diffe
From: Joan Lledó
* pci-arbiter/Makefile:
* Remove pci_access.c and x86_pci.c from the sources.
* pci-arbiter/func_files.c:
* config_blog_op: Call the proper i/o function.
* io_config_file: Use a harcoded PCI config size.
* read_rom_file:
Grab the fu
Hello,
Thanks for your work?
Could you try to split your changes in separate patches? Otherwise the
review is harder since the reviewer has to work out which pieces are
intended to what part of the changes, and applying the parts that look
ok while other parts are getting repolished is harder sin
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
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 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 @@
>
> 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: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
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 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.
> >
> 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 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 */
>
> 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:
> --- 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
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: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
> 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
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ó:
>
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
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
>
> 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
We are getting somewhere :)
Now please fix the indentation (tabs vs spaces) to make it match what is
already there in the file.
Samuel
Hello,
Thanks for your work! It looks in good shape, I'll do some tests and
probably commit.
General note: do not include unrelated changes. Copyright text update
belongs to separate patches. Dropping useless inclusions as well.
Anything else than what is at stake makes the review longer, so you
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
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
> 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 :)
>
Svante Signell, le jeu. 12 sept. 2019 10:23:55 +0200, a ecrit:
> @@ -358,6 +357,18 @@ routine file_reparent (
> skip;/* Was: file_get_children. */
> skip;/* Was: file_get_source. */
>
> +
> +/* Do fcntl type locking on FILE. CMD is from the set F_GETLK64,
> + F_SETLK64, F_SETL
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,
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
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
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
> 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
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
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: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
There was an issue with rlock-tweak.c, revealed by the tdb testsuite:
Index: hurd-debian/libfshelp/rlock-tweak.c
===
--- hurd-debian.orig/libfshelp/rlock-tweak.c
+++ hurd-debian/libfshelp/rlock-tweak.c
@@ -312,10 +312,8 @@ fshelp_rloc
36 matches
Mail list logo
