Re: [cross] building gdb for the 64bit Hurd?

Hi Janneke On Thu, Nov 14, 2024 at 12:44 PM wrote: > Hi! > > I'm trying to build gdb-15.2 for the 64bit Hurd using this patch > > > > Some context: Although the Guix 64bit Hurd now boots (yay!), a > statically linked tar han

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

Hello Damien On Mon, Nov 4, 2024 at 2:44 AM Damien Zammit via Bug reports for the GNU Hurd wrote: > Hi, > > 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 u

Re: [PATCH] Include device/input.h in console-client

Hi Samuel On Sun, Sep 8, 2024 at 6:12 PM Samuel Thibault wrote: > Applied, thanks! > I think we want to revert this since this header is not being installed anymore (it was exporting a custom version of the macros _IO{,R,W,WR}) https://git.savannah.gnu.org/cgit/hurd/gnumach.git/commit/?id=7e0b

Re: guix rumpkernel package fails to build from latest

Hello On Fri, Jul 19, 2024 at 11:06 PM Nathan Dehnel wrote: > # compile libpci/gnumachUser.o > /tmp/guix-build-rumpkernel-1.8-head-HEAD.8a3a6c9.drv-0/source/ > buildrump.sh/src/./obj/tooldir/bin/i486--netbsdelf-gcc > -o > gnuma

Re: [PATCH mig] Suffix complex_alignof with U to hint the compiler that it is always unsigned

On Thu, Jul 18, 2024 at 5:41 PM Almudena Garcia wrote: > do this means that you are updating rumpkernel sources? I tried to update > rumpdisk sources some months ago, but i had problems with the Hurd patches. > No. The user stubs are generated automatically by the build process using mig. El ju

Re: [PATCH] server: Fix bogus port deallocation on server error

On Sun, Jul 14, 2024 at 5:13 PM Samuel Thibault wrote: > Samuel Thibault, le dim. 14 juil. 2024 18:11:40 +0200, a ecrit: > > Samuel Thibault, le dim. 14 juil. 2024 18:06:22 +0200, a ecrit: > > > Samuel Thibault, le dim. 14 juil. 2024 17:42:51 +0200, a ecrit: > > > > Flavio Cruz, le dim. 14 juil.

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

On Wed, Jul 10, 2024 at 9:31 PM Samuel Thibault wrote: > Sergey Bugaev, le mer. 10 juil. 2024 21:07:21 +0300, a ecrit: > > 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? > > We'll want e.g. gd

Re: [PATCH v2] Port GDB to Hurd x86_64.

On Tue, Feb 27, 2024 at 11:15 PM John Baldwin wrote: > On 2/23/24 9:28 PM, Flavio Cruz wrote: > > This port extends the existing i686 port to support x86_64 by trying to > > reuse existing code whenever it makes sense. > > > > * gdb/amd64-gnu-tdep.c: Adds logic for handling signal frames and > >

Re: [PATCH] Hurd port: update interface to match upstream and fix warnings.

Hi Simon On Wed, Feb 7, 2024 at 5:01 PM Samuel Thibault wrote: > Simon Marchi, le mer. 07 févr. 2024 11:47:30 -0500, a ecrit: > > On 2/7/24 01:53, Flavio Cruz wrote: > > > We have recently updated the interface for raising exceptions to use > > > long [1] and updated mach_port_t to be "unsigned

Re: [PATCH hurd] rumpdisk: do not open device if block size is 0

On Sun, Mar 3, 2024 at 10:39 AM Samuel Thibault wrote: > Flávio Cruz, le jeu. 29 févr. 2024 22:01:41 -0500, a ecrit: > > On Thu, Feb 29, 2024 at 7:29 PM Samuel Thibault <[1] > samuel.thiba...@gnu.org> > > wrote: > > > > I could be wrong but if yo

Re: [PATCH hurd] rumpdisk: do not open device if block size is 0

On Thu, Feb 29, 2024 at 7:29 PM Samuel Thibault wrote: > Applied, thanks! > > Flavio Cruz, le mer. 28 févr. 2024 22:39:10 -0500, a ecrit: > > The computer seems to get stuck, caused by the divide by 0 in the > > rumpdisk server in device_get_status. I noticed that if we have no disk > in the > >

Re: [PATCH hurd] Add proc_getchildren_rusage RPC and track rusage for children and descendants

Thanks for the reviews, Samuel! Did you forget to push this change? :) On Fri, Feb 16, 2024 at 8:24 PM Samuel Thibault wrote: > Applied, thanks! > > Flavio Cruz, le ven. 16 févr. 2024 13:26:29 -0500, a ecrit: > > --- > > hurd/process.defs | 6 ++ > > proc/info.c | 8 > > proc

Re: [PATCH binutils-gdb] Port GDB to Hurd x86_64.

