A short progress report about rumpfs

Hi, This is a short report of my progress on rumpfs. This report is written and shared in case I'm on a wrong direction. The most of the stuff util now I have done is reading and thinking. According to this link[0], puffs is a kernel submodule for using userspace filesystem. Hurd is based on a mi

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

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

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

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

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

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

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

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 expl

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

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

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

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

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

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

[PATCH mach] Fix comment

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

Re: The log of booting Thinkpad T60 with rumpdisk

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 checked. > > But overall it seems it only sees cd0, the CD drive, plugged on piixide, > so not AHCI. Did you chec

Re: The log of booting Thinkpad T60 with rumpdisk

ace with rumpdisk. In: ``` rumpdisk r[a n 1.00d0] Copyrighot (c) 1996m, 19i97n, i19t98, 1999, 2000, 20o01, 2002,p 2e00n3, [ f a1.00i000l00e] 2d00 ``` We can see 'random init open faile`. No idea where does it come from. Zhaoming > > Original Message > On

The log of booting Thinkpad T60 with rumpdisk

Hi, I got the Thinkpad T60 dock and the serial-to-usb cable. The issue is that we found booting Thinkpad T60 with rumpdisk failed, so I collected the log for navigation. I followed this link[0] to set up the environment for rumpdisk. If I miss any neccessary information, please remind me. I set u

Re: Using rump function rump_sys_mount()

On Sun, Apr 20, 2025 at 10:49:41PM +, Damien Zammit wrote: > Hi, > > Which rump libraries are you linking to? Its vital to link to the right ones. > Part of the challenge is working out which ones. > It's indeed more challenging than I thought. I supposed I can see the linked rump library us

Using rump function rump_sys_mount()

Hi, I have been playing with the rump interface for a few days. I haven't successfully mount a file system image nor a block device (/dev/wd0s1). This is the branch I'm working on: https://codeberg.org/zhml/hurd/commits/branch/rumpplay-ext2 After compiling the `rumpplay` utility. I created a ext

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

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

[PATCH web] Typo fixed

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

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

age.php?p=glibc&suite=sid Zhaoming Zhaoming Luo (1): contributing: Fix the 'curl' testsuite contributing.mdwn | 1 - 1 file changed, 1 deletion(-) -- 2.49.0

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

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

[PATCH Hurd] Comment fixed

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

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

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

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

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

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

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

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

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

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

:). 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 &

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

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 with only '../configur

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

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

[PATCH v2 0/1] Integrate HPET so the functions used for getting time can have a higher accuracy

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

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

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

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

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 1006

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

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

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

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

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

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

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

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

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

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-source/glibc-2.41/

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

. Signed-off-by: Zhaoming Luo --- sysdeps/mach/hurd/fcntl.c | 38 +++--- 1 file changed, 27 insertions(+), 11 deletions(-) diff --git a/sysdeps/mach/hurd/fcntl.c b/sysdeps/mach/hurd/fcntl.c index a65c190c..d97226cd 100644 --- a/sysdeps/mach/hurd/fcntl.c +++ b

Re: curl testsuite 537

On Mon, Mar 03, 2025 at 01:27:50PM +0100, Samuel Thibault wrote: > 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) > nit

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

On Wed, Mar 05, 2025 at 01:12:04PM +0100, Samuel Thibault wrote: > 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. > > > >

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

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

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

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 source code, try

Re: curl testsuite 1541

On Sat, Mar 01, 2025 at 12:18:05PM +0100, Samuel Thibault wrote: > 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 fa

curl testsuite 537

Hi, The curl testsuite 537 does not fail, but it output a lot of 'deallocating a bogus port...' on the terminal. Test 537 on Hurd opens 0x4 file discriptors and close them[0]. The initial max number of file discriptor on Hurd is 1024[1]. Test 537 raises this number to unlimited so it won't be

curl testsuite 1541

Hi, Failed testsuite 1541 in curl is quite simple, it's related to the clock accuracy of Gnu Mach. It checks for the total time of requesting a page under http protocol[0][1]. More than 0 is needed. Failed log ``` 1541: data FAILED: --- log/check-expected 2025-03-01 16:42:29.0 +0800 ++

Re: Set up a new pfinet instance using remap

On Thu, Feb 27, 2025 at 08:25:37PM +0100, Samuel Thibault wrote: > 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 as

Re: Set up a new pfinet instance using remap

On Thu, Feb 27, 2025 at 09:07:53AM +0800, Zhaoming Luo wrote: > On Thu, Feb 27, 2025 at 01:34:46AM +0100, Samuel Thibault wrote: > > 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: > > >

