Re: [PATCH v2] libshouldbeinlibc: Use 64bit mapped time values in maptime_read when possible

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

Re: [PATCH hurd] libshouldbeinlibc: Use 64bit mapped time values in maptime_read when possible

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_

Re: [PATCH v2] libdiskfs: Get the time with higher resolution from kernel when possible

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: > > > >

Re: [PATCH v2] libdiskfs: Get the time with higher resolution from kernel when possible

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() &

Re: [PATCH v2] libdiskfs: Get the time with higher resolution from kernel when possible

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

Re: [PATCH 0/1] libdiskfs: Get the time with higher resolution from kernel

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

Re: [PATCH mach] Fix comment

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/

Re: The log of booting Thinkpad T60 with rumpdisk

Zhaoming Luo, le mar. 29 avril 2025 17:21:05 +0800, a ecrit: > On Tue, Apr 29, 2025 at 09:51:25AM +0200, Samuel Thibault wrote: > > > > What is more concerning is: > > > > piixide0:0:0: lost interrupt > > > > So the user-level interrupt mechanism should be

Re: The log of booting Thinkpad T60 with rumpdisk

Zhaoming Luo, le mar. 29 avril 2025 11:06:47 +0800, a ecrit: > On Tue, Apr 29, 2025 at 02:19:30AM +, Damien Zammit wrote: > > Hi, this is very interesting and probably indicating that we need to fix > > race between previous servers starting up and next ones, as you mentioned. I don't think i

Re: streamio returning ED_WOULD_BLOCK

Ludovic Courtès, le lun. 21 avril 2025 16:59:03 +0200, a ecrit: > Samuel Thibault writes: > > dev_read starts with if (err) return err;. Various functions do not > > define their own err variable. I don't know the original reason for > > this, but this looks fishy

Re: streamio returning ED_WOULD_BLOCK

Ludovic Courtès, le lun. 21 avril 2025 00:59:00 +0200, a ecrit: > Samuel Thibault writes: > > > Ludovic Courtès, le dim. 20 avril 2025 17:40:02 +0200, a ecrit: > >> What happens here is that reading from /dev/klog (opened with > >> O_NONBLOCK) returns ED_WOULD

Re: streamio returning ED_WOULD_BLOCK

Hello, Ludovic Courtès, le dim. 20 avril 2025 17:40:02 +0200, a ecrit: > What happens here is that reading from /dev/klog (opened with > O_NONBLOCK) returns ED_WOULD_BLOCK. However Guile and its concurrency > framework (Fibers) don’t know about this error, hence the (non-fatal) > backtrace, but t

Re: [PATCH] hurd: save xstate during signal handling

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

Re: accept(2) returning a O_NONBLOCK socket

Hello, yelninei--- via Bug reports for the GNU Hurd, le ven. 18 avril 2025 14:42:03 +0200, a ecrit: >   client = accept(fd, NULL, NULL); >   if (client < 0) return 1; >   fprintf(stderr, "Accepting connection\n"); >   if ((fcntl(client, F_GETFL) & O_NONBLOCK) != 0) > { >   fprintf

Re: [PATCH] hurd: save xstate during signal handling

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

Re: [RFC PATCH v2 glibc] hurd: Check return value of mach_port_mod_refs() in the dup routine of fcntl()

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: > >

Re: [RFC PATCH v2 glibc] hurd: Check return value of mach_port_mod_refs() in the dup routine of fcntl()

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 $? false false > > /home/1speaker/ap

Re: [PATCH] hurd: save xstate during signal handling

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

Re: [PATCH web] The option -M q35 is needed when trying rumpdisk in qemu

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/

Re: [PATCH web] Typo fixed

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

Re: [PATCH] x86_64: update ifdef to exclude the x86_64 for i386 only specific conditions

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

Re: [RFC] riscv64 stub port for GNU Mach – compiles, early WIP

Hello, Hakan Candar, le sam. 05 avril 2025 13:40:01 +, a ecrit: > I’ve been working on getting GNU Mach to compile on riscv64, Nice :) I don't remember if somebody did some work about this. > Separately, I created a `riscv64-none-gnu` target for GCC and created the > necessary backend confi