On Thu, Feb 8, 2024 at 7:09 PM Samuel Thibault wrote: > Flavio Cruz, le dim. 04 févr. 2024 01:43:48 -0500, a ecrit: > > +/* Recognizing signal handler frames. */ > > + > > +/* When the GNU/Hurd libc calls a signal handler, the return address > points > > + inside the trampoline assembly snippe

Re: [PATCH gnumach] Add vm_pages_phys

On Tue, Jan 30, 2024 at 1:38 AM Sergey Bugaev wrote: > Hello, > > On Mon, Jan 29, 2024 at 11:59 PM Samuel Thibault > wrote: > > Please notably review the RPC part, I really don't know that much about > > mig. > > Some nitpicks inline. Flávio, does what I'm saying below make sense to you? > > > +

Re: CI

Hi On Sun, Jan 14, 2024 at 7:13 PM Samuel Thibault wrote: > Hello, > > Flávio Cruz, le mar. 05 déc. 2023 01:27:30 -0500, a ecrit: > > On Sat, Dec 2, 2023 at 8:30 PM Samuel Thibault <[1] > samuel.thiba...@gnu.org> > > wrote: > > > > > Yes, sure, any

Re: [PATCH gnumach] Add vm_pages_phys

Hello On Mon, Jan 29, 2024 at 3:59 PM Samuel Thibault wrote: > For rumpdisk to efficiently determine the physical address, both for > checking whether it is below 4GiB, and for giving it to the disk > driver, we need a gnumach primitive (and that is not conditioned by > MACH_VM_DEBUG like mach_v

Re: [PATCH 1/2] mach/message.h: Use the x86_64 message ABI on all 64-bit ports

Hi Sergey On Tue, Jan 2, 2024 at 7:21 AM Sergey Bugaev wrote: > Signed-off-by: Sergey Bugaev > --- > include/mach/message.h | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/include/mach/message.h b/include/mach/message.h > index 9790ef98..87b83951 100644 > --

Re: mig not cross-building correctly

On Tue, Dec 5, 2023 at 1:31 AM Samuel Thibault wrote: > Hello, > > Flávio Cruz, le mar. 05 déc. 2023 01:09:24 -0500, a ecrit: > > I think you need to do: ./configure --target=i686-unknown-linux-gnu. > > That is implied by --host=i686-unknown-linux-gnu. > > (and

Re: CI

On Sat, Dec 2, 2023 at 8:30 PM Samuel Thibault wrote: > Yes, sure, anything will do. > > I essentially mean that "we" shouldn't be me. > > For a start, just testing that the whole thing just builds in the > various situations would be a *VAST* improvement, considering the amount > of time I spend

Re: mig not cross-building correctly

Hmm, we haven't made any significant change in MiG recently that would break this. I think you need to do: ./configure --target=i686-unknown-linux-gnu. The target compiler will generate the file cpu.h which includes the required sizes when generating code for i686. If MiG is expecting sizeof(ipc_p

Re: [PATCH gnumach] x86_64: Support 8 byte inlined port rights to avoid message resizing.

On Tue, Nov 28, 2023 at 7:53 PM Samuel Thibault wrote: > Samuel Thibault, le mer. 29 nov. 2023 00:19:41 +0100, a ecrit: > > I'm hitting the last assertion, not sure exactly where it is coming from > yet. > > Ok, I missed updating libc :) Now fixed. I'm however getting: > > task /sbin/getty(631) l

Re: 64bit startup

Hi Samuel On Tue, Oct 31, 2023 at 9:14 PM Samuel Thibault wrote: > Samuel Thibault, le mer. 01 nov. 2023 01:50:40 +0100, a ecrit: > > Samuel Thibault, le mar. 31 oct. 2023 04:40:43 +0100, a ecrit: > > > Samuel Thibault, le lun. 30 oct. 2023 18:35:03 +0100, a ecrit: > > > > Samuel Thibault, le di

Re: [PATCH gnumach] Update the 64bit RPC ABI to be simpler (v2)

Hi Samuel On Sun, Sep 24, 2023 at 4:24 AM Samuel Thibault wrote: > Samuel Thibault, le dim. 24 sept. 2023 00:16:21 +0200, a ecrit: > > const mach_msg_type_long_t nameType = { > > .msgtl_header = { > > .msgt_name =0, > >

Re: [PATCH gnumach] Update the 64bit RPC ABI to be simpler (v2)

Hi On Wed, Aug 9, 2023 at 10:21 AM Samuel Thibault wrote: > Sergey Bugaev, le mer. 09 août 2023 11:48:29 +0300, a ecrit: > > On Wed, Aug 9, 2023 at 4:10 AM Samuel Thibault > wrote: > > > So, is anybody against making this change? > > > > I trust Flávio to understand RPC ABI much better than I d

Re: [PATCH gnumach] Update the 64bit RPC ABI to be simpler

Hi Luca, Spent some time doing more testing on this patch since initially I had only tested it on basic programs. After "copyinmsg: allow for the last message element to have msgt_number = 0."

Re: [PATCH glibc] Stop checking if MiG supports retcode.

On Fri, May 26, 2023 at 9:42 AM Guy-Fleury Iteriteka wrote: > On May 26, 2023 2:00:00 PM GMT+02:00, "Flávio Cruz" > wrote: > >Hi Sergey > > > >On Fri, May 19, 2023 at 4:02 AM Sergey Bugaev wrote: > > > >> Hi, > >> > >> On Fr

Re: [PATCH glibc] Stop checking if MiG supports retcode.

On Fri, May 26, 2023 at 10:43 AM Sergey Bugaev wrote: > On Fri, May 26, 2023 at 3:00 PM Flávio Cruz wrote: > > Hi Sergey > > Hi, > > > Thanks for the instructions. I was able to make it work and pushed my > changes to Github. > > That's awesome news -- t

Re: [PATCH glibc] Stop checking if MiG supports retcode.

Hi Sergey On Fri, May 19, 2023 at 4:02 AM Sergey Bugaev wrote: > Hi, > > On Fri, May 19, 2023 at 9:43 AM Flávio Cruz wrote: > > I have made changes so that it does daily builds and I'm able to boot > small programs. However, I haven't had the time to boot programs b

Re: [PATCH glibc] Stop checking if MiG supports retcode.

Hi Sergey Sorry for the late reply, I have been busy with work and also traveling. On Tue, May 16, 2023 at 8:41 AM Sergey Bugaev wrote: > On Tue, May 16, 2023 at 6:02 PM Flávio Cruz wrote: > > Yes, I meant this when I said "generate code to call the server reply > routi

Re: [PATCH glibc] Stop checking if MiG supports retcode.

On Mon, May 15, 2023 at 2:19 AM Sergey Bugaev wrote: > Hi, > > On Mon, May 15, 2023 at 7:09 AM Flávio Cruz wrote: > > If we want > > ./configure to check if MiG generates code to call the server reply > routine > > in case of errors (it doesn't :() then we wil

Re: [PATCH glibc] Stop checking if MiG supports retcode.

Hi Sergey On Wed, May 10, 2023 at 1:36 AM Sergey Bugaev wrote: > Hello, > > On Wed, May 10, 2023, 08:21 Flavio Cruz wrote: > > HAVE_MIG_RETCODE is removed completely since this will be a no-op either > > way (compiling against old Hurd headers will work the same, new Hurd > > headers will resul

Re: [PATCH gnumach] Remove host_kernel_version RPC for x86_64

Hello, On Mon, May 8, 2023 at 4:40 PM Samuel Thibault wrote: > Hello, > > Flavio Cruz, le dim. 07 mai 2023 23:35:23 -0400, a ecrit: > > We can fast track the simplification of the RPC ABI for x86_64 if we > don't have > > MACH_MSG_TYPE_STRING used in RPCs which forces msgt_size to use more > tha

Re: [PATCH mig] Add support for dynamically sized strings

Hello On Fri, Apr 28, 2023 at 5:08 AM Sergey Bugaev wrote: > On Fri, Apr 28, 2023 at 6:00 AM Flavio Cruz wrote: > > Dynamically sized strings can be represented as c_string[*] (*). We > inline > > up to 64 bytes but can pass arbitrary strings if needed out of line. > Currently > > implementatio

Re: Mach time device, or: I know why the network deadlocks!

On Fri, Apr 28, 2023 at 7:54 AM Sergey Bugaev wrote: > Hello! > > Here comes yet another bug description and a change proposal; > hopefully not too long this time. (Update after having written like > half of it: apparently it *is* going to be long.) > > My system regularly experiences network dea

Re: [PATCH gnumach] Update task_basic_info and thread_basic_info to include time_value64_t data.

On Tue, Apr 25, 2023 at 4:11 PM Samuel Thibault wrote: > Flavio Cruz, le mar. 25 avril 2023 00:07:46 -0400, a ecrit: > > On Mon, Apr 17, 2023 at 11:49:46AM +0200, Samuel Thibault wrote: > > > Is this really needed? Since rpc_time_value_t will already be 64bit on > > > 64bit platforms. > > > > > >

Re: [PATCH 3/5] fix exception message format for 64-bit userspace

Hi Lucas, On Wed, Apr 19, 2023 at 3:47 PM Luca Dariz wrote: > * kern/exception.c: message fields need to be aligned to 8 bytes for a > 64-bit userspace, so add the required padding if needed, as done by > MIG. > --- > kern/exception.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff -

Re: [RFC PATCH gnumach 03/34] Make exception subcode a long

Hello! On Mon, Apr 3, 2023 at 5:32 AM Sergey Bugaev via Libc-alpha < libc-al...@sourceware.org> wrote: > On Mon, Apr 3, 2023 at 1:45 AM Samuel Thibault > wrote: > > Sergey Bugaev, le dim. 19 mars 2023 18:09:46 +0300, a ecrit: > > > On EXC_BAD_ACCESS, exception subcode is used to pass the faultin

Re: [PATCH gnumach] Align the user stack correctly for 64 bit programs.

Hi Luca On Mon, Mar 20, 2023 at 3:50 AM Luca wrote: > Hi! This indeed seems to make rpc work, at least in my tests. > > Il 20/03/23 05:59, Flavio Cruz ha scritto: > > diff --git a/i386/i386/thread.h b/i386/i386/thread.h > > index cb317bee..c5da7522 100644 > > --- a/i386/i386/thread.h > > +++ b/i

Re: [RFC PATCH 00/34] The rest of the x86_64-gnu port

Nice work indeed Sergey! On Sun, Mar 19, 2023 at 12:44 PM Luca wrote: > Hi Sergey, > > this looks like a great work! > > Il 19/03/23 16:09, Sergey Bugaev ha scritto: > > I was unable to actually get it running on GNU Mach. It either never gets > > started, or crashes soon enough. The latter is a

Re: [PATCH gnumach] Use c_string to define host_get_kernel_version and host_get_kernel_boot_info.

On Wed, Mar 15, 2023 at 3:20 AM Sergey Bugaev wrote: > On Wed, Mar 15, 2023 at 9:19 AM Flávio Cruz wrote: > > Still, at the > > end of the day we should only have two ways of defining strings, either > through > > c_string or by using variable arrays as defined by data_t

Re: [PATCH gnumach] Use c_string to define host_get_kernel_version and host_get_kernel_boot_info.

On Mon, Mar 13, 2023 at 3:32 PM Samuel Thibault wrote: > Hello, > > Flavio Cruz, le lun. 13 mars 2023 01:41:57 -0400, a ecrit: > > The existing definitions for kernel_version_t and kernel_boot_info_t use > > (MACH_MSG_TYPE_STRING, length*8) which result in message types that have > > a single ele

Re: [PATCH gnumach] Track task and thread time using time_value64_t.

On Mon, Mar 13, 2023 at 3:41 PM Samuel Thibault wrote: > Hello, > > Flavio Cruz, le lun. 13 mars 2023 01:42:12 -0400, a ecrit: > > @@ -854,21 +849,22 @@ kern_return_t task_info( > > task_thread_times_info_t times_info; > > thread_tthread; > > > > -

Re: [PATCH gnumach] Align mach_msg_type_t and mach_msg_type_long_t with the same alignment as uintptr_t.

Hi On Wed, Mar 8, 2023 at 4:37 AM Sergey Bugaev wrote: > Hi, > > this seems to break the x86_64 --disable-user32 gnumach build for me: > > vm/memory_object_user.user.c: In function ‘memory_object_init’: > vm/memory_object_user.user.c:128:9: error: static assertion failed: > "Request expected to

Re: checking whether mig supports the retcode keyword... no

On Fri, Feb 17, 2023 at 6:26 AM Sergey Bugaev wrote: > On Fri, Feb 17, 2023 at 9:02 AM Flávio Cruz wrote: > > Thanks for the instructions. I discovered that mach_msg_type_long_t does > not align to 8 bytes so it also needs a bit of padding just like > mach_msg_type_t. See my la

Re: checking whether mig supports the retcode keyword... no

On Thu, Feb 16, 2023 at 4:19 AM Sergey Bugaev wrote: > On Thu, Feb 16, 2023 at 10:27 AM Flávio Cruz wrote: > >> On that note: right now, MIG-generated stubs are broken on x86_64. MIG > >> built from master complains about time_value_t (which GCC says is 16 > >> by

Re: checking whether mig supports the retcode keyword... no

On Wed, Feb 15, 2023 at 4:05 AM Sergey Bugaev wrote: > On Wed, Feb 15, 2023 at 8:51 AM Flávio Cruz wrote: > >> This would be trivial to fix by flipping the line order in aclocal.m4 > >> (in each repo that vendors it...), but maybe MIG should actually > >> suppo

Re: checking whether mig supports the retcode keyword... no

Hey Sergey On Tue, Feb 14, 2023 at 8:49 AM Sergey Bugaev wrote: > This line in configure logs has always bugged me; of course GNU MIG > supports "retcode" (as in, does not report an error upon seeing it). > Today I happened to have journalctl -f opened at the time I ran > ../configure, and accid

Re: [PATCH gnumach] Add x86_64 registers to i386_thread_state

On Tue, Feb 14, 2023 at 2:51 PM Samuel Thibault wrote: > Sergey Bugaev, le mar. 14 févr. 2023 22:48:18 +0300, a ecrit: > > On Tue, Feb 14, 2023 at 10:20 PM Samuel Thibault > > wrote: > > > > > +#if defined(__x86_64__) && !defined(USER32) > > > > > + uint64_tefl; > > > > > > > > Sho

Re: [RFC PATCH mig 7/12] Drop -undef -ansi from cpp flags

On Sun, Feb 12, 2023 at 10:02 AM Samuel Thibault wrote: > Sergey Bugaev, le dim. 12 févr. 2023 14:10:38 +0300, a ecrit: > > Since GNU Mach commit d30481122a5d24ad6b921062f93b9172ef922fc3, > > i386/machine_types.defs defines types based on defined(__x86_64__). > > Supressing the built-in macro def

Re: [PATCH mig] Make MIG work for pure 64 bit kernel and userland.

On Sun, Feb 12, 2023 at 9:44 AM Samuel Thibault wrote: > Thanks for your work on the 64bit RPC part, that's tricky :) > > Flavio Cruz, le dim. 12 févr. 2023 01:15:05 -0500, a ecrit: > > diff --git a/cpu.sym b/cpu.sym > > index 6bcb878..7858b47 100644 > > --- a/cpu.sym > > +++ b/cpu.sym > > @@ -95

Re: [PATCH mig] Make MIG work for pure 64 bit kernel and userland.

On Sun, Feb 12, 2023 at 11:34 AM Luca wrote: > Il 12/02/23 17:05, Sergey Bugaev ha scritto: > > On Sun, Feb 12, 2023 at 7:01 PM Luca wrote: > >> It seems XNU's mig [0] always sets the alignment to natural_t (=4) with > >> a #pragma... I still have to understand how they handle these issues. > >

Re: [PATCH gnumach] Define rpc_vm_size_array_t and rpc_vm_offset_array_t

On Tue, Jan 31, 2023 at 2:54 PM Luca wrote: > Hi Sergey, > > Il 31/01/23 14:30, Sergey Bugaev ha scritto: > >> I understand they are related to the x64 bringup, and possibly to > >> running 32-bit userland on a 64-bit kernel (or to support for 32-bit > >> tasks communicating with 64-bit tasks?).

Re: [PATCH] Use $(CC) instead of gcc to avoid relying on the host gcc.

On Mon, Jan 30, 2023 at 6:51 PM Guillem Jover wrote: > On Mon, 2023-01-30 at 12:43:09 +0300, Sergey Bugaev wrote: > > it would be nicer if you explicitly specified what source tree this > > patch is for, for instance: [PATCH glibc] or [PATCH gnumach] instead > > of just [PATCH]. (There is the --s

Re: No rule to make target 'interruptServer.stamp', needed by 'interrupt_S.h'

On Tue, Jan 24, 2023 at 7:59 PM Ryan Raymond wrote: > Does anyone know what this is? The file "interrupt_S.h" doesn't exist, but > many files refer to it. I checked the git log but there wasn't a record of > the file ever existing. > That file is generated by mig

Re: [PATCH 4/4] Add cpu_number and cpuboot

On Wed, Jan 25, 2023 at 1:34 AM Jessica Clarke wrote: > On 25 Jan 2023, at 06:27, Flávio Cruz wrote: > >> On Tue, Jan 24, 2023 at 2:54 AM Samuel Thibault < > samuel.thiba...@gnu.org> wrote: > >> Flávio Cruz, le mar. 24 janv. 2023 01:15:15 -0500, a ecrit: &g

Re: [PATCH 4/4] Add cpu_number and cpuboot

On Tue, Jan 24, 2023 at 2:54 AM Samuel Thibault wrote: > Flávio Cruz, le mar. 24 janv. 2023 01:15:15 -0500, a ecrit: > > + int kernel_id; > > + unsigned long flags; > > + > > + cpu_intr_save(&flags); > > + > >

Re: [PATCH 4/4] Add cpu_number and cpuboot

Hi Damien On Sat, Jan 21, 2023 at 3:05 AM Damien Zammit wrote: > --- > i386/i386/cpu_number.c | 37 ++ > i386/i386/cpuboot.S| 164 + > 2 files changed, 201 insertions(+) > create mode 100644 i386/i386/cpu_number.c > create mode 100644 i386/

Re: [PATCH] Add kern/mach.h and kern/gnumach.h to define rpc prototypes

On Tue, Jan 17, 2023 at 8:08 PM Samuel Thibault wrote: > Flavio Cruz, le mar. 17 janv. 2023 00:11:49 -0500, a ecrit: > > +kern_return_t > > +register_new_task_notification( > > + const host_t host, > > + ipc_port_t notification); > > Err, but aren't these declared in the generated gnumach

Re: [PATCH] Add support for x86_64-*-gnu-* targets to build x86_64 gnumach/hurd

if test "$libgcc_cv_cfi" = "yes"; then > tmake_file="${tmake_file} t-stack i386/t-stack-i386" > diff --git a/libgcc/config/i386/gnu-unwind.h > b/libgcc/config/i386/gnu-unwind.h > index 25eb690e370..2cbfc40ea7e 100644 > --- a/libgcc/c

Clisp problem with reserved ranges during startup

Hi I have compiled Clisp in Debian GNU/Hurd but get a warning message during Clisp startup since the mmapable address ranges configured for UNIX_HURD seem to be incorrect: Warning: reserving address range 0x1806...0xbfff that contains memory mappings. clisp might crash later! Memory dump:

Re: [PATCH] Add struct ip_mreqn in the glue headers

On Thu, Sep 8, 2022 at 2:08 AM Samuel Thibault wrote: > Flavio Cruz, le mer. 07 sept. 2022 22:58:53 -0400, a ecrit: > > When I compile from master, I get the following error: > > > > gcc -std=gnu99 -fgnu89-inline -Wall -g -O3 -fno-strict-aliasing -g -O2 > -fno-strict-aliasing -I. -I.. -I../inc

Re: License of Hurd's common lisp bindings

-later. To be frank, I'm not well versed on the consequences of making it GPL v3.0-or-later. Can you elaborate why you prefer that? I don't have a strong preference and can make it "-or-later". Thanks Flavio > > Maxime. > p.s. I'm reading mach/message.l

Re: Compiling glibc: mutex-solid.c:20:10: fatal error: cthreads.h: No such file or directory

o > such file or directory > 87 | #include > | ^ > compilation terminated. > make[2]: *** [_muldi3.o] Error 1 > make[1]: *** [all-target-libgcc] Error 2 > make: *** [all] Error 2 > ``` > It seems that compiling gcc the second time needs glibc to provide a > workin

Re: Adding the hurd-cross package to "The Hurd group"?

t; I don't have much time nowadays, but I think the rewrite does what I intended it to do, meaning you can include C header files and use the C types when defining new routines. > Thank you for inspiring me, > Svante Signell > > On Fri, 2020-02-14 at 00:40 -0800, Flávio Cruz wr

Re: Adding the hurd-cross package to "The Hurd group"?

itory at > > http://git.savannah.gnu.org/cgit/hurd/ or elsewhere. What is the > > procedure to create an upstream git repo? > > I don't know, Thomas, do you know? > > Samuel > > -- Flávio Cruz / flavioc...@gmail.com

Rethinking MIG

Hi As we all know, the current language provided by MIG has several drawbacks: - Requires all types to be described twice: first in the C header file and then in the defs file. This is problematic since types need to have the same size in both files and also the same name. - It does not allow arbi

Re: [PATCH] Turn mach_msg_type_{name,size}_t into unsigned chars.

/* msgt_name = */ MACH_MSG_TYPE_POLYMORPHIC, ^ This shows when compiling some stubs since now mig generates code with MACH_MSG_TYPE_POLYMORPHIC instead of -1. I think this can be trivially fixed by removing the cast in MACH_MSG_TYPE_POLYMORPHIC. > > Samuel > -- Flávio Cruz / flavioc...@gmail.com