Re: Set up a new pfinet instance using remap

On Thu, Feb 27, 2025 at 01:34:46AM +0100, Samuel Thibault wrote: > 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: > > > &

Re: Set up a new pfinet instance using remap

On Tue, Feb 25, 2025 at 08:28:34PM +0100, Samuel Thibault wrote: > 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 t

Set up a new pfinet instance using remap

Hi, So I follow following instructions to setup remap on a new pfinet instance and debug curl testsuite 546: ``` # Setup the translator pfinet which is going to be debugged settrans -fgaPc /tmp/2 /usr/bin/env LD_LIBRARY_PATH=/usr/lib/debug /home/1speaker/hurd/build/pfinet/pfinet # Open a new wi

Re: curl testsuite: 546

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: > > > Zhaoming Luo, le sam. 22 févr. 2025 20:03:12 +0800, a ecrit: > > > &

Re: curl testsuite: 546

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: > > > Zhaoming Luo, le sam. 22 févr. 2025 19:29:55 +0800, a ecrit: > >

Re: curl testsuite: 546

On Sat, Feb 22, 2025 at 12:47:16PM +0100, Samuel Thibault wrote: > 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. Do

curl testsuite: 546

Hi, I have been trying to investigate this issue for some times, but I haven't came out with a nice method. About the fail of test 546[0]. It's the error output: ``` ... < 150 Binary data connection for 546 () (51 bytes). * Maxdownload = -1 * Getting file with size: 51 * STATE: DOING_MORE => DID

[RFC PATCH] Add bootstrap routine for storeio

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

Re: vim testsuite: Test_buflist_alloc_failure

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 the sleep time is not > > long enough. Sleep for 200ms is possible to pass

Re: vim testsuite: Test_FileChangedShell_reload

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: > > > > https://github.com/vim/vim/blob/master/src/testdir/test_filechanged.

Confusion about the bootstrap process

Hi, Hope my questions are too stupid. 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, and open the store. - This starts the fi

vim testsuite: RunVimInTerminal() failed

Hi, As you can see in the vim build log[0]. There are a lot of 'RunVimInTerminal() failed'. When I run most of the failed tests due to 'RunVimInTerminal() failed' before 'make test', they can pass. I found that 'make test' (i.e. run all tests) could cause the tty "stuck". After finishing a 'make t

vim testsuite: Test_FileChangedShell_reload

Hi, 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 https://github.com/vim/vim/blob/master/src/testdir/test_filechang

vim testsuite: Test_buflist_alloc_failure

Hi, 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. Should we just submit a patch to Debian? [0]: https://github.com/vim/

[PATCH] term: The term_getctty() accepts pty_class

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

Re: vim testsuite: Test_keep_pty_open V2

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: > > > This is V2 of figuring out the issue. V1 is abandoned due to my mistake, > &g

Re: Should hurd_select returns directly when nfds == 0?

