memory limits in AMD64 GNU Mach

What are the memory limits in AMD64 GNU Mach? Is it 1TB or 64TB? Yuhong Bao

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

Dear Samuel, Thank you for your feedback. I am in the process of polishing the GCC configuration files and I will send them a patch for the riscv64-gnu backend shortly. It is indeed a trivial change with no more than 100 lines. For the Mach, I'm planning on getting a simple kprintf working an

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

Cool!

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

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

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

Hi all, I’ve been working on getting GNU Mach to compile on riscv64, and I wanted to share an early update and ask if there’s interest in upstreaming a stub port. So far I’ve created a set of stub implementation files for riscv64, mostly copied and stripped down from the existing i386

Re: Errors while building gnu mach (2275d52...) from git source

Hello, Zhaoming Luo, le jeu. 17 oct. 2024 22:17:43 +0800, a ecrit: > ../linux/dev/include/linux/if.h:148:17: error: unknown type name 'caddr_t' >   148 | caddr_t ifru_data; >   | ^~~ > > Did I misunderstand something? No, it's just a bug in the linux net d

Re: Errors while building gnu mach (2275d52...) from git source

Zhaoming Luo writes: > Hi, > > For testing, I'm trying to build gnu mach (2275d52...) from source by > following the guide on this website. I followed the > path of building from the git repository. After I have a working MIG (either > pre-built from apt or built from

Errors while building gnu mach (2275d52...) from git source

Hi, For testing, I'm trying to build gnu mach (2275d52...) from source by following the guide on this website <https://darnassus.sceen.net/~hurd-web/microkernel/mach/gnumach/building/>. I followed the path of building from the git repository. After I have a working MIG (either pre

Re: Initial POWER9 port of GNU Mach

October 18, 2023 11:11 AM, "Tobias Alexandra Platen" wrote: >> Hi, >> >> On 17/10/23 3:10 am, Tobias Alexandra Platen wrote: >> On Mon, 2023-10-16 at 02:39 +, Damien Zammit wrote: > > I dont think that is correct. I often use -kernel flag with qemu > to > boot gnumach on i386. > I think it

Re: Initial POWER9 port of GNU Mach

On Thu, 2023-10-19 at 22:51 -0500, Nathan Dehnel wrote: > Do you happen to have code available for your gnumach-in-userspace > project? I'm interested in looking at it. > I want to push my branch to Savannah in a branch. I'll do it on Sunday evening. Alex

Re: Initial POWER9 port of GNU Mach

Do you happen to have code available for your gnumach-in-userspace project? I'm interested in looking at it.

Re: Initial POWER9 port of GNU Mach

On Wed, 2023-10-18 at 08:07 +, Damien Zammit wrote: > Hi, > > On 17/10/23 3:10 am, Tobias Alexandra Platen wrote: > > On Mon, 2023-10-16 at 02:39 +, Damien Zammit wrote: > > > I dont think that is correct. I often use -kernel flag with qemu > > > to > > > boot gnumach on i386. > > > I thin

Re: Initial POWER9 port of GNU Mach

Hi, On 17/10/23 3:10 am, Tobias Alexandra Platen wrote: > On Mon, 2023-10-16 at 02:39 +, Damien Zammit wrote: >> I dont think that is correct. I often use -kernel flag with qemu to >> boot gnumach on i386. >> I think it supports multiboot so you may need to add some startup >> code to your ppc

Re: Initial POWER9 port of GNU Mach

On Sat, 2023-10-14 at 14:33 +, jbra...@dismail.de wrote: > October 14, 2023 9:43 AM, "Tobias Alexandra Platen" > wrote: > > > There is no startup code for powerpc that currently works, so I > > duck- > > taped everything that is not implemented yet. The OSFMK code that I > > use is from 1994

Re: Initial POWER9 port of GNU Mach

October 14, 2023 9:43 AM, "Tobias Alexandra Platen" wrote: > There is no startup code for powerpc that currently works, so I duck- > taped everything that is not implemented yet. The OSFMK code that I > use is from 1994 and not ported yet. It only runs on a POWERMAC. > > ./mach_kernel > callin

Re: Initial POWER9 port of GNU Mach