Re: [PATCH] Simple testsuite for MIG.

that simple. For anything else, it's better > to add a copyright notice, because otherwise if people adds code to them > they won't dare adding the copyright notice, and then we'd have > non-trivial files without copyright notice. > Done. I think it's ready to go now. Flavio > > Thanks, > Samuel > -- Flávio Cruz / flavioc...@gmail.com

Re: [PATCH] Use uint32_t instead of unsigned32_t.

On 5 April 2016 at 00:59, Justus Winter <4win...@informatik.uni-hamburg.de> wrote: > Quoting Justus Winter (2016-04-05 00:46:11) > > Quoting Flávio Cruz (2016-04-05 00:39:48) > > > > This broke your test suite: > > > Should work with the new patch. Thanks fo

Re: [PATCH] Use uint32_t instead of unsigned32_t.

ou try with the new patch? When I cross-compiled the system with I think I had some leftover files from previous compilations which made everything compile (when it shouldn't). I've tested now with a clean slate and it seems to work fine. > David > -- Flávio Cruz / flavioc...@gmail.com

Re: [PATCH] Use uint32_t instead of unsigned32_t.

) > > (likewise directions.defs) > > Should work with the new patch. Thanks for the report. Flavio > Justus > > > fprintf(file, > > " _t.t = *(type); _c.t = *(check);_t.w != _c.w; }))\n"); > > } > > -- > > 2.6.4 > > > > > -- Flávio Cruz / flavioc...@gmail.com