On Fri, Feb 07, 2025 at 03:00:08PM +0300, Sergey Bugaev wrote: > On Fri, Feb 7, 2025 at 2:36 PM Zhaoming Luo wrote: > > Hi, > > Hi, > > > Thread 4 hit Breakpoint 1, __GI___select (nfds=0, readfds=0x103cc20, > > writefds=0x103cc40, exceptfds=0x103cc60, timeout=0x

Re: vim testsuite: Test_keep_pty_open V2

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

Should hurd_select returns directly when nfds == 0?

Hi, When I'm checking curl test 546. I found that it went into a situation that: ``` Thread 4 hit Breakpoint 1, __GI___select (nfds=0, readfds=0x103cc20, writefds=0x103cc40, exceptfds=0x103cc60, timeout=0x103cc84) at ../sysdeps/mach/hurd/select.c:31 ``` When I continue, it hangs at mach_msg

vim testsuite: Test_keep_pty_open V2

Hi, 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 ("Start isatty!\n"); if (mch_isatty(in)) channel->ch_to_be_closed |=

Re: vim testsuite: Test_keep_pty_open

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: > > > Intead I wrote the following program to reproduce the error: > > >

Re: vim testsuite: Test_keep_pty_open

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

Re: vim testsuite: Test_keep_pty_open

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 > what exactly happens to end up with "all readable fds are closed" > Try to keep the

[RFC PATCH Vim] Add support for Hurd

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

Re: [PATCH 0/1] Exclude GNU/Hurd from has('bsd') feature

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

Re: vim testsuite: Test_keep_pty_open

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 > > command respectively. They gave me the same result. It seems the sleep >

Re: vim testsuite: Test_keep_pty_open

On Mon, Feb 03, 2025 at 08:39:09AM +0100, Samuel Thibault wrote: > Hello, > > Zhaoming Luo, le lun. 03 févr. 2025 12:22:11 +0800, a ecrit: > > It's still the case with different sleep times. I believe the issue is > > related to: > > > > ``` > >

[PATCH 1/1] Exclude GNU/Hurd from has('bsd') feature

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 de

[PATCH 0/1] Exclude GNU/Hurd from has('bsd') feature

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

Re: vim testsuite: Test_platform_name

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 compiled for bsd kernel. > > You can reproduce the issue by running `:echo has('

Re: vim testsuite: Test_platform_name

On Mon, Feb 03, 2025 at 07:39:25AM +0100, Samuel Thibault wrote: > 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

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 compiled for bsd kernel. > > You can reproduce the issue by running `:echo has('

Re: vim testsuite: Test_platform_name

On Mon, Feb 03, 2025 at 02:37:16PM +0800, Yuqian Yang wrote: > 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. Ok, maybe I should try to be more patient :-). Thanks anyway. > > gc

Re: vim testsuite: Test_platform_name

On Mon, Feb 03, 2025 at 02:14:14PM +0800, Yuqian Yang wrote: > On 2025-02-03 12:58, Zhaoming Luo wrote: > > > ... I haven't found a > > practical method to track where the BSD macro is defined during > > compilation. > > It is defined in `/usr/include/x86_64-gn

vim testsuite: Test_platform_name

Hi, This test failed is quite interesting. (source code [0]) Error log after running "make test_functions": ``` ... 1 FAILED: Found errors in Test_platform_name(): command line..script /home/1speaker/vim/src/testdir/runtest.vim[617]..function RunTheTest[57]..Test_platform_name line 18: Expected

vim testsuite: Test_keep_pty_open

Hi, I hope this is the right place to post the discussion like this, as I can confirm the test failed reason is not related to vim and it's quite hard for me to track the issue alone. I think some discussion will be helpful to solve the issue. In the build log[0]: ``` >From test_channel.vim: Fou

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

On Sun, Feb 02, 2025 at 12:13:17PM +0100, Samuel Thibault wrote: > 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: > > >

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

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=0x0, > > readfds=0x103cc20, writefds=0x103cc40, exceptfds=0x103cc60, >

Debug into glibc with source code display in gdb on Debian

Hi, I'm trying to track the curl failed tests by debugging select() function (or system call?) defined in glibc using gdb. When I executed `b _hurd_select` to set a break point and run the program. The gdb stopped at the breakpoint but it gives me the following info: ``` Thread 2 hit Breakpoint 1

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

y, the festival is just like Christmas Day in > our culture. > > TODAY IS THE DAY! Happy Lunar/Chinese New Year to Hurd community! :) > > Sorry that I'm unfamiliar with most contributors here. But the same blessing > to everyone here! Especially Zhaoming Luo, haha! > Happy New Year guys! I know this celebration is not too late ;). Zhaoming Luo

The hardware supported by GNU/Hurd

Hi Paolo, The hardware that's supported by GNU/Hurd is described in the following link: https://darnassus.sceen.net/~hurd-web/faq/drivers/ Please feel free to ask questions. Best wishes, Zhaoming

Gather suggestions about how to set up a more friendly development environment on hurd vm

Hi, I would like to try to add a wiki page introducing how to set up a more friendly development environment in hurd vm. That wiki page will introduce some plugins that would be useful while reading source code, like `any-jump.vim`, and Emacs' `dumb-jump` suggested by gnucode (thanks gnucode :)),

[PATCH 0/1 Web] Open issues: Update clock_gettime page

I have tried my best, but some content is a bit confusing for me. Please do have a check before merge. Zhaoming Luo (1): Open issues: Update clock_gettime page open_issues/clock_gettime.mdwn | 345 open_issues/nanosecond-precision_clock.mdwn | 56 2

[PATCH 1/1 Web] Open issues: Update clock_gettime page

The clock_gettime(CLOCK_MONOTONIC) is implemented. See https://sourceware.org/git?p=glibc.git;a=commit;h=3782ffaf3e6c2a071df029b96712e596b5229838 so this page is out of date. Rename the page to nanosecond-precision_clock, and remove the information about clock_gettime(CLOCK_MONOTONIC). --- open

Re: [RFC PATCH glibc v3] mach: Add CLOCK_MONOTONIC case in clock_gettime()

On Sun, Jan 12, 2025 at 11:34:19PM +0100, Samuel Thibault wrote: > Hello, > > Zhaoming Luo, le lun. 06 janv. 2025 12:39:07 +0800, a ecrit: > > mach: Add CLOCK_MONOTONIC case in clock_gettime() > > > > The Mach RPC host_get_uptime64() is implemented. It returns the e