Re: [PATCH 1/1 web] contributing: Fix the 'curl' testsuite

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.

Re: [PATCH Hurd] Comment fixed

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

Re: [PATCH web] contributing: Improve the get time functions accuracy using HPET

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

Re: [PATCH mach v4 1/1] Integrate HPET so the functions used for getting time can have a higher accuracy

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 high-precision clock

Re: [PATCH v3] mach: Use the host_get_time64 to replace the deprecated host_get_time for CLOCK_REALTIME when it's available

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

Re: [PATCH v2 1/1] mach: Use the host_get_time64 to replace the deprecated host_get_time for CLOCK_REALTIME when it's available

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. > +

Re: [RFC PATCH v3] Integrate HPET so the functions used for getting time can have a higher accuracy

Damien Zammit via Bug reports for the GNU Hurd, le dim. 23 mars 2025 10:20:37 +, a ecrit: > You probably want to disable it entirely so it doesn't need to execute a > branch condition every time it reads the timer, ie with #ifdef. The if is precisely meant for the case where hpet is not avai

Re: [RFC PATCH v3] Integrate HPET so the functions used for getting time can have a higher accuracy

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

Re: [RFC PATCH gnumach] kern: Integrate HPET so the functions used for getting time can have a higher accuracy

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

Re: [RFC PATCH gnumach] kern: Integrate HPET so the functions used for getting time can have a higher accuracy

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 > &

Re: [PATCH] mach: Use the host_get_time64 to replace the deprecated host_get_time for CLOCK_REALTIME

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

Re: [RFC PATCH gnumach] kern: Integrate HPET so the functions used for getting time can have a higher accuracy

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

Re: [PATCH] hurd: Check return value of mach_port_mod_refs() in the dup routine of fcntl()

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) > +

Re: [RFC PATCH glibc] Check return value of a mach_port_mod_ref() in dup()

Zhaoming Luo, le mer. 05 mars 2025 20:07:56 +0800, a ecrit: > 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 'a

Re: [RFC PATCH glibc] Check return value of a mach_port_mod_ref() in dup()

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/fetch.php?pkg=glibc&arch=hurd-i38

Re: curl testsuite 537

Zhaoming Luo, le lun. 03 mars 2025 19:35:37 +0800, a ecrit: > Test 537 on Hurd opens 0x4 file discriptors and close them[0]. The code is really odd. if(nitems > 0x7fff) nitems = 0x4; I would have rather understood if(nitems > 0x7fff) nitems = 0x8000; which will happ

Re: curl testsuite 537

Zhaoming Luo, le lun. 03 mars 2025 19:35:37 +0800, a ecrit: > a dup() is executed[4]. The code line of [4] I think is where the issue > is. We ignored return value of __mach_port_mod_refs(). In this case we > indeed reached the limit of reference count[5], Oops :) This should indeed be fixed into

Re: curl testsuite 1541

Zhaoming Luo, le sam. 01 mars 2025 19:06:52 +0800, a ecrit: > It checks for the total time of requesting a page under http > protocol[0][1]. More than 0 is needed. > > It's just too fast and our GNU Mach clock is not accurate enough: Ah :/ > Maybe adding the support of high accuracy clock in GNU

Re: Set up a new pfinet instance using remap

Zhaoming Luo, le ven. 28 févr. 2025 20:42:41 +0800, a ecrit: > I have applied the code and make test. [...] > I think you can commit the code. Ok, done so, thanks! > I could only see two failed tests now. Test 537 is a stress test and > it got stuck and outputing a lot of 'Deallocating a bogus po

Re: Set up a new pfinet instance using remap