Re: [PATCH] Use uint32_t instead of unsigned32_t.

4_t cpu_clock, last_cpu_clock, delta, system_time; > - unsigned64_t delta_high, delta_low; > - unsigned32_t mul; > +static uint64_t hyp_get_stime(void) { > + uint32_t version; > + uint64_t cpu_clock, last_cpu_clock, delta, system_time; > + uint64_t delta_high, delta_low; > + uint32_t mul; > signed8_t shift; > volatile struct vcpu_time_info *time = > &hyp_shared_info.vcpu_info[0].time; > > @@ -56,14 +56,14 @@ static unsigned64_t hyp_get_stime(void) { > else > delta <<= shift; > delta_high = delta >> 32; > - delta_low = (unsigned32_t) delta; > - return system_time + ((delta_low * (unsigned64_t) mul) >> 32) > - + (delta_high * (unsigned64_t) mul); > + delta_low = (uint32_t) delta; > + return system_time + ((delta_low * (uint64_t) mul) >> 32) > + + (delta_high * (uint64_t) mul); > } > > -unsigned64_t hyp_get_time(void) { > - unsigned32_t version; > - unsigned32_t sec, nsec; > +uint64_t hyp_get_time(void) { > + uint32_t version; > + uint32_t sec, nsec; > > do { > version = hyp_shared_info.wc_version; > @@ -77,7 +77,7 @@ unsigned64_t hyp_get_time(void) { > } > > static void hypclock_intr(int unit, int old_ipl, void *ret_addr, struct > i386_interrupt_state *regs) { > - unsigned64_t nsec, delta; > + uint64_t nsec, delta; > > if (!lastnsec) > return; > @@ -116,7 +116,7 @@ int > readtodc(tp) > u_int *tp; > { > - unsigned64_t t = hyp_get_time(); > + uint64_t t = hyp_get_time(); > u_int n = t / 10; > > *tp = n; > diff --git a/xen/time.h b/xen/time.h > index 8c8bc53..cf28720 100644 > --- a/xen/time.h > +++ b/xen/time.h > @@ -20,6 +20,6 @@ > #define XEN_TIME_H > > #include > -unsigned64_t hyp_get_time(void); > +uint64_t hyp_get_time(void); > > #endif /* XEN_TIME_H */ > -- > 2.7.0 > > -- Flávio Cruz / flavioc...@gmail.com

Re: [PATCH] Use uint32_t instead of unsigned32_t.

{ mach_msg_type_t t; uint32_t w; } _t, _c;\\\n"); > > fprintf(file, > > " _t.t = *(type); _c.t = *(check);_t.w != _c.w; }))\n"); > > } > > -- > > 2.6.4 > > > > > > -- > Samuel > bon comment on fait de l'investigation pour savoir qui est le vilain ? > on débranche le routeur et on regarde qui s'affole > -+- #ens-mim administre -+- > -- Flávio Cruz / flavioc...@gmail.com

Re: [PATCH] Remove functions, procedures and simple procedures.

f(file, "\t\t{ %s(%s); ", rt->rtErrorName, error_msg); > > + fprintf(file, "\t\t{ (%s); ", error_msg); > > if (rt->rtNumReplyVar > 0) > > fprintf(file, "OutP = &Mess.Out; "); > > fprintf(file, "return OutP->%s; }\n", rt->rtReturn->argMsgField); > > @@ -267,16 +265,12 @@ WriteMsgError(FILE *file, const routine_t *rt, > const char *error_msg) > > > > /* > > * Writes the send call when there is to be no subsequent > > - * receive. Called by WriteRoutine for SimpleProcedures > > - * or SimpleRoutines > > + * receive. Called by WriteRoutine for SimpleRoutines. > > */ > > static void > > WriteMsgSend(FILE *file, const routine_t *rt) > > { > > -const char *MsgResult = (rt->rtProcedure) > > - ? "msg_result =" > > - : "return"; > > - > > +const char *MsgResult = "return"; > > char SendSize[24]; > > > > if (rt->rtNumRequestVar == 0) > > @@ -301,12 +295,6 @@ WriteMsgSend(FILE *file, const routine_t *rt) > > " MACH_PORT_NULL, MACH_MSG_TIMEOUT_NONE, > MACH_PORT_NULL);\n" > > ); > > } > > - > > -if (rt->rtProcedure) > > -{ > > - fprintf(file, "\tif (msg_result != MACH_MSG_SUCCESS)\n"); > > - WriteMsgError(file, rt, "msg_result"); > > -} > > } > > > > /* > > @@ -342,7 +330,7 @@ WriteMsgCheckReceive(FILE *file, const routine_t > *rt, const char *success) > > /* > > * Writes the rpc call and the code to check for errors. > > * This is the default code to be generated. Called by WriteRoutine > > - * for all routine types except SimpleProcedure and SimpleRoutine. > > + * for all routine types except SimpleRoutine. > > */ > > static void > > WriteMsgRPC(FILE *file, const routine_t *rt) > > @@ -1213,12 +1201,8 @@ WriteRoutine(FILE *file, const routine_t *rt) > > else { > > WriteReplyArgs(file, rt); > > > > - /* return the return value, if any */ > > - > > - if (rt->rtProcedure) > > - fprintf(file, "\t/* Procedure - no return needed */\n"); > > - else > > - WriteReturnValue(file, rt); > > + /* return the return value */ > > +WriteReturnValue(file, rt); > > } > > } > > > > -- > > 2.6.4 > > > > > > -- > Samuel > cool, j'ai un rapport a rendre pour le 31 decembre a minuit... > -+- #ens-mim - bonne année ! -+- > -- Flávio Cruz / flavioc...@gmail.com