Re: [RFC PATCH v3 1/1 Hurd]hurd: Add a libstore library without libparted

On Sat, Jan 11, 2025 at 11:39:46AM +0100, Samuel Thibault wrote: > Hello, Thanks for the review. > > Zhaoming Luo, le sam. 11 janv. 2025 12:56:33 +0800, a ecrit: > > diff --git a/libstore/Makefile b/libstore/Makefile > > index c7af958b..d0f06450 100644 > > --- a/

[RFC PATCH v3 1/1 Hurd]hurd: Add a libstore library without libparted

* Makefile: Add subdir libstore-noparted * libstore-noparted/Makefile: The Makefile for the new module * libstore/Makefile: Add conditionals so libstore-noparted can use it --- Makefile | 1 + libstore-noparted/Makefile | 6 ++ libstore/Makefile | 19 ++

[RFC PATCH v3 0/1] Add a libstore library without libparted

?= libstore ``` Zhaoming Luo (1): Add a libstore library without libparted Makefile | 1 + libstore-noparted/Makefile | 6 ++ libstore/Makefile | 19 +++ 3 files changed, 22 insertions(+), 4 deletions(-) create mode 100644 libstore-noparted

[RFC PATCH v2 Hurd] Add a libstore library without libparted

I haven't added `USE_PARTED` to exlcude the parted module, but I have added `?=` to `dir` and `libname` to factorize the Makefile. However, the libstore-noparted.so.0.3 file does not link to libparted. It is expected to link to libparted before I use `USE_PARTED` to exclude the parted module. The

Re: [RFC PATCH Hurd] Add a libstore library without libparted

On Thu, Jan 09, 2025 at 02:09:01PM +0100, Samuel Thibault wrote: > Hello, > > Zhaoming Luo, le jeu. 09 janv. 2025 20:58:22 +0800, a ecrit: > > The library can be compiled using the following command in the build/ > > directory: > > ``` > > make libstore-noparted

Re: [RFC PATCH Hurd] Add a libstore library without libparted

On 1/10/25 8:58 PM, Zhaoming Luo wrote: On Thu, Jan 09, 2025 at 02:09:01PM +0100, Samuel Thibault wrote: Apologize for it. I was testing the email client and forgot to remove Cc. Best, Zhaoming Hello, Zhaoming Luo, le jeu. 09 janv. 2025 20:58:22 +0800, a ecrit: The library can be compiled

Re: [RFC PATCH Hurd] Add a libstore library without libparted

On Thu, Jan 09, 2025 at 02:09:01PM +0100, Samuel Thibault wrote: > Hello, > > Zhaoming Luo, le jeu. 09 janv. 2025 20:58:22 +0800, a ecrit: > > The library can be compiled using the following command in the build/ > > directory: > > ``` > > make libstore-noparted

[RFC PATCH Hurd] Add a libstore library without libparted

The library can be compiled using the following command in the build/ directory: ``` make libstore-noparted ``` This file is the same as libstore/Makefile except a few modifications so it can use the source files from libstore/ and build a libstore with libparted module. --- Makefile

[RFC PATCH glibc v3] mach: Add CLOCK_MONOTONIC case in clock_gettime()

mach: Add CLOCK_MONOTONIC case in clock_gettime() The Mach RPC host_get_uptime64() is implemented. It returns the elapsed time value since bootup. See https://git.savannah.gnu.org/cgit/hurd/gnumach.git/commit/?id=fc494bfe3fb6363e1077dc035eb119970d84a9d1 In this patch, the RPC is used to implemen

Re: [RFC PATCH glibc v2 1/1] hurd: Add CLOCK_MONOTONIC case in clock_gettime()

Thanks for reviewing. On 1/3/25 6:52 PM, Sergey Bugaev wrote: On Fri, Jan 3, 2025 at 1:42 PM Zhaoming Luo wrote: hurd: Add CLOCK_MONOTONIC case in clock_gettime() Nitpick: the prefix should be "mach:" instead of "hurd:". In theory, there could be other targets that a

[RFC PATCH glibc v2 0/1] hurd: Add CLOCK_MONOTONIC case in clock_gettime()

submitting the 1/1 patch to glibc? I think the website mentions I need to mention my assignment form status. Not sure where to add it. Should I add it in cover-letter? Zhaoming Luo (1): hurd: Add CLOCK_MONOTONIC case in clock_gettime() config.h.in | 3 +++ sysdeps/mach

  1   2   3   >