There is no startup code for powerpc that currently works, so I duck- taped everything that is not implemented yet. The OSFMK code that I use is from 1994 and not ported yet. It only runs on a POWERMAC. ./mach_kernel calling setup_main void duct_sched_init(void) void duct_vm_mem_bootstrap(void)

Re: Initial POWER9 port of GNU Mach

To test gnunach, you must run this to a virtual machine and debug from remote debugging. You can't debug it like a common application. Create a little VM from Qemu (using qemu-system-ppc) and run gnumach from it. El sábado 14 de octubre de 2023, Tobias Alexandra Platen escribió: > cd gnumach/p

Initial POWER9 port of GNU Mach

cd gnumach/power9 gdb ./mach_kernel GNU gdb (Debian 13.1-3) 13.1 Copyright (C) 2023 Free Software Foundation, Inc. . Program received signal SIGSEGV, Segmentation fault. pset_sys_bootstrap () at kern/processor.c:84 84 proces

Re: directmap vs highmem usage in gnu mach?

Richard Braun, le mer. 25 août 2021 17:12:44 +0200, a ecrit: > For practical purposes, sure, but in the long run, there must be > some kind of very clear (preferrably explicit) policy about all that. Yes, sure, I planned to mark the functions as such :) > Personally, I'd do the same as Linux, wit

Re: directmap vs highmem usage in gnu mach?

On Wed, Aug 25, 2021 at 04:23:23PM +0200, Samuel Thibault wrote: > Richard Braun, le mer. 25 août 2021 15:59:12 +0200, a ecrit: > > I can't recall exactly, but that's why we write comments, right ? > > See [1]. > > > > Fixing this requires changing all callers to not assume that allocated > > memo

Re: directmap vs highmem usage in gnu mach?

Richard Braun, le mer. 25 août 2021 15:59:12 +0200, a ecrit: > I can't recall exactly, but that's why we write comments, right ? > See [1]. > > Fixing this requires changing all callers to not assume that allocated > memory can always be directly mapped, in particular some kvtophys calls. Ok, I w

Re: directmap vs highmem usage in gnu mach?

On Mon, Aug 23, 2021 at 01:56:52PM +0200, Samuel Thibault wrote: > Do you know if it is on purpose that all vm_page_grab() calls use the > directmem segment, and not the highmem segment? Notably vm_page_fault() > ends up filling the directmem segment first, I even wonder how the > highmem segment

directmap vs highmem usage in gnu mach?

Hello Richard, Do you know if it is on purpose that all vm_page_grab() calls use the directmem segment, and not the highmem segment? Notably vm_page_fault() ends up filling the directmem segment first, I even wonder how the highmem segment ends up getting filled :) Is that perhaps to rather try

Re: Can't boot GNU Mach with efi

That's cool. I didn't realize that the Hurd could potentially boot from UEFI. That's interesting. February 6, 2021 6:40 PM, "Paul Dufresne" wrote: > Le sam., 06 févr. 2021 16:57:39 -0500 écrit ---- > >> So, you got GNU Mach to boot with EFI? Wow!

Re: Can't boot GNU Mach with efi

Le sam., 06 févr. 2021 16:57:39 -0500 écrit > So, you got GNU Mach to boot with EFI? Wow! That's awesome! No... I had not tried yet when you wrote your message. Now, I have tried, and failed. I think that a good part of the (my) problem, is that I have made a custom i

Re: Can't boot GNU Mach with efi

So, you got GNU Mach to boot with EFI? Wow! That's awesome! February 6, 2021 4:14 PM, "Paul Dufresne" wrote: > I just wrote: >> The question is... how to we get the EFI_SYSTEM_TABLE, that was read by >> BOOTX64.EFI (which I > believe is part of Grub bina

Re: Can't boot GNU Mach with efi

I just wrote: > The question is... how to we get the EFI_SYSTEM_TABLE, that was read by > BOOTX64.EFI (which I believe is part of Grub binary package)... > or is there an other way to get it again? That is much easier than I thought! This manual explains it: https://www.gnu.org/software/gru

Re: Can't boot GNU Mach with efi

https://help.ubuntu.com/community/UEFIBooting is a good introduction to booting on UEFI with Grub. They say: "If you have a non-Mac UEFI system, then you have a x86_64 (aka 64-bit) UEFI 2.x firmware. " But I did saw non-MAC UEFI which was 32 bit on relatively old laptops. Type the following com