Re: [PATCH] Cast kernel server call arguments to the correct type when mach_port_t and ipc_port_t are used interchangeably

> > > > I've been wondering about that, but didn't took a closer look. I > > always assumed that this is due to MatchMakers poor type support. > > In this case it's related to the way mig handles ipc_port_t objects and > mach_port_t names internally. > > > > > Cheers, > > Justus > > Cheers > Flavio > -- Flávio Cruz / flavioc...@gmail.com

Re: [PATCH] Fixed leaks in _netfs_translator_callback2_fn

ould do it as follows: err = errno; netfs_release_peropen (po); iohelp_free_iouser (user); return err; I've seen this pattern a few times in other files since the release calls may reassign errno. -- Flávio Cruz / flavioc...@gmail.com

Re: GSoC report: Physical memory management

panics. > > -- > Richard Braun > > [1] http://darnassus.sceen.net/gitweb/?p=rbraun/gnumach.git;a=summary > > -- Flávio Cruz / flavioc...@gmail.com

Re: [PATCH] Change file_utimes RPC to use a struct timespec and update the servers to use UTIME_NOW and UTIME_OMIT.

Hi Samuel Have you see the new patches? Let me know if anything looks wrong. Cheers Flavio On 20 September 2015 at 03:04, Flávio Cruz wrote: > Hi Samuel > > On Sat, 19 Sep 2015 at 14:22 Samuel Thibault > wrote: > >> Sorry I didn't think about it at first,

