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

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

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

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=0x103cc84) > at ../sysdeps/mach/hurd/select.c:31 > ``` > > When I continue, it hangs at mach_msg[0]: > > gdb

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

On Mon, Jan 27, 2025 at 12:18 AM Samuel Thibault wrote: > > + err = aarch64_get_hwcaps(mach_host_self(), &caps, &mdir, &revdir); > > + if (err) > > +goto out; > > + > > + implementer = (mdir & 0xff00) >> 24; > > + variant = (mdir & 0x00f0) >> 20; > > + architecture = (mdir &

Re: abseil port: strerror_r behaviour differs from Debian/Linux

On Sun, Jan 26, 2025 at 12:06 AM Diego Nieto Cid wrote: > Hello, Hello, > However, when running in GNU/Hurd, the output is a bit different: > > strerror_r: Error in unknown error system: So for some background: on the Hurd, Unix errors are unified with Mach error codes (see gnumach

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

On Sun, Jan 12, 2025 at 10:48 PM Samuel Thibault wrote: > Does the posted patch look fine to you? It does, so: Acked-by: Sergey Bugaev I'll test it some time later when I get around to doing more aarch64-gnu hacking :| Sergey

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

On Thu, Jan 9, 2025 at 6:18 PM Jessica Clarke wrote: > On 9 Jan 2025, at 15:12, Diego Nieto Cid wrote: > > Looking at the types.h header, I see there are HWCAP2_* definitions for > > bits above 32. Since hwcaps_t is an uint32_t and the defs file claims to > > return two values (I assume the first

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

On Thu, Jan 9, 2025 at 4:09 PM Samuel Thibault wrote: > > 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. > > Thanks for working on it. AIU

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

Hi, On Thu, Jan 9, 2025 at 1:42 AM Luca wrote: > >> maybe this can be already made arch-specific. > >> > > > > Hmm, maybe. As is it only makes sense for x86 based architectures. > > There was some work from Sergey towards porting to aarch64, I guess > currently the hurd should compile there, and

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

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 also run on Mach, and sysdeps/mach/clock_gettime.c is only Mach-specific, not Hurd-specifi

Re: [RFC PATCH glic] hurd: Add CLOCK_MONOTONIC case in clock_gettime()

On Fri, Jan 3, 2025 at 5:32 AM Zhaoming Luo wrote: > > in the latter case, you should get MIG_BAD_ID from the kernel, so you > > can detect that. > What's the best way to handle the MIG_BAD_ID case. I tried perror(NULL) > but it gave my output '(ipc/mig) bad request message ID'. To be honest I > d

Re: [RFC PATCH glic] hurd: Add CLOCK_MONOTONIC case in clock_gettime()

Happy New Year! On Wed, Jan 1, 2025 at 12:25 PM Zhaoming Luo wrote: > > --- > sysdeps/mach/clock_gettime.c | 12 > 1 file changed, 12 insertions(+) > > diff --git a/sysdeps/mach/clock_gettime.c b/sysdeps/mach/clock_gettime.c > index 6fffad39f5..22faf85730 100644 > --- a/sysdeps/mach

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

On Tue, Dec 31, 2024 at 1:30 AM Diego Nieto Cid wrote: > On Mon, Dec 30, 2024 at 07:08:55PM +0100, Samuel Thibault wrote: > > You also need to take into account the case where > > current->max_protection was NONE and new_prot is not NONE, you then have > > to decrease size_none. > Ah right, the &

Re: [hurd-amd64] ibus test failures

Hello, On Mon, Dec 30, 2024 at 3:36 AM Diego Nieto Cid wrote: > > On Sun, Dec 29, 2024 at 11:33:47PM +0100, Samuel Thibault wrote: > > Hello, > > > > Diego Nieto Cid, le dim. 29 déc. 2024 22:14:40 +, a ecrit: > > > (ibus-daemon:17123): GLib-GIO-WARNING **: 20:49:29.230: Expected a > > >

Re: [PATCH hurd] pci-arbiter: Fix long standing bug with PCI access

On Sat, Dec 28, 2024 at 9:38 AM Damien Zammit via Bug reports for the GNU Hurd wrote: > > Proxied memory was not rounded up to page size, causing > error with vm_map'ing the underlying memory. > > WARNING: Could be security risk if assumption is incorrect: > Assumes start of all pci memory resour

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

Merry Christmas :) On Tue, Dec 24, 2024 at 8:11 PM Diego Nieto Cid wrote: > * HOST_PORT must be the privileged host control port > * if the caller desires to increase the current max limit. > * > * On the other hand, if the max limit is being decreased, the >

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

Getting really close :) On Mon, Dec 23, 2024 at 10:07 PM wrote: > + > +/* > + * Set a task virtual memory limit parameters > + */ > +routine vm_set_size_limit( > + host_port : mach_port_t; > + map : vm_task_t; > + current_limit : vm_size_t; > + max_limit

Re: [RFC] Implementing RLIMIT_AS

On Sun, Dec 22, 2024 at 1:45 PM Samuel Thibault wrote: > > FWIW, this means that the caller would be potentially sending the host > > priv port to someone who's not necessarily the kernel. That's fine if > > we're acting on mach_task_self (since if someone is interposing our > > task port, we can

Re: [RFC] Implementing RLIMIT_AS

On Sun, Dec 22, 2024 at 6:11 AM Diego Nieto Cid wrote: > I just didn't understand the hard/soft limits. It's better described > by the structure members and not the comments: > > struct rlimit { > rlim_t rlim_cur; /* Soft limit */ > rlim_t rlim_max; /* Hard limit (ceiling for

Re: [RFC] Implementing RLIMIT_AS

On Fri, Dec 20, 2024 at 5:17 PM Diego Nieto Cid wrote: > >Also make sure to avoid limiting the kernel's own maps. > > Oh right, I need to check for the kernel map, even though the default > means no limit it may be nice to check at the enforcing point whether > the allocation happens against the k

Re: [RFC] Implementing RLIMIT_AS

On Thu, Dec 19, 2024 at 6:56 PM Diego Nieto Cid wrote: > Hello, Hi, a few pointers from me: > I started with hard limit beacause I still need to research how > soft limits work. So, for now, it's a plain rejection with ENOMEM. > > 2. At vm_map_setup, initialize the `hard_limit` fiel

Re: [PATCH 1/1 Web] Add microkernel/mach/mig/documentation/mig-mutate page

On Thu, Dec 12, 2024 at 6:14 PM wrote: > #stillFriendsRight? Totally! I'm just hoping I didn't offend you or something. And please keep up the good work on docs, just... not that way :) Sergey

Re: [PATCH 1/1 Web] Add microkernel/mach/mig/documentation/mig-mutate page

On Wed, Dec 11, 2024 at 11:58 PM Samuel Thibault wrote: > jbra...@dismail.de, le mer. 11 déc. 2024 20:46:54 +, a ecrit: > > Sergey, are you ok with "assigning copyright" to the FSF for this document? > > Sergey has already assigned copyright for all past&future hurd > contributions. Uh. I ass

Re: [PATCH 3/3] intr: Protect internals with a lock

On Tue, Dec 10, 2024 at 3:19 PM Samuel Thibault wrote: > Sergey Bugaev, le mar. 10 déc. 2024 14:57:05 +0300, a ecrit: > > @@ -103,11 +105,15 @@ queue_intr (struct irqdev *dev, int id, user_intr_t > > *e) > > * disabled. Level-triggered interrupts would k

[PATCH 2/3] linux: Fix building with C23

7;true' and 'false' being valid values of the type. Signed-off-by: Sergey Bugaev --- Only compile-tested. linux/src/drivers/scsi/BusLogic.h | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/linux/src/drivers/scsi/BusLogic.h b/linux/src/drivers/scsi/BusLogic.h

[PATCH 3/3] intr: Protect internals with a lock

ternals of device/intr with a simple_lock_irq. Reported-by: Damien Zammit Signed-off-by: Sergey Bugaev --- With this, Damien's latest patchset, and "smp: Create AP processor set and put all APs inside it" reverted, a complete Debian GNU/Hurd system boots for me in QEMU with -smp

[PATCH 1/3] Fix various function pointer types

Fixes Wincompatible-pointer-types errors on GCC 15. Signed-off-by: Sergey Bugaev --- ddb/db_variables.h | 2 +- i386/i386/trap.c | 2 +- vm/vm_fault.c | 4 ++-- vm/vm_map.c| 2 +- vm/vm_map.h| 8 5 files changed, 9 insertions(+), 9 deletions(-) diff --git a/ddb

Re: [PATCH 6/6 gnumach] i386/apic: Fix condition on non-BSP

On Tue, Dec 10, 2024 at 12:40 AM Samuel Thibault wrote: > Applied, thanks! FWIW, I noticed that the last few commits from Damien have "Damien Zammit via Bug reports for the GNU Hurd " listed as the Git commit author. Sergey

Re: [PATCH Hurd] lwip: Properly handle errors during initialization

On Sun, Dec 8, 2024 at 11:54 AM Zhaoming Luo wrote: > > Reviewed-by: Sergey Bugaev > > > Thanks for the review. > > (...but I don't know exactly what you're supposed to do with that R-b > > line. I asked on libc-alpha last year [0], and didn't get

Re: [PATCH Hurd] lwip: Properly handle errors during initialization

On Sun, Dec 8, 2024 at 7:53 AM Zhaoming Luo wrote: > lwip/main.c | 10 -- > 1 file changed, 4 insertions(+), 6 deletions(-) Makes sense to me, thanks! Reviewed-by: Sergey Bugaev (...but I don't know exactly what you're supposed to do with that R-b line. I asked on

Re: [util-linux PATCH] Support hwclock for GNU Hurd

On Thu, Dec 5, 2024 at 3:39 PM Zhaoming Luo wrote: > - rtc_dev_fd = open(rtc_dev_name, O_RDONLY); > + rtc_dev_fd = open(rtc_dev_name, O_RDONLY | O_WRONLY); It's called "xxx-only" for a reason :) On standard Unix, you should use O_RDWR for this. Now, on the Hurd, these

[PATCH] libstore: Fix zero store writes

We discard any written data, but we still need to set *amount. Not doing that is undefined behavior, and causes the write to appear to fail. This is the cause of a libzstd test failure on GNU/Hurd in particular. Reported-by: Diego Nieto Cid Signed-off-by: Sergey Bugaev --- Note: not tested

[PATCH] hurd: Protect against servers returning bogus read/write lengths

n the size actually submitted to it, which is a separate bug to be fixed on the Hurd side. With this patch, EGRATUITOUS is now propagated to the caller. Reported-by: Diego Nieto Cid Signed-off-by: Sergey Bugaev --- hurd/fd-read.c | 12 +++- hurd/fd-write.c | 10 +++--- 2 files c

Re: libzstd :: non-regular file test failure

On Wed, Dec 4, 2024 at 11:26 AM Samuel Thibault wrote: > It's probably worth checking other _write methods in libstore/ That, and also glibc should make more efforts to be resilient against servers returning bogus read/write amounts, whether by mistake like here or maliciously. If we don't saniti

Re: libzstd :: non-regular file test failure

On Wed, Dec 4, 2024 at 12:11 AM Diego Nieto Cid wrote: > 52<--47(pid1044)->io_write_request ("Hello World!\n" -1) = 0 15 On Wed, Dec 4, 2024 at 4:50 AM Diego Nieto Cid wrote: > I traced it to the function `io_write` from `libhurduser.so.3` which > is returning 1. On Wed, Dec 4, 2024 at 6:09

Re: [PATCH hurd] sutils: Add smp tool for running a process on slave processors

Hi, a quick review: On Tue, Nov 26, 2024 at 10:43 AM Damien Zammit via Bug reports for the GNU Hurd wrote: > +static void > +smp(char * const argv[]) Style nitpick: space before the paren. > +{ > + int err; error_t rather > + unsigned int pset_count; mach_msg_type_number_t rather (it's lik

Re: x86_64-gnu 14.2.0 cross-compiler -O2 removes THREAD_SETMEM in glibc sigreturn.c

On Sun, Nov 24, 2024 at 3:58 PM Andreas Schwab wrote: > > https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Goto-Labels > > > > “ > > GCC assumes that asm execution falls through to the next statement (if > > this is not the case, consider using the __builtin_unreachable intrinsic > > after the

Re: x86_64-gnu 14.2.0 cross-compiler -O2 removes THREAD_SETMEM in glibc sigreturn.c

Reduced further: --8<-- struct hurd_sigstate; typedef struct { void *tcb; union dtv *dtv; unsigned int self_do_no_use; int __glibc_padding1; int multiple_threads; int gscope_flag; unsigned long sysinfo; unsigned long stack_guard; unsigned long pointer_guard; long __glibc_p

Re: findutil's gnulib-test's test-sigaction's raise fails with Guix' libc

On Fri, Nov 22, 2024 at 5:11 PM wrote: > Sounds awfully familiar...so is this a compiler bug? What, did you think if was *my* code that's broken? :D :D :D > How should I go > forward here? Most importantly, please report this to GCC developers. You could use the preprocessed source so they don

Re: findutil's gnulib-test's test-sigaction's raise fails with Guix' libc

On Fri, Nov 22, 2024 at 4:28 PM wrote: > using the (amazing) command-line that glibc creates > > --8<---cut here---start->8--- > $ x86_64-pc-gnu-gcc ../sysdeps/mach/hurd/x86_64/sigreturn.c -c -std=gnu11 > -fgnu89-inline -g -O2 -Wall -Wwrite-strings -Wundef -fm

Re: findutil's gnulib-test's test-sigaction's raise fails with Guix' libc

On Fri, Nov 22, 2024 at 1:52 PM wrote: > Hi! Hi Janneke, > I have bisected the problem to be in sigaction.o: when linking with > sigaction.o from Debian's libcrt.a it passes, when using Guix's > sigaction.o it fails. Problem solved, you would say? I assume you mean sigreturn.o, not sigaction.o

Re: [RFC PATCH] Add rtc server, rtc-read and rtc-set operations

On Tue, Nov 19, 2024 at 12:08 PM Samuel Thibault wrote: > Ah, yes. Since it's not a performance-critical service, you can as well > use ports_manage_port_operations_one_thread instead, and get done with > it :) This might be an issue once we implement the blocking read/select functionality; don't

Re: [RFC PATCH] Add rtc server, rtc-read and rtc-set operations

On Sun, Nov 17, 2024 at 3:34 PM Zhaoming Luo wrote: > Hi, Hi, looks nice to me overall, thanks for working on this! I cannot judge the actual driver part, so here are some nitpicks about not following the GNU code style :D I will try to build and test it later. By the way: apparently gnumach al

Re: [RFC PATCH] Adding RTC device (work in progress)

On Fri, Nov 8, 2024 at 3:26 AM Zhaoming Luo wrote: > The rest of the stuff > is mainly about filling codes into the server-side functions; it may > require some time as I haven't had any experience of writing drivers. Me neither :) But, perhaps the following would be somewhat useful. The osdev w

Re: [RFC PATCH v2 4/4] Add rtc server

On Fri, Nov 8, 2024 at 4:55 AM Zhaoming Luo wrote: > diff --git a/rtc/main.c b/rtc/main.c > new file mode 100644 > index ..114fb497 > --- /dev/null > +++ b/rtc/main.c > @@ -0,0 +1,88 @@ > + > +#include > + > +#include > +#include > +#include I don't think you need nullauth.h? > +#inc

Re: [RFC PATCH v2 2/4] Add ioctl interface for rtc device

Hi Zhaoming, On Fri, Nov 8, 2024 at 11:01 AM Samuel Thibault wrote: > Here as well this breaks the build since at this point of the series you > haven't added rtc.h yet. Better just merge all the patches. To expand on what Samuel says, the point is that the repo is expected to build successfully

Re: [RFC PATCH] Adding RTC device (work in progress)

On Wed, Nov 6, 2024 at 4:28 AM Zhaoming Luo wrote: > I think it's worth to put this part into mig documentation website[0], > just like the IRC log pieces we have already had. What do you think? I > can do it. > > [0]: > https://darnassus.sceen.net/~hurd-web/microkernel/mach/mig/documentation/ Su

Re: [RFC PATCH] Adding RTC device (work in progress)

On Sun, Nov 3, 2024 at 11:19 AM Zhaoming Luo wrote: > >> +import "rtc.h"; > > This would only work when the generated C file is built in the rtc/ of > > the Hurd source tree, right? Perhaps this should be ? > It makes sense, and I have corrected it. However, then the compilation > will fail with:

Re: [RFC: drm server] limitations of MiG for ioctls

On Tue, Nov 5, 2024 at 10:16 AM Yuqian Yang wrote: > > 1. the ioctl ID encoding space is fully used already -- all the bits > > in an ioctl ID are meaningful, so there'd be nowhere to pack the new > > info; > > What does this mean? So we can't create new ioctl op and args for drm > with the same v

Re: [RFC: drm server] limitations of MiG for ioctls

On Mon, Nov 4, 2024 at 10:44 AM Damien Zammit wrote: > I am currently attempting to implement a drm server to provide > a way to use libdrm with multiboot framebuffer exposed by new device(mbinfo). > > I am running into a problem that I am unable to implement a compatible > ioctl api because of the

Re: [RFC PATCH] Adding RTC device (work in progress)

On Fri, Nov 1, 2024 at 2:46 PM Zhaoming Luo wrote: > diff --git a/hurd/pioctl.defs b/hurd/pioctl.defs > new file mode 100644 > index ..36fa8d3f > --- /dev/null > +++ b/hurd/pioctl.defs > @@ -0,0 +1,34 @@ > +/* Definitions for /dev/rtc ioctls */ > + > +/* Ioctl group 'p'; the subsystem is d

Re: [RFC PATCH 0/3] Adding /dev/rtc device (work in progress)

On Fri, Nov 1, 2024 at 1:46 PM Zhaoming Luo wrote: > Send this email? ([y]es|[n]o|[e]dit|[q]uit|[a]ll): y > 250 OK > ...propagated at /usr/lib/git-core/git-send-email line 1696, > line 2. Hm, I have no idea about this kind of thing. git-send-email line 1696 in my copy of Git v2.47.0 is just

Re: [RFC PATCH 0/3] Adding /dev/rtc device (work in progress)

On Fri, Nov 1, 2024 at 1:30 PM Zhaoming Luo wrote: > I think it's a good chance to stop > and gather some suggestions and feedback, so I sent a series of RTC patches. Hi Zhaoming, I'm only seeing a single "patch", namely this cover letter. Did you perhaps accidentally run your git send-email on

Re: Using tm_t in a defs file

On Mon, Oct 28, 2024 at 9:35 AM Zhaoming Luo wrote: > I see, so _IOR is a wrapper of _IOC for calculating an ioctl number. > This ioctl number is used for invoking the routine in the rtc server. We > need to define _IOT_rtc_time because calculating RTC_RD_TIME requires > the ioctl number of rtc, _

Re: Using tm_t in a defs file

On Sun, Oct 27, 2024 at 3:02 PM Zhaoming Luo wrote: > I didn't develop it in-tree because I haven't figure out how to write a > Makefile for an in-tree server. I haven't found a reference or document > for me to learn writing it. Any recommendations? Maybe I should write > one based on the Makefil

Re: Using tm_t in a defs file

On Sun, Oct 27, 2024 at 11:46 AM Zhaoming Luo wrote: > Hi, Hi Zhaoming, > I did the following things in a Debian/Hurd virtual machine. > > I was following this link > > to implement a rtc server. My idea is that I should im

Re: More thinking about adding /dev/rtc

On Sat, Oct 26, 2024 at 5:45 AM Zhaoming Luo wrote: > Hi, Hi, > - Which server should have the implementation pioctl-ops.c, pfinet or > lwip? /dev/rtc is the Real Time Clock device, right? If so, it has nothing to do with the TCP/IP stack, in either of the two implementations (pfinet or lwip).

Re: [PATCH Hurd]: adding a missing comment

On Fri, Oct 25, 2024 at 9:50 AM Samuel Thibault wrote: > Zhaoming Luo, le ven. 25 oct. 2024 10:43:29 +0800, a ecrit: > > it seems a bit unreliable (last commit is 7 months ago). > > Last commit not being that recent does not mean it's unreliable: it > possibly just works and doesn't need updates.

Re: Error building Hurd on an existing Hurd

On Mon, Oct 21, 2024 at 9:53 PM Samuel Thibault wrote: > Ah ok. > > Yes :) Good :) > He said we was using > > https://mail.gnu.org/archive/html/bug-hurd/2023-01/msg00132.html I admit I didn't follow the link in the original message... Those are my notes about bootstrapping a toolchain & cross-c

Re: Error building Hurd on an existing Hurd

On Mon, Oct 21, 2024 at 9:38 PM Samuel Thibault wrote: > Sergey Bugaev, le lun. 21 oct. 2024 14:47:10 +0300, a ecrit: > > You must > > have a fresh enough MIG build (that already generates references to > > mach_port_name_inlined_t), but older gnumach headers (that

Re: Error building Hurd on an existing Hurd

On Mon, Oct 21, 2024 at 9:21 AM Zhaoming Luo wrote: > Hi, Hi, > I am trying to build Hurd (76419b67...) from source on an existing Hurd. I > found this post. However, when I tried ./configure && make, I got the > following error: > > default_pagerUser.c: In function 'default_pager_object_creat

Re: [web:add translator pages 12/15] add translator/devnode page.

On Thu, Oct 17, 2024 at 7:28 AM Amos Jeffries wrote: > I would guess that means it provides access to system devices under the > path "/dev" ? What it does is it exposes a Mach device as a filesystem node (hence "devnode"), so you can do open("/dev/foobar") instead of device_open("foobar"). In pa

Re: Qoth Q3 2024 & on aarch64-gnu

On Tue, Sep 24, 2024 at 4:53 AM wrote: > I'm game to try! How would I go about setting up a vm AArch64 image that > > runs the Hurd? It's not much different from building a Hurd image for another architecture (i686 or x86_64), other than having to use some unmerged branches. You should start by

[PATCH] hurd: Avoid file_check_access () RPC for access (F_OK)

GLib switching to use faccessat (F_OK) to implement g_file_query_exists () for local files. https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4272 Signed-off-by: Sergey Bugaev --- sysdeps/mach/hurd/faccessat.c | 9 + 1 file changed, 9 insertions(+) diff --git a/sysdeps/mach/hurd

Re: [PATCH gnumach 2/3] add tests for FLOAT/XFLOAT state

On Wed, Aug 21, 2024 at 7:37 PM Luca Dariz wrote: > +#include > + > +static void printx(struct i386_xfloat_state *state, int size) > +{ > + printf("xfloat init %d fp %d exc %d\n", > + state->initialized, state->fpkind, state->exc_status); > + struct i386_xfp_save *xfp = (struct i386_xfp

Re: [PATCH] add xfloat thread state interface

On Mon, Aug 5, 2024 at 9:23 PM Samuel Thibault wrote: > Luca Dariz, le lun. 05 août 2024 14:52:24 +0200, a ecrit: > > Il 05/08/24 00:32, Samuel Thibault ha scritto: > > > Luca Dariz, le ven. 02 août 2024 17:32:34 +0200, a ecrit: > > > > +#define XFP_STATE_BYTES (sizeof (struct i386_xfp_save)) > >

Re: [PATCH glibc] Add pthread_getname_np and pthread_setname_np for Hurd

Hi Flavio, in general, what's this useful for? Debugging, maybe? Do you expect the process itself to query its threads' names locally, or do you expect another process (GDB) to issue thread_get_name remotely? On Wed, Jul 10, 2024 at 7:04 PM Flavio Cruz wrote: > diff --git a/htl/pt-internal.h b/

Re: Come watch a live stream coding session for the Hurd Video

On Sun, Jun 2, 2024 at 12:22 AM Joshua Branson wrote: > So we had an awesome time today watching Sergey code a trivial translator (1) > and do > some glibc hacking (2). Sergey coded and chatted for 4 and 1/2 hours! Three > cheers > for that kind of commitment! Thanks pal! > > In the livestrea

Re: Come watch a live stream coding session for the Hurd

Hi, On Fri, May 31, 2024 at 3:18 PM Almudena Garcia wrote: > Other idea could be a magnet/torrent translator > > wget magnet:?fl=http://... > > and downloading the torrent file without a torrent client bittorrentfs would be cool indeed, and it's something that I wanted to write for a long time a

Re: [PATCH 9/9] Add a test for thread state

On Tue, Apr 16, 2024 at 4:01 AM Samuel Thibault wrote: > Ah, no, I mis read the result. It does stay stuck on x86_64. Indeed, thanks. Reproduced and fixed; I was accidentally using rsp (instead of ursp) in one place. Sergey -- >8 -- This tests generating and handling exceptions, thread_get_sta

Re: [RFC PATCH 03/23] Allow glibc to be compiled without EXEC_PAGESIZE

Hello, On Wed, Apr 10, 2024 at 2:57 PM Florian Weimer wrote: > * Sergey Bugaev: > > > We could define EXEC_PAGESIZE to some conservative value on > > aarch64-gnu too, if it turns out that this little workaround is really > > required. But it seems cleaner to make s

[PATCH 9/9] Add a test for thread state

This tests generating and handling exceptions, thread_get_state(), thread_set_state(), and newly added thread_set_self_state(). It does many of the same things that glibc does when handling a signal. --- Note that I only tested this on i386 and AArch64, not on x86_64. tests/test-thread-state.c |

[PATCH 3/9] aarch64: Add public syscall ABI

We use largely the same ABI as Linux: a syscall is invoked with the "svc #0" instruction, passing arguments the same way as for a regular function call. Specifically, up to 8 arguments are passed in the x0-x7 registers, and the rest are placed on the stack (this is only necessary for the vm_map()

[PATCH 5/9] aarch64: Add mach_aarch64 API

This currently contains a single RPC to get Linux-compatible hwcaps, as well as the values of MIDR_EL1 and REVIDR_EL1 system registers. In the future, this is expected to host the APIs to manage PAC keys, and possibly some sort of AArch64-specific APIs for userland IRQ handlers. --- aarch64/Makef

[PATCH 6/9] aarch64: Add exception type definitions

A few yet-unimplemented codes are also sketched out; these are included so you know roughly what to expect once the missing functionality gets implemented, but are not in any way stable or usable. --- aarch64/Makefrag.am | 1 + aarch64/include/mach/aarch64/exception.h | 90 ++

[PATCH 8/9] Add thread_set_self_state() trap

This is a new Mach trap that sets the calling thread's state to the passed value, as if with a call to the thread_set_state() RPC. If the flavor of state being set is the one that contains the register used for syscall return value (i386_THREAD_STATE or i386_REGS_SEGS_STATE on x86, AARCH64_THREAD_

[PATCH 7/9] aarch64: Add thread state types

Notes: * TPIDR_EL0, the TLS pointer, is included in the generic state directly. * TPIDR2_EL0, part of the SME extension, is not included in the generic state. If we add SME support, it will be a part of something like aarch64_sme_state. * CPSR is not a real register in AArch64 (unlike in AArch

[PATCH 2/9] aarch64: Add the basics

This adds "aarch64" host support to the build system, along with some uninteresting installed headers. The empty aarch64/aarch64/ast.h header is also added to create the aarch64/aarch64/ directory (due to Git peculiarity). With this, it should be possible to run 'configure --host=aarch64-gnu' and

[PATCH 0/9] AArch64 Mach public headers

Hello! This patchset contains public headers for AArch64 support in GNU Mach, along with just enough buildsystem infrastructure to recognize and install them. It is quite similar to the "sketch" patches that I have posted in January of this year, but I have done a number of changes for two reasons

[PATCH 4/9] aarch64: Add vm_param.h

And make it so that the generic vm_param.h doesn't require the machine- specific one to define PAGE_SIZE etc. We *don't* want a PAGE_SIZE constant to be statically exported to userland; instead userland should initialize vm_page_size by querying vm_statistics(), and then use vm_page_size. We'd al

[PATCH 1/9] Add CPU_TYPE_ARM64

This is distinct from CPU_TYPE_ARM, since we're going to exclusively use AArch64 / A64, which CPU_TYPE_ARM was never meant to support, and to match EM_AARCH64, which is also separate from EM_ARM. CPU_TYPE_X86_64 was similarly made distinct from CPU_TYPE_I386. This is named CPU_TYPE_ARM64 rather t

Re: [PATCH v2 2/3] aarch64: Add support for aarch64-gnu (GNU/Hurd on AArch64)

On Tue, Apr 9, 2024 at 7:24 PM Palmer Dabbelt wrote: > > I assume the buildbot failure that I just got an email about is > > unrelated; it's failing on some RISC-V thing. > > Sorry if I missed something here, do you have a pointer? The buildbot failure emails reference [0] and [1]. [0]: https://

Re: [PATCH v2 2/3] aarch64: Add support for aarch64-gnu (GNU/Hurd on AArch64)

On Tue, Apr 9, 2024 at 10:27 AM Thomas Schwinge wrote: > Thanks, pushed to trunk branch: > > - commit 532c57f8c3a15b109a46d3e2b14d60a5c40979d5 "Move GNU/Hurd startfile > spec from config/i386/gnu.h to config/gnu.h" > - commit 9670a2326333caa8482377c00beb65723b7b4b26 "aarch64: Add support for

[PATCH 1/3] vm: Fix use-after-free in vm_map_pageable_scan()

When operating on the kernel map, vm_map_pageable_scan() does what the code itself describes as "HACK HACK HACK HACK": it unlocks the map, and calls vm_fault_wire() with the map unlocked. This hack is required to avoid a deadlock in case vm_fault or one of its callees (perhaps, a pager) needs to al

[PATCH 2/3] vm: Don't attempt to extend in-transition entries

The in-transition mechanism exists to make it possible to unlock a map while still making sure some VM entries won't disappear from under you. This is currently used by the VM copyin mechanics. Entries in this state are better left alone, and extending/coalescing is only an optimization, so it mak

[PATCH 3/3] vm: Mark entries as in-transition while wiring down

When operating on the kernel map, vm_map_pageable_scan() does what the code itself describes as "HACK HACK HACK HACK": it unlocks the map, and calls vm_fault_wire() with the map unlocked. This hack is required to avoid a deadlock in case vm_fault or one of its callees (perhaps, a pager) needs to al

Re: [PATCH v2 2/3] aarch64: Add support for aarch64-gnu (GNU/Hurd on AArch64)

Hello, On Tue, Apr 2, 2024 at 8:26 PM Richard Sandiford wrote: > I don't know if you're waiting on me, but just in case: this and patch 3 > still LGTM if Thomas is OK with them. Thanks. Thomas asked me to resubmit with Changelog entries added (but hasn't pointed out anything else), so this is wa

[PATCH mig 2/2] Add support for MACH_MSG_TYPE_COPY_SEND_ONCE

--- cpu.sym | 2 ++ lexxer.l | 1 + 2 files changed, 3 insertions(+) diff --git a/cpu.sym b/cpu.sym index 1ac2fae..fe208c9 100644 --- a/cpu.sym +++ b/cpu.sym @@ -69,6 +69,8 @@ expr MACH_MSG_TYPE_COPY_SEND expr MACH_MSG_TYPE_MAKE_SEND /* Must hold receive rights */ expr MACH_MSG_TYPE_MAKE_SEND

[PATCH gnumach 1/2] Add MACH_MSG_TYPE_COPY_SEND_ONCE

Mach allows messages to carry port rights along with data; the rights contained in a message are transferred from the sender's IPC space to the receiver. The sender has to specify exactly how a right that the message will carry is to be created from the right(s) that the sender holds: in particula

Re: [PATCH] elf-load: Respect PT_GNU_STACK

On Wed, Mar 27, 2024 at 9:37 PM Samuel Thibault wrote: > But it's not getting used anywhere? Indeed, I forgot to extract the kern/bootstrap.c part of the change. Ooops :) Thanks for pointing it out. Sergey -- >8 -- If a bootstrap ELF contains a PT_GNU_STACK phdr, take stack protection from the

[PATCH 16/17] tests: Don't ask for executable stack

--- tests/start.S| 2 ++ tests/syscalls.S | 2 ++ 2 files changed, 4 insertions(+) diff --git a/tests/start.S b/tests/start.S index b795bfbd..15970fb9 100644 --- a/tests/start.S +++ b/tests/start.S @@ -26,3 +26,5 @@ _start: movq%rsp,%rdi callq c_start #endif /* __x86_

[PATCH 00/17] Preparatory patches

These are generic, relatively independent patches from the AArch64 branch. I've done a quick build for i386-gnu and things still seem to build, but please test! Sergey

[PATCH 04/17] Load 64-bit ELFs on all 64-bit ports

Not only on x86_64. --- include/mach/exec/elf.h | 4 ++-- kern/exception.c| 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/include/mach/exec/elf.h b/include/mach/exec/elf.h index 42920e25..55304496 100644 --- a/include/mach/exec/elf.h +++ b/include/mach/exec/elf.h @@

[PATCH 02/17] Disable host_kernel_version() everywhere but on i386

It's not only x86_64, none of new architectures are going to have it. --- include/mach/mach_host.defs | 6 +++--- kern/host.c | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/include/mach/mach_host.defs b/include/mach/mach_host.defs index a8c40af6..8fd9d6b3

[PATCH 01/17] elf-load: Respect PT_GNU_STACK

If a bootstrap ELF contains a PT_GNU_STACK phdr, take stack protection from there. Otherwise, default to VM_PROT_ALL. --- include/mach/exec/elf.h | 1 + include/mach/exec/exec.h | 2 ++ kern/elf-load.c | 7 +++ 3 files changed, 10 insertions(+) diff --git a/include/mach/exec/elf.h

[PATCH 17/17] tests: Create tests/ in the build tree before trying to use it

--- tests/user-qemu.mk | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/user-qemu.mk b/tests/user-qemu.mk index fd5ae1ab..4f8390b6 100644 --- a/tests/user-qemu.mk +++ b/tests/user-qemu.mk @@ -130,6 +130,7 @@ SRC_TESTLIB= \ $(MIG_GEN_CC) tests/errlist.c: $(addprefix $(srcdir)/in

[PATCH 05/17] gsync: Use copyin()/copyout() to access user memory

Depending on the architecture and setup, it may not be possible to access user memory directly, for example, due to user mode mappings not being accessible from kernel mode (x86 SMAP, AArch64 PAN). There are dedicated machine-specific copyin()/copyout() routines that know how to access user memory

[PATCH 07/17] kern/rdxtree: Fix undefined behavior

Initializing a variable with itself is undefined, and GCC 14 rightfully produces a warning about the variable being used (to initialize itself) prior to initialization. X15 sets the variables to 0 instead, so do the same in Mach. --- kern/rdxtree.c | 4 ++-- 1 file changed, 2 insertions(+), 2 dele

[PATCH 12/17] tests: Add a more serious mach_msg_server() routine

--- tests/include/testlib.h | 16 ++ tests/test-syscalls.c | 40 + tests/testlib.c | 123 3 files changed, 142 insertions(+), 37 deletions(-) diff --git a/tests/include/testlib.h b/tests/include/testlib.h index cdb2ce13..d236712

[PATCH 11/17] tests: Fix halt()

Mark it as noreturn, and make sure to halt, not reboot. --- tests/include/testlib.h | 2 +- tests/testlib.c | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/tests/include/testlib.h b/tests/include/testlib.h index a3f3a6a8..cdb2ce13 100644 --- a/tests/include/testlib.

[PATCH 15/17] tests: Make exception subcode a long

--- tests/test-syscalls.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/test-syscalls.c b/tests/test-syscalls.c index 63c2690a..fbfecd9c 100644 --- a/tests/test-syscalls.c +++ b/tests/test-syscalls.c @@ -34,7 +34,7 @@ static struct { mach_port_t task; integer_t ex

  1   2   3   4   5   6   7   8   9   >