Re: Can't boot GNU Mach with efi

I can't boot current in UEFI on "recent: Prime H310M-C CR2.0 motherboard. Here on Ubuntu, I see the CD have: /media/paul/Debian sid h-i386 1/EFI/boot/bootia32.efi nothing else in that /EFI/boot directory. I am really unsure, but I feel this file is for people having to boot 32 bits (U)EFI. Most

Re: Can't boot GNU Mach with efi

Andrea G. Monaco, le sam. 06 févr. 2021 00:16:58 +0100, a ecrit: > > Mach doesn't initialize text mode itself indeed. > > Okay, Mach has no framebuffer console like fbcon in Linux, right? Then > maybe the only option is switching back to text mode. It doesn't indeed, it's a microkernel :) Sam

Re: Can't boot GNU Mach with efi

> Mach doesn't initialize text mode itself indeed. Okay, Mach has no framebuffer console like fbcon in Linux, right? Then maybe the only option is switching back to text mode. -- Andrea G. Monaco Hacker, mathematician, lgbt+ activist "Hope will never be silent!", H. Milk

Re: GNU Mach doesn't work with EFI

Hello, Andrea G. Monaco, le dim. 10 janv. 2021 01:15:00 +0100, a ecrit: > After some research, I found that EFI doesn't provide a VGA text mode > (https://forum.osdev.org/viewtopic.php?f=1&t=28429) and offers different > graphic primitives than BIOS. That's not a problem: gnumach doesn't use them

GNU Mach doesn't work with EFI

Hello, it seems that GNU Mach doesn't work with EFI. It's not that I'm fond of EFI, in fact I hate it because it makes booting so difficult, but right now I have only an EFI system available. Also, I heard that many boot firmwares nowadays have only EFI and no BIOS, or they just