Re: [PATCH] Change file_utimes RPC to use a struct timespec and update the servers to use UTIME_NOW and UTIME_OMIT.

Hi Samuel On Sat, 19 Sep 2015 at 14:22 Samuel Thibault wrote: > Sorry I didn't think about it at first, but inside the fallback on > file_utimes: > > Flávio Cruz, le Thu 17 Sep 2015 02:05:33 +, a écrit : > > + if (err == MIG_BAD_ID || err == EOPNOTSUPP) > > +

Re: [PATCH] Change file_utimes RPC to use a struct timespec and update the servers to use UTIME_NOW and UTIME_OMIT.

Hi Samuel On Sun, 13 Sep 2015 at 12:49 Samuel Thibault wrote: > Flávio Cruz, le Mon 31 Aug 2015 15:16:08 +, a écrit : > > Note that I also added a two macros to convert between timespecs and > > time_value_t in libshouldbeinlibc/timefmt.h (one was taken from the exec > &

Re: [PATCH] Change file_utimes RPC to use a struct timespec and update the servers to use UTIME_NOW and UTIME_OMIT.

On Sun, 30 Aug 2015 at 01:24 Samuel Thibault wrote: > Hello, > > Thanks for working on this! > > Flávio Cruz, le Sat 29 Aug 2015 03:35:56 +0100, a écrit : > > These two patches allow the glibc and the hurd servers to handle > UTIME_OMIT and UTIME_NOW in futimens. > >

[PATCH] Add Hurd support for UTIME_OMIT and UTIME_NOW.

From: Flávio Cruz This fixes the bug described in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762677 --- sysdeps/mach/hurd/bits/stat.h | 4 sysdeps/mach/hurd/futimens.c | 17 ++--- sysdeps/mach/hurd/futimes.c | 25 ++--- sysdeps/mach/hurd/lutimes

[PATCH] Change file_utimes RPC to use a struct timespec and update the servers to use UTIME_NOW and UTIME_OMIT.

From: Flávio Cruz Hello These two patches allow the glibc and the hurd servers to handle UTIME_OMIT and UTIME_NOW in futimens. The file_utimes RPC now uses a struct timespec instead of a timeval. --- console-client/trans.c | 8 ++-- console/console.c | 8 ++-- ext2fs/p

Re: [PATCH] Port leak when using clisp

I've split the patch into two. Cheers Flavio On Thu, 27 Aug 2015 at 11:53 Justus Winter < 4win...@informatik.uni-hamburg.de> wrote: > Hi, > > Quoting Flávio Cruz (2015-08-27 00:26:13) > > Em qua, 26 de ago de 2015 às 12:18, Justus Winter < > > 4win...@

Re: [PATCH] Port leak when using clisp

Em qua, 26 de ago de 2015 às 12:18, Justus Winter < 4win...@informatik.uni-hamburg.de> escreveu: > > > After looking around and using KDB, I've figured out that the following > loop in > > kern/exceptions.c/exception_raise_continue_slow was the culprit: > > Could you elaborate a little on your met

[PATCH] Port leak when using clisp

Hi all I'm trying to port the SBCL compiler to the Hurd but I've found a serious port leak which prevents me from completing the port. So, the first thing I did was to compile CLISP in order to bootstrap SBCL. CLISP compiled just fine and runs well as far as I know. Next, I started the bootstrap

Re: clisp -- Flávio Cruz, GSoC 2008 (was : Writing translators in lisp - cl-hurd code recovered )

Just to be sure: is this true also for the changes you did after first merging stuff into the CVS branch? Yes. The git repository contains the newest updates. Flávio.

Re: clisp -- Flávio Cruz, GSoC 2008 (was : Writing translators in lisp - cl-hurd code recovered )

Hello! On Thu, Sep 17, 2009 at 08:23:22AM +0200, Arne Babenhauserheide wrote: Am Dienstag, 15. September 2009 08:56:24 schrieb Arne Babenhauserheide: Since the Hurd has bindings for using common Lisp for translators, you can in fact use Lisp to write part of an OS (the attached snapshot is

[PATCH] Use standard constants in boot/

Hey, This patches changes 1 and 2's into STDOUT_FILENO and STDERR_FILENO, respectively. Index: boot/boot.c === RCS file: /cvsroot/hurd/hurd/boot/boot.c,v retrieving revision 1.109 diff -u -r1.109 boot.c --- boot/boot.c 14 Mar 2006 23

[BUG] Problem compiling ugids-argp.o from libshouldbeinlibc

Hello, Some people have reported the same problem. When trying to compile libshouldbeinlibc, the target ugids-argp.o fails with make error 2. gcc -std=gnu99 -fgnu89-inline -Wall -g -O3 -g -O2 -I. -I../../libshouldbeinlibc -I.. -I../.. -I../include -I../../include -D_GNU_SOURCE -D_IO_MTSAFE

Re: GSoC projects

etc.). b) People on IRC said it was a better idea to include it in the main source tree. IMHO, it should be a standalone thing, because it has dependencies in three external Lisp libraries and it's written in Lisp ;-) Regards, Flávio Cruz.