Hello, Nice investigation! Zhaoming Luo, le jeu. 27 févr. 2025 10:37:36 +0800, a ecrit: > It means that pthread_hurd_cond_timedwait_np() successes but > current->signal is still 1. I assume current->signal will only be > modified to 1 when pthread_hurd_cond_timedwait_np() returns EINTR. Maybe > w

Re: Set up a new pfinet instance using remap

Zhaoming Luo, le jeu. 27 févr. 2025 08:23:16 +0800, a ecrit: > On Tue, Feb 25, 2025 at 08:28:34PM +0100, Samuel Thibault wrote: > > Zhaoming Luo, le mar. 25 févr. 2025 21:14:14 +0800, a ecrit: > > > The program './runtests.pl -g 546' stopped at [0] several times bef

Re: Set up a new pfinet instance using remap

Hello, Zhaoming Luo, le mar. 25 févr. 2025 21:14:14 +0800, a ecrit: > The program './runtests.pl -g 546' stopped at [0] several times before > the test is really running, so I think some preparations involved > io_select_common. However, after the test is running, I set a breakpoint > at [1](it's

Re: [RFC PATCH] Add bootstrap routine for storeio

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

Re: Type mach_msg_type_number_t usage too small in x86-64 on pci_get_dev_rom()

Samuel Thibault, le sam. 22 févr. 2025 15:33:27 +0100, a ecrit: > Guillem Jover, le sam. 22 févr. 2025 14:09:59 +0100, a ecrit: > > The pciutils package is failing to build in Debian on hurd-amd64: > > > > > > https://buildd.debian.org/status/fetch.php?pkg=pci

Re: Type mach_msg_type_number_t usage too small in x86-64 on pci_get_dev_rom()

Guillem Jover, le sam. 22 févr. 2025 14:09:59 +0100, a ecrit: > The pciutils package is failing to build in Debian on hurd-amd64: > > > https://buildd.debian.org/status/fetch.php?pkg=pciutils&arch=hurd-amd64&ver=1%3A3.13.0-1%2Bb1&stamp=1732538417&raw=0 > > The error is the following: > > ,---

Re: curl testsuite: 546

Zhaoming Luo, le sam. 22 févr. 2025 21:06:18 +0800, a ecrit: > On Sat, Feb 22, 2025 at 02:01:58PM +0100, Samuel Thibault wrote: > > Zhaoming Luo, le sam. 22 févr. 2025 20:59:53 +0800, a ecrit: > > > On Sat, Feb 22, 2025 at 01:07:40PM +0100, Samuel Thibault wrote: > > >

Re: curl testsuite: 546

Zhaoming Luo, le sam. 22 févr. 2025 20:59:53 +0800, a ecrit: > On Sat, Feb 22, 2025 at 01:07:40PM +0100, Samuel Thibault wrote: > > Zhaoming Luo, le sam. 22 févr. 2025 20:03:12 +0800, a ecrit: > > > On Sat, Feb 22, 2025 at 12:47:16PM +0100, Samuel Thibault wrote: > > >

Re: curl testsuite: 546

Zhaoming Luo, le sam. 22 févr. 2025 20:03:12 +0800, a ecrit: > On Sat, Feb 22, 2025 at 12:47:16PM +0100, Samuel Thibault wrote: > > Zhaoming Luo, le sam. 22 févr. 2025 19:29:55 +0800, a ecrit: > > > lib533.c:96 select() failed, with errno 1073741828 (Interrupted system > &g

Re: curl testsuite: 546

Hello, Zhaoming Luo, le sam. 22 févr. 2025 19:29:55 +0800, a ecrit: > lib533.c:96 select() failed, with errno 1073741828 (Interrupted system call) This is expected if the test handles a signal. Does it indeed set up a signal handler and get a signal? Samuel

Re: vim testsuite: Test_buflist_alloc_failure

Zhaoming Luo, le lun. 17 févr. 2025 12:21:53 +0800, a ecrit: > On Sun, Feb 16, 2025 at 10:30:17AM +0100, Samuel Thibault wrote: > > Hello, > > > > Zhaoming Luo, le dim. 16 févr. 2025 15:59:41 +0800, a ecrit: > > > In the test[0] of vim. I think the issue is that th

Re: vim testsuite: Test_FileChangedShell_reload

Zhaoming Luo, le lun. 17 févr. 2025 10:16:42 +0800, a ecrit: > On Sun, Feb 16, 2025 at 10:39:42AM +0100, Samuel Thibault wrote: > > Zhaoming Luo, le dim. 16 févr. 2025 16:22:01 +0800, a ecrit: > > > In test_filechanged.vim, those three parts are the sources of fail: > > >

Re: Confusion about the bootstrap process

Hello, Zhaoming Luo, le lun. 17 févr. 2025 09:14:13 +0800, a ecrit: > This is what I have done to try to open the storeio translator in > ext2fs, like what's mentioned in the TODO list. > ``` >error_t err; >mach_port_t bootstrap; > > - /* Initialize the diskfs library, parse arguments, a

Re: vim testsuite: Test_FileChangedShell_reload

Zhaoming Luo, le dim. 16 févr. 2025 16:22:01 +0800, a ecrit: > In test_filechanged.vim, those three parts are the sources of fail: > > https://github.com/vim/vim/blob/master/src/testdir/test_filechanged.vim#L15-L18 > https://github.com/vim/vim/blob/master/src/testdir/test_filechanged.vim#L57-L60 >

Re: vim testsuite: Test_buflist_alloc_failure

Hello, Zhaoming Luo, le dim. 16 févr. 2025 15:59:41 +0800, a ecrit: > In the test[0] of vim. I think the issue is that the sleep time is not > long enough. Sleep for 200ms is possible to pass the test, though the > possibility is not that high. I think sleep for 2 seconds might be a > good option.

Re: [PATCH hurd] Allow compilation with -O0

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

Re: [PATCH mig] Server routines: ensure that strings in the request are null terminated before calling the server routine

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,

Re: [PATCH glibc] mig_strncpy: ensure destination string is null terminated

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 > ++

Re: [PATCH gnumach] mig_strncpy: ensure destination string is null terminated

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 > +++

Re: [PATCH hurd] Allow compilation with -O0

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

Re: [PATCH] term: The term_getctty() accepts pty_class

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

Re: vim testsuite: Test_keep_pty_open V2

Zhaoming Luo, le sam. 08 févr. 2025 12:51:04 +0800, a ecrit: > On Sat, Feb 08, 2025 at 08:55:31AM +0800, Zhaoming Luo wrote: > > On Fri, Feb 07, 2025 at 01:57:01PM +0100, Samuel Thibault wrote: > > > Zhaoming Luo, le ven. 07 févr. 2025 18:44:50 +0800, a ecrit: > > > &

Re: [PATCH 5/6] GNU/Hurd: disable symbolize.

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

Re: vim testsuite: Test_keep_pty_open V2

Zhaoming Luo, le ven. 07 févr. 2025 18:44:50 +0800, a ecrit: > This is V2 of figuring out the issue. V1 is abandoned due to my mistake, > but this time I can confirm the source of issue. This time I ran > rpctrace directly on vim, and used two printfs to locate the isatty(). > > ``` > printf ("Sta

Re: vim testsuite: Test_keep_pty_open

Zhaoming Luo, le jeu. 06 févr. 2025 10:54:30 +0800, a ecrit: > Though I don't know why gdb tells me it uses the implementation in > $(glibc)/unix/bsd/getpt.c. Is it expected? Yes, if you git grep you will see that there are only login/getpt.c (dumb), sysdeps/unix/sysv/linux/getpt.c (linux-specific

Re: vim testsuite: Test_keep_pty_open

Zhaoming Luo, le jeu. 06 févr. 2025 11:11:42 +0800, a ecrit: > On Thu, Feb 06, 2025 at 10:54:30AM +0800, Zhaoming Luo wrote: > > On Thu, Feb 06, 2025 at 02:03:26AM +0100, Samuel Thibault wrote: > > > Zhaoming Luo, le mer. 05 févr. 2025 10:33:04 +0800, a ecrit: > > > >

Re: [RFC PATCH Vim] Add support for Hurd

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 ++

Re: vim testsuite: Test_keep_pty_open

Zhaoming Luo, le mer. 05 févr. 2025 10:33:04 +0800, a ecrit: > On Tue, Feb 04, 2025 at 09:12:18AM +0100, Samuel Thibault wrote: > > Only out_io and err_io are supposed to be readable. Or did they mean > > from the point of view of the executed process. Again, it means check &

Re: tty has to be manually created after installed with LiveCD

Yuqian Yang, le mer. 05 févr. 2025 02:04:47 +0800, a ecrit: > I tried many cases. qemu-kvm never reproduced however I tried. > > I get a working one in VirtualBox by not pushing enter immediately > after grub is installed and it prompts me to reboot. So I guess > the problem is indeed that the fil

Re: [PATCH gnumach v3] Implement per task virtual memory limit

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

Re: vim testsuite: Test_keep_pty_open

Zhaoming Luo, le mar. 04 févr. 2025 16:01:09 +0800, a ecrit: > On Mon, Feb 03, 2025 at 01:21:44PM +0100, Samuel Thibault wrote: > > Zhaoming Luo, le lun. 03 févr. 2025 20:05:38 +0800, a ecrit: > > > I did the experiments using my own C waiting program and `sleep` shell > >

Re: Upgrade rumpkernel package to rump 10.99.12

Hello, Damien Zammit via Bug reports for the GNU Hurd, le sam. 11 janv. 2025 07:19:24 +, a ecrit: > I would like to suggest the following upgrade of rump to be on par with > my "develop" branch[1]. The patches would need to be fetched from my > branch directly because there is a very large

Re: tty has to be manually created after installed with LiveCD

Hello, Yuqian Yang, le mar. 04 févr. 2025 03:04:26 +0800, a ecrit: > I installed i386 Hurd in a virtual machine of VirtualBox with > Debian LiveCD.[1] > [1] > https://cdimage.debian.org/cdimage/ports/stable/hurd-i386/debian-sid-hurd-i386-NETINST-1.iso > The installation succeeded. I rebooted to

Re: vim testsuite: Test_keep_pty_open

Zhaoming Luo, le lun. 03 févr. 2025 20:05:38 +0800, a ecrit: > I did the experiments using my own C waiting program and `sleep` shell > command respectively. They gave me the same result. It seems the sleep > program was not executed at all. Or it just didn't get the time to do anything. > Anothe

Re: vim testsuite: Test_platform_name

Yuqian Yang, le lun. 03 févr. 2025 15:39:32 +0800, a ecrit: > > Ok I will send a patch to vim to exclude has('bsd') using > > defined(__GNU__), do you think adding a has() (maybe has('hurd')?) for > > Hurd > > should also be submitted with the patch? > > I think that needs to be discussed with vim

Re: vim testsuite: Test_platform_name

Zhaoming Luo, le lun. 03 févr. 2025 15:12:07 +0800, a ecrit: > On Mon, Feb 03, 2025 at 07:32:42AM +0100, Samuel Thibault wrote: > > Hello, > > > > Zhaoming Luo, le lun. 03 févr. 2025 12:58:13 +0800, a ecrit: > > > So the story in short is that vim thinks it is comp

Re: vim testsuite: Test_platform_name

Zhaoming Luo, le lun. 03 févr. 2025 14:44:33 +0800, a ecrit: > On Mon, Feb 03, 2025 at 07:32:42AM +0100, Samuel Thibault wrote: > > Hello, > > > > Zhaoming Luo, le lun. 03 févr. 2025 12:58:13 +0800, a ecrit: > > > So the story in short is that vim thinks it is comp

Re: vim testsuite: Test_keep_pty_open

Hello, Zhaoming Luo, le lun. 03 févr. 2025 12:22:11 +0800, a ecrit: > ``` > Run 1, 13:51:24 - 13:51:24 in 0.02 seconds: > command line..script > /<>/src/vim-gtk3/testdir/runtest.vim[617]..function > RunTheTest[57]..Test_keep_pty_open line 6: Expected range 200 - 1000, but got > 20 So it b

Re: vim testsuite: Test_platform_name

Samuel Thibault, le lun. 03 févr. 2025 07:39:25 +0100, a ecrit: > Yuqian Yang, le lun. 03 févr. 2025 14:37:16 +0800, a ecrit: > > On 2025-02-03 14:24, Zhaoming Luo wrote: > > > Cool how to you find it? > > > > Not a very wise way. Track codes, search with gre

Re: vim testsuite: Test_platform_name

Yuqian Yang, le lun. 03 févr. 2025 14:37:16 +0800, a ecrit: > On 2025-02-03 14:24, Zhaoming Luo wrote: > > Cool how to you find it? > > Not a very wise way. Track codes, search with grep or other tools. > > gcc preprocessor can do this with gcc -E. But it does not work for > system headers. You

Re: vim testsuite: Test_platform_name

Hello, Zhaoming Luo, le lun. 03 févr. 2025 12:58:13 +0800, a ecrit: > So the story in short is that vim thinks it is compiled for bsd kernel. > You can reproduce the issue by running `:echo has('bsd')` in vim on > Hurd. The implementation of `has()` is in [2]. The `has('bsd')` is > covered by `#if

Re: Debug into glibc with source code display in gdb on Debian

Zhaoming Luo, le dim. 02 févr. 2025 19:09:45 +0800, a ecrit: > On Sun, Feb 02, 2025 at 12:00:17PM +0100, Samuel Thibault wrote: > > Zhaoming Luo, le dim. 02 févr. 2025 18:55:49 +0800, a ecrit: > > > ``` > > > Thread 2 hit Breakpoint 1, _hurd_select (nfds=7, pollfds=0x

Re: Debug into glibc with source code display in gdb on Debian

Zhaoming Luo, le dim. 02 févr. 2025 18:55:49 +0800, a ecrit: > ``` > Thread 2 hit Breakpoint 1, _hurd_select (nfds=7, pollfds=0x0, > readfds=0x103cc20, writefds=0x103cc40, exceptfds=0x103cc60, > timeout=0x103cba4, sigmask=0x0) at ./hurd/hurdselect.c:51 > 51 ./hurd/hurdselect.c: No such fi

Re: [PATCH Web 1/2] Organize and detail Running_the_Hurd in home page.

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

Re: [PATCH Web] Add more info about running hurd in VirtualBox.

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

Re: [PATCH mig v2] header: add definitions for RPC presence and IDs

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

Re: [PATCH hurd v2] Add partial /proc/cpuinfo implementation

Applied, thanks! dnie...@gmail.com, le lun. 27 janv. 2025 01:17:33 +, a ecrit: > From: Diego Nieto Cid > > Hello, > > On Sun, Jan 26, 2025 at 10:18:03PM +0100, Samuel Thibault wrote: > > > > dnie...@gmail.com, le ven. 10 janv. 2025 23:52:28 +, a ecrit: &

Re: [PATCH] Add source code link to sidebar.

Yuqian Yang, le lun. 27 janv. 2025 15:16:54 +0800, a ecrit: > Make it easier to get source code directly. Applied, thanks! > --- > sidebar.mdwn | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/sidebar.mdwn b/sidebar.mdwn > index b2c7c223..87b0633b 100644 > --- a/sidebar.mdwn > +++ b/sid

Re: [PATCH hurd v1] Add partial /proc/cpuinfo implementation

Sergey Bugaev, le lun. 27 janv. 2025 00:25:15 +0300, a ecrit: > > > +out: > > > + flcose(m); > > > > You didn't try to compile it ;) > > I suppose that's not easy for Diego to do, given the state of aarch64-gnu :) Sure, but he can comment the very few really-arm64-specific lines and try to build

Re: [PATCH hurd v1] Add partial /proc/cpuinfo implementation

Hello, Thanks for working on it :) Sorry for the delay, dnie...@gmail.com, le ven. 10 janv. 2025 23:52:28 +, a ecrit: > --- a/procfs/rootdir.c > +++ b/procfs/rootdir.c > @@ -38,6 +38,12 @@ > #include "procfs_dir.h" > #include "main.h" > #include > +#if defined (__x86_64__) || defined (_

Re: [PATCH] Add doc of topgit installation to make it easier.

Yuqian Yang, le lun. 27 janv. 2025 00:23:31 +0800, a ecrit: > On 2025-01-26 23:52, Samuel Thibault wrote: > > I applied it but that came with trouble: the lines were split, and > > with spurious heading spaces. Did you really use git format-patch / > > send-email to se

Re: [PATCH] Add doc of topgit installation to make it easier.

Hello, Yuqian Yang, le dim. 26 janv. 2025 23:12:59 +0800, a ecrit: > One notable problem is that topgit is default to install to prefix `~` > rather than `~/.local`, which might surprise some people. I applied it but that came with trouble: the lines were split, and with spurious heading spaces.

Re: [PATCH v2] procfs: set d_type on returned direntries

Hello, dnie...@gmail.com, le lun. 20 janv. 2025 23:47:58 +, a ecrit: > From: Diego Nieto Cid > > Thanks for the pointer Samuel. I managed to call procfs_lookup > and extract from the node stat structure its type. > > It mostly works except for the ".." and "self" entries: > > ./test-pr

Re: [PATCH] procfs: set d_type on returned direntries

Hello, dnie...@gmail.com, le dim. 19 janv. 2025 23:50:10 +, a ecrit: > diff --git a/procfs/netfs.c b/procfs/netfs.c > index 4ed5eab6..3cf7a8e2 100644 > --- a/procfs/netfs.c > +++ b/procfs/netfs.c > @@ -115,6 +115,29 @@ error_t netfs_attempt_readlink (struct iouser *user, > struct node *np, >

Re: Console problems

Almudena Garcia, le dim. 19 janv. 2025 18:54:53 +0100, a ecrit: > with dpkg-reconfigure keyboard-configuration What is the content of /etc/default/keyboard ? Samuel

Re: Console problems

Hello, Almudena Garcia, le jeu. 16 janv. 2025 14:02:47 +0100, a ecrit: > I found the same problem. Added to this, the layout doesn't works, keeping in > en_US despite my configuration is "es" How did you configure it to es? Samuel

Re: [PATCH 0/1] fix cp /dev/null file

gfleury, le sam. 18 janv. 2025 13:10:20 +0200, a ecrit: > This fixes a bug related to `cp /dev/null file`, where you would encounter an > error like: > `skipping file /dev/null as it was replaced while being copied`. > > I reduced the `st_blksize` to one page, as it is on GNU/Linux, and added a

Re: Networking problems

Bruno Haible via Bug reports for the GNU Hurd, le mar. 14 janv. 2025 15:39:45 +0100, a ecrit: > Samuel Thibault wrote: > > > In the default (NAT) configuration of a VirtualBox VM, in all VMs > > > so far I could "ssh 10.0.2.2" to log into the VM host. With these

Re: File system problems

Bruno Haible via Bug reports for the GNU Hurd, le mar. 14 janv. 2025 15:51:11 +0100, a ecrit: > Samuel Thibault wrote: > > > when I run 'sync' it hangs. I can interrupt the 'sync' command via > > > Ctrl-C and restart it, but it then still hangs. I ended u

  1   2   3   4   5   6   7   8   9   10   >