[task #5488] Update the device driver glue code in GNU Mach

Update of task #5488 (project hurd): Wiki-like text discussion box: => Rather remove it :) By finishing the rump user-level code. ___ Reply to this item at: ___

Re: Unit testing in GNU Mach?

Almudena Garcia, le ven. 04 oct. 2019 17:25:24 +0200, a ecrit: > Are there any unit test suite to check gnumach?  I'm not aware of any. Samuel

Unit testing in GNU Mach?

Hi all: Developing the SMP support in gnumach, some people ask me if there are any usecase and unit test to check the code. I don't know how can I use unit test in gnumach, neither if there are any key usecase to check. Are there any unit test suite to check gnumach? Thanks

Re: Problem with GNU Mach compillation

Thanks, This solve my problem. https://github.com/AlmuHS/GNUMach_SMP/ Now I will can continue with my SMP work :-) El lun., 31 dic. 2018 a las 2:26, Almudena Garcia (< liberamenso10...@gmail.com>) escribió: > > > El dom., 30 dic. 2018 a las 22:36, Samuel Thibault (< > samuel.thiba...@gnu.org>) e

Re: Problem with GNU Mach compillation

El dom., 30 dic. 2018 a las 22:36, Samuel Thibault () escribió: > Hello, > > Almudena Garcia, le lun. 24 déc. 2018 00:37:42 +0100, a ecrit: > > I tried with a clean compillation from original gnumach sources, and > this step > > runs well. But, in my fork, It crashes. > > This was indeed fixed in

Re: Problem with GNU Mach compillation

Hello, Almudena Garcia, le lun. 24 déc. 2018 00:37:42 +0100, a ecrit: > I tried with a clean compillation from original gnumach sources, and this step > runs well. But, in my fork, It crashes. This was indeed fixed in the master branch. You need to pull from it to get the fix. Samuel

Re: Problem with GNU Mach compilation

Almudena Garcia, le mer. 27 juin 2018 22:27:48 +0200, a ecrit: > I've just to try the flags what you suggested, and this also runs correctly Cool, thanks for the test! Samuel

Re: Problem with GNU Mach compilation

I've just to try the flags what you suggested, and this also runs correctly 2018-06-27 22:15 GMT+02:00 Almudena Garcia : > Ok, I'll try it > > 2018-06-27 22:14 GMT+02:00 Samuel Thibault : > >> Almudena Garcia, le mer. 27 juin 2018 22:06:32 +0200, a ecrit: >> > I don't be sure. I asked in #hurd Fr

Re: Problem with GNU Mach compilation

Ok, I'll try it 2018-06-27 22:14 GMT+02:00 Samuel Thibault : > Almudena Garcia, le mer. 27 juin 2018 22:06:32 +0200, a ecrit: > > I don't be sure. I asked in #hurd Freenode channel, and one person > suggested me > > to add this flags > > Ok, but could you test these instead? > > -no-pie -fno-

Re: Problem with GNU Mach compilation

Almudena Garcia, le mer. 27 juin 2018 22:06:32 +0200, a ecrit: > I don't be sure. I asked in #hurd Freenode channel, and one person suggested > me > to add this flags Ok, but could you test these instead? -no-pie -fno-pic Samuel

Re: Problem with GNU Mach compilation

This is the conversation 2018-06-27 22:06 GMT+02:00 Almudena Garcia : > I don't be sure. I asked in #hurd Freenode channel, and one person > suggested me to add this flags > > 2018-06-27 21:45 GMT+02:00 Samuel Thibault : > >> Almudena Garcia, le mer. 27 juin 2018 18:16:21 +0200, a ecrit: >> > -

Re: Problem with GNU Mach compilation

I don't be sure. I asked in #hurd Freenode channel, and one person suggested me to add this flags 2018-06-27 21:45 GMT+02:00 Samuel Thibault : > Almudena Garcia, le mer. 27 juin 2018 18:16:21 +0200, a ecrit: > > - -fno-builtin-log > > + -fno-builtin-log --no-pie --no-pic > > I'm surprised

Re: Problem with GNU Mach compilation

Almudena Garcia, le mer. 27 juin 2018 18:16:21 +0200, a ecrit: > - -fno-builtin-log > + -fno-builtin-log --no-pie --no-pic I'm surprised by the form of the option. I would have thought rather -no-pie -fno-pic which are documented, while the options above are not. Could you try them inst

Re: Problem with GNU Mach compilation

Have you received my latest patch? 2018-06-27 18:18 GMT+02:00 Almudena Garcia : > Yes, I just send a fixed patch file, with diff -u > > 2018-06-27 18:17 GMT+02:00 Samuel Thibault : > >> Almudena Garcia, le mer. 27 juin 2018 18:12:53 +0200, a ecrit: >> > I attach the patch file >> >> Please use di

Re: Problem with GNU Mach compilation

Yes, I just send a fixed patch file, with diff -u 2018-06-27 18:17 GMT+02:00 Samuel Thibault : > Almudena Garcia, le mer. 27 juin 2018 18:12:53 +0200, a ecrit: > > I attach the patch file > > Please use diff -u, not just diff. > > Samuel >

Re: Problem with GNU Mach compilation

02:00 Almudena Garcia : > >> HHi all: >> >> I'm trying to compile GNU Mach from GNU Hurd, using the sources from git >> repository. >> >> I based on this guide: https://www.gnu.org/software/h >> urd/microkernel/mach/gnumach/building.html >> B

Re: Problem with GNU Mach compilation

Almudena Garcia, le mer. 27 juin 2018 18:12:53 +0200, a ecrit: > I attach the patch file Please use diff -u, not just diff. Samuel

Re: Problem with GNU Mach compilation

Finally, I got to solve the problem, adding a few flags to Makefile.am http://dpaste.com/2NRGESV I attach the patch file 2018-06-25 18:13 GMT+02:00 Almudena Garcia : > HHi all: > > I'm trying to compile GNU Mach from GNU Hurd, using the sources from git > repository. > >

GNU Hurd 0.9, GNU Mach 1.8, GNU MIG 1.8 released

Hi! Please see <http://www.gnu.org/software/hurd/news/2016-12-18-releases.html>. Text-only version: | GNU Hurd 0.9, GNU Mach 1.8, GNU MIG 1.8 released. | | We're pleased to announce new releases! | | * GNU Hurd 0.9, NEWS: | | Version 0.9 (2016-12-18) | | | The 'b

Re: [SCM] GNU Mach branch, master, updated. v1.7-67-gc387012

Hello, Justus Winter, on Sun 06 Nov 2016 12:08:31 +, wrote: > Revert "i386: use ACPI to power off the machine" That'll be quite inconvenient. Do we have plans to push that into userspace? Samuel

GNU Hurd 0.8, GNU Mach 1.7, GNU MIG 1.7 released

Hi! Please see <http://www.gnu.org/software/hurd/news/2016-05-18-releases.html>. Text-only version: | GNU Hurd 0.8, GNU Mach 1.7, GNU MIG 1.7 released. | | We're pleased to announce new releases! | | GNU Hurd 0.8, NEWS: | | Version 0.8 (2016-05-18) | | | The netfs

Re: Kernel debugging / drivers (was: USB keyboard driver the GNU Mach)

Hello, I agree that having a in-kernel USB keyboard driver makes sense for the debugger. As for the interaction with userland USB support, I don't think we can share the access to the same USB chip, so when the kernel driver is running the userland driver can't run. One could say that when the U

Kernel debugging / drivers (was: USB keyboard driver the GNU Mach)

Hi, On Mon, Feb 29, 2016 at 12:41:43PM +0100, Justus Winter wrote: > While we generally want to move away from drivers in the kernel, it > might indeed be nice to have a keyboard driver inside it for kdb. Hm, this is an interesting point. I haven't actually considered keyboard drivers up till no

Re: Testing requested for the next version of GNU Mach

Richard Braun, on Tue 15 Mar 2016 00:40:40 +0100, wrote: > On Tue, Mar 15, 2016 at 12:32:43AM +0100, Samuel Thibault wrote: > > Richard Braun, on Mon 14 Mar 2016 23:37:33 +0100, wrote: > > > On Mon, Mar 14, 2016 at 06:27:24PM -0400, David Michael wrote: > > > > After poking around a bit more, it se

Re: Testing requested for the next version of GNU Mach

On Tue, Mar 15, 2016 at 12:32:43AM +0100, Samuel Thibault wrote: > Richard Braun, on Mon 14 Mar 2016 23:37:33 +0100, wrote: > > On Mon, Mar 14, 2016 at 06:27:24PM -0400, David Michael wrote: > > > After poking around a bit more, it seems that the space is eaten by > > > debug info. Appending -g0 t

Re: Testing requested for the next version of GNU Mach

Richard Braun, on Mon 14 Mar 2016 23:37:33 +0100, wrote: > On Mon, Mar 14, 2016 at 06:27:24PM -0400, David Michael wrote: > > After poking around a bit more, it seems that the space is eaten by > > debug info. Appending -g0 to CFLAGS allowed gnumach to boot > > successfully and resulted in this: >

Re: Testing requested for the next version of GNU Mach

On Mon, Mar 14, 2016 at 06:27:24PM -0400, David Michael wrote: > > The realtek board shouldn't be working without DDE... Something looks > > wrong in your test setup. > > I've been using it almost exclusively for the last three or four years > without DDE. It works fine for me until I try to chan

Re: Testing requested for the next version of GNU Mach

On Sun, Mar 13, 2016 at 9:06 AM, Richard Braun wrote: > On Fri, Mar 11, 2016 at 05:38:06PM -0500, David Michael wrote: >> I didn't get a chance to try with Debian yet, but after looking a bit >> more, the failure I'm getting is from linux_kmem_init() allocating >> memory. It panics in vm_page_gra

Re: Testing requested for the next version of GNU Mach

On Fri, Mar 11, 2016 at 05:38:06PM -0500, David Michael wrote: > I didn't get a chance to try with Debian yet, but after looking a bit > more, the failure I'm getting is from linux_kmem_init() allocating > memory. It panics in vm_page_grab_contig() when allocating the 29th > (i=28) chunk. This me

Re: Testing requested for the next version of GNU Mach

David Michael, on Fri 11 Mar 2016 17:38:06 -0500, wrote: > but I will try to see what Debian is doing differently over the > weekend. Debian simply doesn't use those drivers any more, but netdde instead. Samuel

Re: Testing requested for the next version of GNU Mach

On Wed, Mar 9, 2016 at 2:57 PM, Richard Braun wrote: > On Tue, Mar 08, 2016 at 12:15:25PM -0500, David Michael wrote: >> So unless rtl8139 bits are still hidden somewhere (grep only finds >> some PCI ID definitions), it looks like there may be a different >> problem. >

Re: Testing requested for the next version of GNU Mach

On Tue, Mar 08, 2016 at 12:15:25PM -0500, David Michael wrote: > So unless rtl8139 bits are still hidden somewhere (grep only finds > some PCI ID definitions), it looks like there may be a different > problem. Building GNU Mach with : --enable-silent-rules --enable-kdb --enable-ide

Re: Testing requested for the next version of GNU Mach

On Tue, Mar 08, 2016 at 12:15:25PM -0500, David Michael wrote: > I've just removed linux/src/drivers/net/rtl8139.c and dropped all > references to rtl8139 from the following files Please use --disable-rtl8139 instead, and only use GRUB as configured by Debian so that we restrict the variables of o

Re: Testing requested for the next version of GNU Mach

On Tue, Mar 8, 2016 at 10:00 AM, David Michael wrote: > On Tue, Mar 8, 2016 at 5:06 AM, Richard Braun wrote: >> In any case, this isn't a regression caused by my work, and I don't >> intend to fix in-kernel drivers, in particular when we have a good >> user space replacement. As a result, I sugge

Re: Testing requested for the next version of GNU Mach

On Tue, Mar 8, 2016 at 5:06 AM, Richard Braun wrote: > In any case, this isn't a regression caused by my work, and I don't > intend to fix in-kernel drivers, in particular when we have a good > user space replacement. As a result, I suggest we remove the rtl8139 > driver from the kernel. That's p

Re: Testing requested for the next version of GNU Mach

On Mon, Mar 07, 2016 at 11:01:47PM -0500, David Michael wrote: > Yes, this was when booting gnumach in QEMU with -device rtl8139 for a > net device. Here is the situation : At some point in 2006 (but apparently merged in 2009), netdrivers, the network drivers written by Donald Becker, were update

Re: Testing requested for the next version of GNU Mach

On Mon, Mar 7, 2016 at 8:56 PM, Richard Braun wrote: > On Tue, Mar 08, 2016 at 12:00:03AM +0100, Richard Braun wrote: >> On Sun, Feb 28, 2016 at 03:50:06PM -0500, David Michael wrote: >> > Yes, that did it. The latest gnumach can be booted with GRUB when >> > those options are disabled. >> >> It

Re: Testing requested for the next version of GNU Mach

On Tue, Mar 08, 2016 at 12:00:03AM +0100, Richard Braun wrote: > On Sun, Feb 28, 2016 at 03:50:06PM -0500, David Michael wrote: > > Yes, that did it. The latest gnumach can be booted with GRUB when > > those options are disabled. > > It seems we've been having this bug for a long time, but noone

Re: Testing requested for the next version of GNU Mach

On Sun, Feb 28, 2016 at 03:50:06PM -0500, David Michael wrote: > On Sun, Feb 28, 2016 at 3:37 PM, Richard Braun wrote: > > On Sun, Feb 28, 2016 at 03:27:50PM -0500, David Michael wrote: > >> The same GRUB has no problem booting older gnumach (bee3f0) or Linux. > >> Are you aware of any patches req

Re: Testing requested for the next version of GNU Mach

On Sun, Feb 28, 2016 at 03:50:06PM -0500, David Michael wrote: > > It's not related to GRUB at all apparently. My guess is something got > > wrong in the Linux glue code for in kernel drivers. Could you build > > gnumach with --disable-net-group --disable-pcmcia-group > > --disable-wireless-group a

Re: USB keyboard driver the GNU Mach

f getting the hurd running on an > oldish PC on bare metal. The first issue I encountered is that the PC does > not have a PS/2 port and the BIOS does not seem of offer any emulation. GNU > Mach does have any support for usb as far as I could tell. > > I have worked to re-purpose some

USB keyboard driver the GNU Mach

port and the BIOS does not seem of offer any emulation. GNU Mach does have any support for usb as far as I could tell. I have worked to re-purpose some old (2.4.x) Linux kernel usb code to produce a basic usb keyboard driver for GNU Mach. It is a bit more than a key board driver. It is a usb hardware

Re: Testing requested for the next version of GNU Mach

On Sun, Feb 28, 2016 at 3:37 PM, Richard Braun wrote: > On Sun, Feb 28, 2016 at 03:27:50PM -0500, David Michael wrote: >> The same GRUB has no problem booting older gnumach (bee3f0) or Linux. >> Are you aware of any patches required by GRUB to boot the X15 >> multiboot/biosmem bits? > > Thanks for

Re: Testing requested for the next version of GNU Mach

On Sun, Feb 28, 2016 at 03:27:50PM -0500, David Michael wrote: > The same GRUB has no problem booting older gnumach (bee3f0) or Linux. > Are you aware of any patches required by GRUB to boot the X15 > multiboot/biosmem bits? Thanks for your report. It's not related to GRUB at all apparently. My g

Re: Testing requested for the next version of GNU Mach

3 release) built for the i386-pc platform, the following is displayed for a fraction of a second before the system reboots: GNU Mach 1.6 ELF section header table at c0010278 biosmem: physical memory map: biosmem: 00:09fc00, available biosmem: 09fc00:

Testing requested for the next version of GNU Mach

Hello, As part of the next GNU Mach release, the physical allocator has been completely changed in favor of a more standard buddy allocator (finally) and the kernel allocator can service much more memory for its objects, making kernel memory exhaustion very unlikely. Considering we can now

GNU Hurd 0.7, GNU Mach 1.6, GNU MIG 1.6 released

Hi! Please see <http://www.gnu.org/software/hurd/news/2015-10-31-releases.html>. Text-only version: | GNU Hurd 0.7, GNU Mach 1.6, GNU MIG 1.6 released. | | We're pleased to announce new releases! | | GNU Hurd 0.7, NEWS: | | Version 0.7 (2015-10-31) | | | The no

Rework *.msgids handling when neither client nor server stubs are required (was: [SCM] GNU Mach branch, master, updated. v1.5-32-g255c47e)

Hi! On Sun, 31 May 2015 16:01:54 +, Justus Winter <4win...@informatik.uni-hamburg.de> wrote: > commit 255c47e669819f153c722c98a230f6fe4e6ece08 > Author: Justus Winter <4win...@informatik.uni-hamburg.de> > Date: Sun May 25 16:26:42 2014 +0200 > > Include the notify protocol in `gnumach.

GNU Mach 1.5 released

Hi! We're pleased to announce version 1.5 of GNU Mach, the GNU distribution of the Mach microkernel, <http://www.gnu.org/software/hurd/microkernel/mach/gnumach.html>. GNU Mach is the microkernel upon which a GNU Hurd system is based. It provides an Inter Process Communication (IPC

Re: protected payloads for GNU Mach

Quoting Richard Braun (2014-02-19 10:47:03) > On Tue, Feb 18, 2014 at 09:49:23PM -0800, Samuel Thibault wrote: > > Apart from that and perhaps a function to clear the protected payload > > value (which may however not be really useful), the whole thing seems > > interesting and good to me, do other

Re: protected payloads for GNU Mach

On Tue, Feb 18, 2014 at 09:49:23PM -0800, Samuel Thibault wrote: > Apart from that and perhaps a function to clear the protected payload > value (which may however not be really useful), the whole thing seems > interesting and good to me, do other people agree? Well, since I've pushed that as a pr

Re: protected payloads for GNU Mach

Hello, Documentation changes should rather be commited along the source code change. Apart from that and perhaps a function to clear the protected payload value (which may however not be really useful), the whole thing seems interesting and good to me, do other people agree? Samuel

protected payloads for GNU Mach

Hi :) this patch series implements protected payloads on top of the mach messaging system. It preserves the semantics for programs not using this functionality. This is the kernel part of my work that will (hopefully) speed up the Hurd. For a detailed sketch see: id:20131128235647.1092.90...@t

Re: continuous integration // GNU Mach for Xen fails to build

Quoting Justus Winter (2013-12-18 12:38:31) > While doing that I discovered that the recent cleanups broke GNU Mach > when compiled for the Xen target. Two issues were merely missing > includes, but now it fails like this: > > % ./configure --enable-kdb --enable-platform=xen --enab

continuous integration // GNU Mach for Xen fails to build

Hi :) I've been playing around with buildbot, the goal is to automatically produce Debian packages from the upstream git repositories. This is work in progress. To that end I took the Debian repositories of Hurd, MIG and GNU Mach and removed anything that is present in the upstream reposit

Implementing protected payloads in GNU Mach, mig, and the Hurd

, matching the sender thread to the receiver. 2. In libports, in either manage_multithread or manage_one_thread. 3. In the in-translator function defined for file_t by setting FILE_INTRANS. This patch set adds support for protected payloads to GNU Mach, mig and the Hurd. It adds an kernel call to

[task #5782] Handling of large memory equipment by GNU Mach

Update of task #5782 (project hurd): Status:None => Cancelled Open/Closed:Open => Closed ___ Reply to this item at:

[task #6111] Release GNU Mach 1.4

Update of task #6111 (project hurd): Status: In Progress => Done Percent Complete: 0% => 100% Open/Closed:Open => Closed _

Happy 30th birthday, GNU! GNU Mach 1.4 released

Hi! It is the GNU project's 30th birthday, and we are pleased to announce version 1.4 of GNU Mach, the GNU distribution of the Mach microkernel, <http://www.gnu.org/software/hurd/microkernel/mach/gnumach.html>. GNU Mach is the microkernel upon which a GNU Hurd system is based. It

Re: [SCM] GNU Mach branch, master, updated. 471e5b080f7790c2cf95e3069d9fed1173c9ec17

Svante Signell, le Fri 27 Sep 2013 16:52:36 +0200, a écrit : > I found a small spelling mistake in the above text: > We don't turn it on be default -> We don't turn it on by default Indeed, thanks. Samuel

Re: [SCM] GNU Mach branch, master, updated. 471e5b080f7790c2cf95e3069d9fed1173c9ec17

On Fri, 2013-09-27 at 16:26 +0200, Thomas Schwinge wrote: > Hi! > > On Wed, 25 Sep 2013 23:29:22 +, Samuel Thibault > wrote: > > commit 471e5b080f7790c2cf95e3069d9fed1173c9ec17 > > Author: Samuel Thibault > > Date: Thu Sep 26 01:28:45 2013 +0200 > @@ -26,20 +26,12 @@ debugging the kernel

Re: [SCM] GNU Mach branch, master, updated. 471e5b080f7790c2cf95e3069d9fed1173c9ec17

Thomas Schwinge, le Fri 27 Sep 2013 16:26:33 +0200, a écrit : > I suggest to simplify that as follows, OK? > > +$ [...]/configure --host=i686-gnu CC='gcc -m32' LD='ld -melf_i386' Ah, right, yes. Samuel

Re: [SCM] GNU Mach branch, master, updated. 471e5b080f7790c2cf95e3069d9fed1173c9ec17

eable memory footprint of the kernel. -The specific switches you give to configure are always recorded in the -file `config.status'. So you can always tell what options you used to -build a particular kernel. +GNU Mach can be cross-built. No specific options need to be given when +building