[PATCH] libfshelp: keep stdin and stdout open

Hi, This patches changes the available file descriptors when starting translator processes. It keeps stdin and stdout open, both pointing to /dev/null. This patch has the side effect of fixing the strange behavior of CLISP when starting Lisp translators (it goes into a stack overflow with stdin an

[patch] use major & minor for device numbers

This patch makes libnetfs use the macros from sys/sysmacros.h. Index: file-get-translator.c === RCS file: /cvsroot/hurd/hurd/libnetfs/file-get-translator.c,v retrieving revision 1.9 diff -u -r1.9 file-get-translator.c --- file-get-tra

[PATCH] idvec_merge_auth leak

Hey guys, This patch fixes a memory problem. munmap must deallocate the exact number of bytes in a UID/GID array. Index: idvec-auth.c === RCS file: /cvsroot/hurd/hurd/libshouldbeinlibc/idvec-auth.c,v retrieving revision 1.8 diff -u -

[PATCH] libnetfs file-utimes.c unnecessary computations

Hey folks, In file-utimes.c the port existence is only verified after some computations on the atime and mtime timespec's are done. That is unnecessary when we exit with EOPNOTSUPP. This patches just changes the order of the check. Index: file-utimes.c

[PATCH] fshelp_iscontroller root uid bug

->uids, st->st_uid) + if (idvec_contains (user->uids, 0) || idvec_contains (user->uids, st->st_uid) || idvec_contains (user->uids, geteuid ())) return 0; Cheers, Flávio Cruz. fshelp-perms-iscontroller.patch Description: Binary data

Re: Thoughts about the Lisp bindings project

> A little side node: You are regularily using "pretend" in a manner that > doesn't quite fit the context in English, and in fact is quite amusing > :-) Ahah, checked that up on a dictionary, indeed, it's quite amusing ;-) > I don't think it's a good idea to define the interfaces in a completely

Thoughts about the Lisp bindings project

Here's what I pretend to do during the summer session for GSOC: 1. API to create RPC calls on the fly (something like defrpc) Will involve the creation of an API that can generate new RPC calls as MIG does but using Lisp macros. This interface should be micro-kernel agnostic. Of course the inner

Summer of code: procfs and lisp bindings

rtant, right now, for the Hurd? The procfs translator or some cute Lisp bindings? Thanks for your time, Flávio Cruz.