Zhaoming Luo, le sam. 03 mai 2025 21:28:08 +0800, a ecrit:
> Use 64bit mapped time values in maptime_read when the kernel and the
> mapped_time_value structure in header file time_value.h support it.
> Otherwise step back to use the 32bit time.
Applied, thanks!
Samuel
> ---
> configure.ac
Use 64bit mapped time values in maptime_read when the kernel and the
mapped_time_value structure in header file time_value.h support it.
Otherwise step back to use the 32bit time.
---
configure.ac| 3 +++
libshouldbeinlibc/maptime.h | 16
2 files changed, 19 inse
Hello,
Zhaoming Luo, le sam. 03 mai 2025 12:49:56 +0800, a ecrit:
> Use 64bit mapped time values in maptime_read when possible. The 64bit
> time values in mapped time will be zero when the kernel does not support
> 64bit mapped time.
> + if (mtime->time_value.seconds == 0)
Please add
AC_CHECK_
Use 64bit mapped time values in maptime_read when possible. The 64bit
time values in mapped time will be zero when the kernel does not support
64bit mapped time.
---
libshouldbeinlibc/maptime.h | 27 +--
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/libsho
Zhaoming Luo, le sam. 03 mai 2025 08:30:10 +0800, a ecrit:
> On Sat, May 03, 2025 at 02:21:31AM +0200, Samuel Thibault wrote:
> > Zhaoming Luo, le sam. 03 mai 2025 08:17:52 +0800, a ecrit:
> > > On Sat, May 03, 2025 at 02:10:12AM +0200, Samuel Thibault wrote:
> > > > Zhaoming Luo, le ven. 02 mai 20
On Sat, May 03, 2025 at 02:21:31AM +0200, Samuel Thibault wrote:
> Zhaoming Luo, le sam. 03 mai 2025 08:17:52 +0800, a ecrit:
> > On Sat, May 03, 2025 at 02:10:12AM +0200, Samuel Thibault wrote:
> > > Zhaoming Luo, le ven. 02 mai 2025 22:45:44 +0800, a ecrit:
> > > > Get the time with higher resolu
Zhaoming Luo, le sam. 03 mai 2025 08:17:52 +0800, a ecrit:
> On Sat, May 03, 2025 at 02:10:12AM +0200, Samuel Thibault wrote:
> > Zhaoming Luo, le ven. 02 mai 2025 22:45:44 +0800, a ecrit:
> > > Get the time with higher resolution from kernel using host_get_time64()
> > > when possible.
> >
> > It
On Sat, May 03, 2025 at 02:10:12AM +0200, Samuel Thibault wrote:
> Zhaoming Luo, le ven. 02 mai 2025 22:45:44 +0800, a ecrit:
> > Get the time with higher resolution from kernel using host_get_time64()
> > when possible.
>
> It seems there's a misunderstanding. I explained that the mapped time
> d
Zhaoming Luo, le ven. 02 mai 2025 22:45:44 +0800, a ecrit:
> Get the time with higher resolution from kernel using host_get_time64()
> when possible.
It seems there's a misunderstanding. I explained that the mapped time
does have 64bit precision fields, that's what I mean we want to use,
rather th
Get the time with higher resolution from kernel using host_get_time64()
when possible.
---
libdiskfs/node-times.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/libdiskfs/node-times.c b/libdiskfs/node-times.c
index 60eabc0f..203232da 100644
--- a/li
Zhaoming Luo, le ven. 02 mai 2025 18:52:49 +0800, a ecrit:
> I'm wondering if I should consider the case that host_get_time64() is not
> supported
Yes, please.
I wonder how many times I will have to repeat it: backward compatibility
is really important, otherwise people can't try to downgrade ker
From: zhm
I'm wondering if I should consider the case that host_get_time64() is not
supported and go back to use maptime_read().
zhm (1):
libdiskfs: Get the time with higher resolution from kernel
libdiskfs/node-times.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-
From: zhm
Get the time with higher resolution from kernel.
---
libdiskfs/node-times.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/libdiskfs/node-times.c b/libdiskfs/node-times.c
index 60eabc0f..dab193c6 100644
--- a/libdiskfs/node-times.c
+++ b/libdis
Zhaoming Luo, le jeu. 01 mai 2025 18:13:46 +0800, a ecrit:
> We can have better resolution now so this comment can be removed.
Applied, thanks!
Samuel
> ---
> include/mach/time_value.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/mach/time_value.h b/include/
We can have better resolution now so this comment can be removed.
---
include/mach/time_value.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/mach/time_value.h b/include/mach/time_value.h
index 8274197d..9c660e7e 100644
--- a/include/mach/time_value.h
+++ b/include/m
Hello,
So it works as your additional test shows, but it is fragile.
Luca Dariz, le mer. 19 mars 2025 18:11:18 +0100, a ecrit:
> diff --git a/sysdeps/mach/hurd/i386/sigreturn.c
> b/sysdeps/mach/hurd/i386/sigreturn.c
> index ce8df8d02b..618cb74196 100644
> --- a/sysdeps/mach/hurd/i386/sigreturn.c
Hello
I fixed these and pushed it, thanks so much!
Samuel
Samuel Thibault, le ven. 11 avril 2025 02:27:04 +0200, a ecrit:
> Hello,
>
> Sorry it took me long to manage to fine time to look at this...
>
> Luca Dariz, le mer. 19 mars 2025 18:11:18 +0100, a ecrit:
> > diff --git a/sysdeps/mach/hur
Samuel Thibault, le jeu. 17 avril 2025 23:31:50 +0200, a ecrit:
> Zhaoming Luo, le lun. 10 mars 2025 16:44:09 +0800, a ecrit:
> > I haven't tested this patch again some stress tests as I don't know why
> > the `dpkg-buildpackage -B` on my qemu got stuck at:
> >
Hello,
Zhaoming Luo, le lun. 10 mars 2025 16:44:09 +0800, a ecrit:
> I haven't tested this patch again some stress tests as I don't know why
> the `dpkg-buildpackage -B` on my qemu got stuck at:
>
> ```
> ...
> ../scripts/evaluate-test.sh stdio-common/scanf14 $? fal
Hello,
Sorry it took me long to manage to fine time to look at this...
Luca Dariz, le mer. 19 mars 2025 18:11:18 +0100, a ecrit:
> diff --git a/sysdeps/mach/hurd/i386/sigreturn.c
> b/sysdeps/mach/hurd/i386/sigreturn.c
> index ce8df8d02b..618cb74196 100644
> --- a/sysdeps/mach/hurd/i386/sigreturn
Zhaoming Luo, le jeu. 10 avril 2025 20:20:26 +0800, a ecrit:
> The option -M q35 is needed when trying rumpdisk in qemu
It would be useful to track down why, and fix the issue :)
Samuel
> ---
> hurd/rump/rumpdisk.mdwn | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/hurd/rump/
The option -M q35 is needed when trying rumpdisk in qemu
---
hurd/rump/rumpdisk.mdwn | 9 +
1 file changed, 9 insertions(+)
diff --git a/hurd/rump/rumpdisk.mdwn b/hurd/rump/rumpdisk.mdwn
index 33e37ff7..cd7d77e1 100644
--- a/hurd/rump/rumpdisk.mdwn
+++ b/hurd/rump/rumpdisk.mdwn
@@ -59,4
Applied, thanks!
Zhaoming Luo, le jeu. 10 avril 2025 08:55:49 +0800, a ecrit:
> ---
> hurd/running/debian/qemu_image.mdwn | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hurd/running/debian/qemu_image.mdwn
> b/hurd/running/debian/qemu_image.mdwn
> index 9984ac33..8409bc
---
hurd/running/debian/qemu_image.mdwn | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hurd/running/debian/qemu_image.mdwn
b/hurd/running/debian/qemu_image.mdwn
index 9984ac33..8409bc8c 100644
--- a/hurd/running/debian/qemu_image.mdwn
+++ b/hurd/running/debian/qemu_image.mdwn
Applied, thanks!
Etienne Brateau, le lun. 07 avril 2025 22:11:26 +0200, a ecrit:
> ---
> i386/i386/trap.c| 4 ++--
> i386/intel/pmap.c | 4 ++--
> i386/intel/read_fault.c | 2 +-
> 3 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/i386/i386/trap.c b/i386/i386/trap.c
---
i386/i386/trap.c| 4 ++--
i386/intel/pmap.c | 4 ++--
i386/intel/read_fault.c | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/i386/i386/trap.c b/i386/i386/trap.c
index a9d0d8d2..90650b31 100644
--- a/i386/i386/trap.c
+++ b/i386/i386/trap.c
@@ -236,7 +236,7
Zhaoming Luo, le jeu. 03 avril 2025 12:42:19 +0800, a ecrit:
> This is done.
Applied, thanks!
> ---
> contributing.mdwn | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/contributing.mdwn b/contributing.mdwn
> index d79388ab..c9ce3c6a 100644
> --- a/contributing.mdwn
> +++ b/contributing.
oup::
TESTDONE: 1642 tests out of 1642 reported OK: 100%
```
An issue I can see is some tests output a whole bunch of
'deallocating bogus port', though it does not cause any test failed. I
have reported this issue and prepared a patch[1], now I'm just waiting for
the glibc 2.41-6 (or la
This is done.
---
contributing.mdwn | 1 -
1 file changed, 1 deletion(-)
diff --git a/contributing.mdwn b/contributing.mdwn
index d79388ab..c9ce3c6a 100644
--- a/contributing.mdwn
+++ b/contributing.mdwn
@@ -190,7 +190,6 @@ This is the list of tasks that we *want* to address soon,
starting with
Applied, thanks!
Zhaoming Luo, le mer. 02 avril 2025 17:23:54 +0800, a ecrit:
> ---
> hurd/io.defs | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hurd/io.defs b/hurd/io.defs
> index 5bc399ed..4c63de36 100644
> --- a/hurd/io.defs
> +++ b/hurd/io.defs
> @@ -46,7 +46,7 @@
---
hurd/io.defs | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hurd/io.defs b/hurd/io.defs
index 5bc399ed..4c63de36 100644
--- a/hurd/io.defs
+++ b/hurd/io.defs
@@ -46,7 +46,7 @@ routine io_write (
offset: loff_t;
out amount: vm_size_t);
-/* Read data from a
Applied, thanks!
Zhaoming Luo, le mer. 26 mars 2025 12:06:08 +0800, a ecrit:
> This is done.
> See:
> https://git.savannah.gnu.org/cgit/hurd/gnumach.git/commit/?id=6d91c78f0c240e3c7d81e19e85507e0aec580d6f
>
> ---
> contributing.mdwn | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/contri
This is done.
See:
https://git.savannah.gnu.org/cgit/hurd/gnumach.git/commit/?id=6d91c78f0c240e3c7d81e19e85507e0aec580d6f
---
contributing.mdwn | 1 -
1 file changed, 1 deletion(-)
diff --git a/contributing.mdwn b/contributing.mdwn
index ec98019a..d79388ab 100644
--- a/contributing.mdwn
+++ b/co
Applied, thanks!
Zhaoming Luo, le lun. 24 mars 2025 12:25:51 +0800, a ecrit:
> Integrate HPET so host_get_time, host_get_time64, and host_get_uptime64
> are more precise. The highest precision can be 10ns when this patch is
> applied.
>
> * i386/i386/apic.c: Implement the two
Applied, thanks!
Zhaoming Luo, le lun. 24 mars 2025 13:20:42 +0800, a ecrit:
> Check the availability of host_get_time64 and use it to replace
> host_get_time for CLOCK_REALTIME when it's available. Fall back to
> host_get_time if gnumach does not support host_get_time64 but the
> gnumach headers
Check the availability of host_get_time64 and use it to replace
host_get_time for CLOCK_REALTIME when it's available. Fall back to
host_get_time if gnumach does not support host_get_time64 but the
gnumach headers do.
host_get_time is deprecated
See
https://git.savannah.gnu.org/cgit/hurd/gnumach.g
Compared with RFC v3:
- Use #ifdef APIC in hpclock_read_counter() to avoid the runtime check
of the availability of HPET.
- Remove the redundant check in hpclock_get_counter_period_nsec().
- Fix a small bug in time_value64_add_hpc().
- Some comment improvements
Zhaoming Luo (1):
Integrate HPET
Integrate HPET so host_get_time, host_get_time64, and host_get_uptime64
are more precise. The highest precision can be 10ns when this patch is
applied.
* i386/i386/apic.c: Implement the two high-precision clock interface functions
added in this patch for i386.
* i386/i386at/model_dep.c
Zhaoming Luo, le dim. 23 mars 2025 10:47:14 +0800, a ecrit:
> Check the availability of host_get_time64 and use it to replace
> host_get_time for CLOCK_REALTIME when it's available.
> case CLOCK_REALTIME:
>{
> - /* __host_get_time can only fail if passed an invalid host_t.
> +
inal Message
> On 23/3/25 9:13 pm, Zhaoming Luo wrote:
>
> > Hi,
> >
> > I'm wondering the code for checking whether a high-precision code is
> > available should be in mach_clock.c or in the machine-dependent
> > directory. In this patch it&#x
Hello,
Almost there!
Samuel
Zhaoming Luo, le dim. 23 mars 2025 18:13:55 +0800, a ecrit:
> +uint32_t
> +hpclock_get_counter_period_nsec(void)
> +{
> +if (hpet_addr != NULL)
> + return hpet_period_nsec;
> +else
> + return 0;
When hpet_addr is NULL, hpet_period_nsec will already be
Damien Zammit via Bug reports for the GNU Hurd, le dim. 23 mars 2025 08:22:23
+, a ecrit:
> I think we are assuming any machine with ACPI has HPET. This is true since
> ~2005.
Yes, but we currently still support the non-APIC case too.
Samuel
:).
Zhaoming
>
>
> Original Message
> On 23/3/25 9:13 pm, Zhaoming Luo wrote:
>
> > Hi,
> >
> > I'm wondering the code for checking whether a high-precision code is
> > available should be in mach_clock.c or in the machine-dependent
&
wrote:
> Hi,
>
> I'm wondering the code for checking whether a high-precision code is
> available should be in mach_clock.c or in the machine-dependent
> directory. In this patch it's in the machine-dependent directory. It can
> ensure the backward compactabili
Hi,
I'm wondering the code for checking whether a high-precision code is
available should be in mach_clock.c or in the machine-dependent
directory. In this patch it's in the machine-dependent directory. It can
ensure the backward compactability. Otherwise compiling a gnumach
On Sun, Mar 23, 2025 at 09:03:01AM +0100, Samuel Thibault wrote:
> Zhaoming Luo, le dim. 23 mars 2025 13:29:47 +0800, a ecrit:
> > On Sun, Mar 23, 2025 at 12:48:52AM +0100, Samuel Thibault wrote:
> > > Zhaoming Luo, le sam. 22 mars 2025 15:24:50 +0800, a ecrit:
> > >
> > > > diff --git a/i386/i386
I think we are assuming any machine with ACPI has HPET. This is true since
~2005.
Damien
Sent from Proton Mail Android
Original Message
On 23/3/25 7:03 pm, Samuel Thibault wrote:
> Zhaoming Luo, le dim. 23 mars 2025 13:29:47 +0800, a ecrit:
> > On Sun, Mar 23, 2025 at 12:
Zhaoming Luo, le dim. 23 mars 2025 13:29:47 +0800, a ecrit:
> On Sun, Mar 23, 2025 at 12:48:52AM +0100, Samuel Thibault wrote:
> > Zhaoming Luo, le sam. 22 mars 2025 15:24:50 +0800, a ecrit:
> >
> > > diff --git a/i386/i386at/model_dep.c b/i386/i386at/model_dep.c
> > > index 30449c37..aa8451ac 100
Compared with RFC version:
- Call them hpc (high-precision clock) instead of hpet.
- Move the function signatures to kern/mach_clock.h.
- Cap the value in time_value64_add_hpet().
Zhaoming Luo (1):
Integrate HPET so the functions used for getting time can have a
higher accuracy
i386/i386/a
Integrate HPET so host_get_time, host_get_time64, and host_get_uptime64
are more precise. The highest precision can be 10ns when this patch is
applied.
* i386/i386/apic.c: Implement the two high-precision clock interface functions
added in this patch for i386.
* i386/i386at/model_dep.c
On Sun, Mar 23, 2025 at 12:48:52AM +0100, Samuel Thibault wrote:
> Hello,
>
Thanks for the review
> Zhaoming Luo, le sam. 22 mars 2025 15:24:50 +0800, a ecrit:
>
> > diff --git a/i386/i386at/model_dep.c b/i386/i386at/model_dep.c
> > index 30449c37..aa8451ac 100644
> > --- a/i386/i386at/model_dep
Thank you Samuel for the review.
Compared with v1:
- Check if host_get_time64 RPC is available and use it for
CLOCK_REALTIME when it is
Zhaoming Luo (1):
mach: Use the host_get_time64 to replace the deprecated host_get_time
for CLOCK_REALTIME
config.h.in | 3 +++
sysde
Check the availability of host_get_time64 and use it to replace
host_get_time for CLOCK_REALTIME when it's available.
host_get_time is deprecated
See
https://git.savannah.gnu.org/cgit/hurd/gnumach.git/commit/?id=569df850cd7badd1e36132ad3b44aa76a4d27c25
However, it's kept for backward compactbilit
Hello,
Zhaoming Luo, le dim. 23 mars 2025 09:50:33 +0800, a ecrit:
> Use the host_get_time64 to replace the deprecated host_get_time for
> CLOCK_REALTIME.
host_get_time64 is not always available, not with older gnumach. Please
use #if machinery like above in the monotonic case.
In general, pleas
Use the host_get_time64 to replace the deprecated host_get_time for
CLOCK_REALTIME.
See
https://git.savannah.gnu.org/cgit/hurd/gnumach.git/commit/?id=569df850cd7badd1e36132ad3b44aa76a4d27c25
---
sysdeps/mach/clock_gettime.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --g
Hello,
Zhaoming Luo, le sam. 22 mars 2025 15:24:50 +0800, a ecrit:
> The HPET counter is read once in every clock interrupt. When any of the
> functions used for getting time is used, the HPET counter is read again and
> the difference between these two read is multiplied by the HPET period
> and
The HPET counter is read once in every clock interrupt. When any of the
functions used for getting time is used, the HPET counter is read again and
the difference between these two read is multiplied by the HPET period
and added to the read value from time or uptime to get a more accurate
time read
to the
local-intr-msg-clobber.diff patch, which is now obsolete.
* hurd/test-sig-xstate.c: check xstate save and restore in the case
where a signal is delivered to a running thread, making sure that
the xstate is modified in the signal handler.
* hurd/test-xstate.h: add helpers to test xstate
Compare with v1:
Better readability and also check for dup3.
I haven't tested this patch again some stress tests as I don't know why
the `dpkg-buildpackage -B` on my qemu got stuck at:
```
...
../scripts/evaluate-test.sh stdio-common/scanf14 $? false false >
/home/1speaker/apt-sour
Hello,
While at it, we'd better also fix sysdeps/mach/hurd/dup3.c the exact
same way (which will also fix dup2).
Thanks,
Samuel
Zhaoming Luo, le jeu. 06 mars 2025 06:39:04 +0800, a ecrit:
> Ignoring the return value of mach_port_mod_ref() causes the situation
> + if (err)
> +
Ignoring the return value of mach_port_mod_ref() causes the situation
that when the reference count of the io server port is full, the caller
of dup() still supposes a new file discriptor is allocated. In this
patch we check the return value of mach_port_mod_ref() and return an
error when it fails
> > Zhaoming Luo, le mer. 05 mars 2025 19:25:15 +0800, a ecrit:
> > > > - Run 'apt source glibc', use quilt to apply this patch and build
> > > > the libc package using `dpkg-buildpackage -B`. I got the same error as
> > > > [0].
> > >
pt source glibc', use quilt to apply this patch and build
> > > the libc package using `dpkg-buildpackage -B`. I got the same error as
> > > [0].
> > >
> > > [0]:
> > > https://buildd.debian.org/status/fetch.php?pkg=glibc&arch=hurd-i386&a
On Wed, Mar 05, 2025 at 12:38:39PM +0100, Samuel Thibault wrote:
> Hello,
Thanks for the quick reply.
>
> Zhaoming Luo, le mer. 05 mars 2025 19:25:15 +0800, a ecrit:
> > - Run 'apt source glibc', use quilt to apply this patch and build
> > the libc package usin
Hello,
Zhaoming Luo, le mer. 05 mars 2025 19:25:15 +0800, a ecrit:
> - Run 'apt source glibc', use quilt to apply this patch and build
> the libc package using `dpkg-buildpackage -B`. I got the same error as
> [0].
>
> [0]:
> https://buildd.debian.org/status/f
This patch is quite conservative, only the first mach_port_mod_ref() is
checked, as I haven't found an elegant way to check both
mach_port_mod_ref()s.
I haven't successfully tested this patch. I have tried several methods to
apply the patch and build but failed:
- Clone the glibc s
Hello,
Zhaoming Luo, le sam. 22 févr. 2025 14:27:07 +0800, a ecrit:
> This is not completed, but I would to confirm whether I have
> understanded the code.
Yes, this is the idea.
> Then we use 'machdev_trivfs_init ()' to init it so ext2fs can use
> device_open('hd0s1'); the following stuff it is
This is not completed, but I would to confirm whether I have
understanded the code.
Assume the storeio is added in the boot process. What it can use is the
'hd0' device provided by the rumpdisk. The control port of rumpdisk is
set on the bootstrap port of storeio, so we need to use the following
c
Samuel Thibault, le lun. 10 févr. 2025 13:57:46 +0100, a ecrit:
> Flavio Cruz, le dim. 09 févr. 2025 22:36:30 -0500, a ecrit:
> > * pfinet/linux-src/net/ipv4/{tcp,udp}_ipv4.c: mark lookup functions as
> > extern since they are used in another module (icmp.c) and shouldn't be
> > removed.
>
> >
Applied, thanks!
Flavio Cruz, le dim. 09 févr. 2025 22:38:26 -0500, a ecrit:
> ---
> server.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/server.c b/server.c
> index 8da231c..9d25573 100644
> --- a/server.c
> +++ b/server.c
> @@ -766,6 +766,14 @@ WriteExtractArg(FILE *file,
Applied, thanks!
Flavio Cruz, le dim. 09 févr. 2025 22:37:56 -0500, a ecrit:
> ---
> mach/mig_strncpy.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/mach/mig_strncpy.c b/mach/mig_strncpy.c
> index b0c001d775..dbd0a08e56 100644
> --- a/mach/mig_strncpy.c
> ++
Applied, thanks!
Flavio Cruz, le dim. 09 févr. 2025 22:37:13 -0500, a ecrit:
> ---
> kern/ipc_mig.c | 25 +
> 1 file changed, 13 insertions(+), 12 deletions(-)
>
> diff --git a/kern/ipc_mig.c b/kern/ipc_mig.c
> index 18ac88ef..b6543703 100644
> --- a/kern/ipc_mig.c
> +++
Flavio Cruz, le dim. 09 févr. 2025 22:36:30 -0500, a ecrit:
> * pfinet/linux-src/net/ipv4/{tcp,udp}_ipv4.c: mark lookup functions as
> extern since they are used in another module (icmp.c) and shouldn't be
> removed.
> diff --git a/pfinet/linux-src/net/ipv4/tcp_ipv4.c
> b/pfinet/linux-src/net
---
server.c | 8
1 file changed, 8 insertions(+)
diff --git a/server.c b/server.c
index 8da231c..9d25573 100644
--- a/server.c
+++ b/server.c
@@ -766,6 +766,14 @@ WriteExtractArg(FILE *file, const argument_t *arg)
WriteInitializeCount(file, arg);
}
+/* Ensure stri
---
mach/mig_strncpy.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/mach/mig_strncpy.c b/mach/mig_strncpy.c
index b0c001d775..dbd0a08e56 100644
--- a/mach/mig_strncpy.c
+++ b/mach/mig_strncpy.c
@@ -6,6 +6,14 @@
vm_size_t
__mig_strncpy (char *dst, const char *src,
---
kern/ipc_mig.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/kern/ipc_mig.c b/kern/ipc_mig.c
index 18ac88ef..b6543703 100644
--- a/kern/ipc_mig.c
+++ b/kern/ipc_mig.c
@@ -273,10 +273,12 @@ mig_put_reply_port(
/*
* mig_strncpy.c - by Joshua B
* libshouldbeinlibc/lcm.c: make gcd static since it's not exposed as a
symbol.
* pfinet/linux-src/net/ipv4/{tcp,udp}_ipv4.c: mark lookup functions as
extern since they are used in another module (icmp.c) and shouldn't be
removed.
* term/munge.c: make poutput static since it's not exposed as a
Applied, thanks!
Zhaoming Luo, le sam. 08 févr. 2025 18:32:20 +0800, a ecrit:
> The term_getctty() should accept pty_class
>
> See
> https://mail.gnu.org/archive/html/bug-hurd/2025-02/msg00061.html
>
> * term/users.c: The term_getctty() accepts pty_class
> ---
> term/users.c | 2 +-
> 1 file ch
The term_getctty() should accept pty_class
See
https://mail.gnu.org/archive/html/bug-hurd/2025-02/msg00061.html
* term/users.c: The term_getctty() accepts pty_class
---
term/users.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/term/users.c b/term/users.c
index 3f449c71..bb
tting them from mmap() and such functions that map files into memory.
or do we just disable it like now?
That will be simpler for now.
Samuel
Got it. I'll disable it for now and put a simple explanation next to it
when I send the whole patch to upstream.
--
Yuqian Yang
On Fri, Feb 7, 2025 at 6:51 PM Samuel Thibault wrote:
> Yuqian Yang, le ven. 07 févr. 2025 23:27:01 +0800, a ecrit:
> > I know this is due to the way of our kernel to handle file and memory.
> > Do we have a good way to fix this,
>
> Not a trivial way. It'd need adding names to the kernel map entr
Yuqian Yang, le ven. 07 févr. 2025 23:27:01 +0800, a ecrit:
> I know this is due to the way of our kernel to handle file and memory.
> Do we have a good way to fix this,
Not a trivial way. It'd need adding names to the kernel map entries, and
setting them from mmap() and such functions that map fi
When I fixed abseil[1] for Hurd, I disabled its debugging feature
of finding the symbol of current functions or any other symbols.[2]
It does not work on Hurd and its unit tests failed. It can be safely
disabled and does not affect other functions of lib just like
platforms that do not support it,
Zhaoming Luo, le mer. 05 févr. 2025 09:03:49 +0800, a ecrit:
> Please have a look, I hope the semantics are correct :).
That looks alright indeed!
Thanks,
Samuel
> ---
> runtime/doc/builtin.txt| 1 +
> src/evalfunc.c | 9 -
> src/testdir/test_functions.vim | 2 ++
Please have a look, I hope the semantics are correct :).
Zhaoming
---
runtime/doc/builtin.txt| 1 +
src/evalfunc.c | 9 -
src/testdir/test_functions.vim | 2 ++
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/runtime/doc/builtin.txt b/runtime/doc/bu
On Mon, Feb 03, 2025 at 04:41:13PM +0800, Zhaoming Luo wrote:
>
> Zhaoming Luo (1):
> Exclude GNU/Hurd from has('bsd') feature
>
> src/evalfunc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
As it seems not to be the correct way of submitting pa
Samuel Thibault, le ven. 10 janv. 2025 19:40:05 +0100, a ecrit:
> Diego Nieto Cid, le mar. 07 janv. 2025 18:48:49 +, a ecrit:
> > I've been running gnumach with this patch for some time, doing other
> > porting/debugging tasks and suffered from sporadic filesystem corru
GNU/Hurd, like Mac OS X, is a BSD-based system. It should exclude
has('bsd') feature just like what Mac OS X does. The __GNU__ pre-defined
macro indicates it's compiling for GNU/Hurd.
Signed-off-by: Zhaoming Luo
---
src/evalfunc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Hi,
I'm not sure if I should add a feature (like has('hurd')) for GNU/Hurd,
and if it should be in this patch or in a seperate patch.
Zhaoming Luo (1):
Exclude GNU/Hurd from has('bsd') feature
src/evalfunc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
2.47.2
This port extends the existing i686 port to support x86_64 by reusing
existing code whenever it makes sense.
* gdb/amd64-gnu-tdep.c: Adds logic for handling signal frames and
position of amd64 registers in the different Hurd structs.
The signal code is very similar to i686, except the trampoli
Applied both, thanks!
Samuel
Yuqian Yang, le ven. 31 janv. 2025 18:31:38 +0800, a ecrit:
> * The old "Access to a GNU/Hurd System" is very vague. Move it to
> Running section.
>
> * Add details to Running section. Separate following things into
> individual paragraphs.
>
> * Running platf
On Wed, Jan 29, 2025 at 05:28:05PM +0800, Yuqian Yang wrote:
> > That's a good idea! Thanks for the contribution!
>
> You are so welcome.
>
> After struggling about my own things for several months, I turn back to Hurd
> now. I'm reading the doc now and recording some things for bootstrap of
> c
Ikiwiki seems to not have the feature of automatically creating
a section anchor. So I use this ugly way to make it.
---
index.mdwn | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/index.mdwn b/index.mdwn
index 82e614f3..815a49a6 100644
--- a/index.mdwn
+++ b/index.mdwn
@@
* The old "Access to a GNU/Hurd System" is very vague. Move it to
Running section.
* Add details to Running section. Separate following things into
individual paragraphs.
* Running platforms
* Pre-installed image or LiveCD
* Distributions
* Add some recommandations.
---
index.mdwn | 3
Applied, thanks!
Yuqian Yang, le mer. 29 janv. 2025 23:14:31 +0800, a ecrit:
> Many people are familiar with VirtualBox, or using OS other than
> GNU/Linux. VirtualBox gives them more opportunity to play with Hurd.
> ---
> hurd/running/virtualbox.mdwn | 19 +--
> index.mdwn
Many people are familiar with VirtualBox, or using OS other than
GNU/Linux. VirtualBox gives them more opportunity to play with Hurd.
---
hurd/running/virtualbox.mdwn | 19 +--
index.mdwn | 2 ++
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/hur
January 29, 2025 at 4:28 AM, "Yuqian Yang" mailto:crup...@crupest.life?to=%22Yuqian%20Yang%22%20%3Ccrupest%40crupest.life%3E
> wrote:
>
> >
> > That's a good idea! Thanks for the contribution!
> >
> You are so welcome.
>
> After struggling about my own things for several months, I turn back
That's a good idea! Thanks for the contribution!
You are so welcome.
After struggling about my own things for several months, I turn back to
Hurd now. I'm reading the doc now and recording some things for
bootstrap of contributing to Hurd. So I'll mainly contribute to doc
recently.
BTW, d
If you have not seen this website, it is a simple way to get started
with git send-email:
https://git-send-email.io/
That's a really nice guide. Neat and essential.
Actually I was about to learn git send-email and how to organize my
mails to better use mailing list. There are a lot of duplica
Applied, thanks!
Luca Dariz, le lun. 06 janv. 2025 14:46:49 +0100, a ecrit:
> This allows to check at compilation time for some rpc (as done for
> example in glibc for thread_set/get_name() and host_page_size()).
> Also the IDs can be useful for testing purposes, or when assembling
> messages manu
1 - 100 of 4136 matches
Mail list logo