Re: GNU Mach

Kevin Madhu, le Sat 23 Feb 2013 07:57:22 +0530, a écrit : > Have you guys given up on my problem? We actually don't understand what is happening: things seem to be right, except that the mig command being invoked does not like the input, which *is* really right. My only guess is that the mig

Re: GNU Mach

Hi, Have you guys given up on my problem? On Wed, Feb 20, 2013 at 4:18 PM, Kevin Madhu wrote: > I found the file you were asking for. But im afraid i do not see the other > three files anywhere(memory_object_user.user.c, memory_object_user.user.h, > memory_object_user.user.msgids). Are the

Re: GNU Mach

I found the file you were asking for. But im afraid i do not see the other three files anywhere(memory_object_user.user.c, memory_object_user.user.h, memory_object_user.user.msgids). Are they suppossed to be mig's output? On Wed, Feb 20, 2013 at 1:47 PM, Thomas Schwinge wrote: > Hi! > > On Wed,

Re: GNU Mach

Hi! On Wed, 20 Feb 2013 10:15:34 +0530, Kevin Madhu wrote: >I pulled the code from git repository only and its up-to-date(mig - > http://git.savannah.gnu.org/cgit/hurd/mig.git/, mach - > http://git.savannah.gnu.org/cgit/hurd/gnumach.git/). And following the > instructions, I successfully

  1   2   3   4   5   6   7   >