USB keyboard driver the GNU Mach

This does not seem like the right forum for this post, but this list looks like the only hurd list with any activity, so here goes. I have taken on the project this year of 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 por

Re: GSoC ideas

On Sun, Feb 28, 2016 at 11:12:25PM +0100, Samuel Thibault wrote: > Just sending my big +1 on this project :) Same here. I'd like to note that I'm personally pushing so that we have less students but with better projects. This one definitely fits. -- Richard Braun

Re: RFC: Lightweight synchronization mechanism for gnumach

On Sun, Feb 28, 2016 at 11:05:19PM +0100, Samuel Thibault wrote: > Agustina Arzille, on Sun 28 Feb 2016 18:52:26 -0300, wrote: > > programs (At least, I hope it isn't), but I think it serves to illustrate > > the performance of each implementation under heavy contention. > > I don't think there is

Re: Rework of the userspace interrupt handling patch

Justus Winter, on Sun 28 Feb 2016 23:51:40 +0100, wrote: > Quoting Samuel Thibault (2016-02-28 22:35:14) > > Justus Winter, on Sun 28 Feb 2016 00:33:20 +0100, wrote: > > > 3/ ... instead the notification message carries a send right as the > > > reply port, and the userspace server acknowledges the

Re: Rework of the userspace interrupt handling patch

Quoting Samuel Thibault (2016-02-28 22:35:14) > Justus Winter, on Sun 28 Feb 2016 00:33:20 +0100, wrote: > > 3/ ... instead the notification message carries a send right as the > > reply port, and the userspace server acknowledges the interrupt by > > deallocating this right. > > That makes much m

Re: GSoC ideas

Hello, Just sending my big +1 on this project :) Samuel

Re: RFC: Lightweight synchronization mechanism for gnumach

Agustina Arzille, on Sun 28 Feb 2016 18:52:26 -0300, wrote: > programs (At least, I hope it isn't), but I think it serves to illustrate > the performance of each implementation under heavy contention. I don't think there is heavy contention actually :) Since it's uni-processor, switches between t

Re: RFC: Lightweight synchronization mechanism for gnumach

On 02/28/2016 06:32 PM, Samuel Thibault wrote: Hello, Agustina Arzille, on Sun 28 Feb 2016 14:22:03 -0300, wrote: Here's a rough comparison of how locking is implemented in libpthread, and the futex prototype I posted. Did you make measurements? It'd be interesting to post them here. Samuel

Re: Rework of the userspace interrupt handling patch

Justus Winter, on Sun 28 Feb 2016 00:33:20 +0100, wrote: > 3/ ... instead the notification message carries a send right as the > reply port, and the userspace server acknowledges the interrupt by > deallocating this right. That makes much more sense to me than the current disable/enable. I guess

Re: RFC: Lightweight synchronization mechanism for gnumach

Hello, Agustina Arzille, on Sun 28 Feb 2016 14:22:03 -0300, wrote: > Here's a rough comparison of how locking is implemented in libpthread, > and the futex prototype I posted. Did you make measurements? It'd be interesting to post them here. Samuel

Re: RFC: Lightweight synchronization mechanism for gnumach

Hello, That's really cool :) The implementation needs to be reviewed, but the interface looks good. We'll probably want to have a copyright assignement from you for this work. I have pasted below the form for this. If you're to contribute more to GNU/Hurd, it'd be useful that you already assig

Re: dlerror sets errno to ENOSYS

Diego Nieto Cid, on Sun 28 Feb 2016 16:53:51 -0300, wrote: > On Sun, Feb 28, 2016 at 07:57:43PM +0100, Samuel Thibault wrote: > > > > Using watch in gdb :) > > > > I've added fprintf(stderr,"%p\n", &errno); to get the address of errno: > > > > Oh, that's interesting. I've been struggling with "

Re: dlerror sets errno to ENOSYS

Hi On Sun, Feb 28, 2016 at 07:57:43PM +0100, Samuel Thibault wrote: > > Using watch in gdb :) > > I've added fprintf(stderr,"%p\n", &errno); to get the address of errno: > Oh, that's interesting. I've been struggling with "display errno", or "display *__errno_location()" without success. > >

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

Hi, I haven't been able to boot gnumach with upstream GRUB since this X15 code was imported. It does boot successfully with QEMU's multiboot arguments, and it seems fine when it's running. When booting the latest gnumach (689810) with GRUB (both old versions and today's beta3 release) built for

Re: RFC: Lightweight synchronization mechanism for gnumach

On Sun, Feb 28, 2016 at 04:13:34PM -0300, Agustina Arzille wrote: > I named it differently because I feel "futex" doesn't really convey what it > does, but I agree that consistency with standards (even de facto ones) is > a good idea. I agree, Linux sucks at names and they even acknowledge it. As

Re: RFC: Lightweight synchronization mechanism for gnumach

On 02/28/2016 02:59 PM, Richard Braun wrote: On Sat, Feb 27, 2016 at 10:53:12PM -0300, Agustina Arzille wrote: Hello, everyone. Here's a patch for gnumach that implements a lightweight synchronization mechanism. It can be used as a basis to build many higher-level objects like mutexes, semapho

Re: dlerror sets errno to ENOSYS

Hello, Diego Nieto Cid, on Sun 28 Feb 2016 01:10:27 -0300, wrote: > Any ideas? Using watch in gdb :) I've added fprintf(stderr,"%p\n", &errno); to get the address of errno: (gdb) r Starting program: /home/samy/main [New Thread 28384.6] Breakpoint 1, main (argc=1, argv=0x102bda4) at main.c:11

Re: RFC: Lightweight synchronization mechanism for gnumach

On Sun, Feb 28, 2016 at 06:01:03PM +0100, Justus Winter wrote: > I'm curious why your mechanism is faster, because you implemented it > using messages sent to the kernel using mach_msg, and not as traps. > This is ok for a prototype of course, but you should look at how > e.g. mach_port_deallocate

Re: RFC: Lightweight synchronization mechanism for gnumach

On Sat, Feb 27, 2016 at 10:53:12PM -0300, Agustina Arzille wrote: > Hello, everyone. > > Here's a patch for gnumach that implements a lightweight synchronization > mechanism. It can be used as a basis to build many higher-level objects like > mutexes, semaphores, etc. Given its genericity, and bec

Re: RFC: Lightweight synchronization mechanism for gnumach

On 02/28/2016 02:01 PM, Justus Winter wrote: Hi :) thanks for your prototype. I cannot comment on the primitive you implemented because I'm lacking the expertise, however Quoting Agustina Arzille (2016-02-28 02:53:12) I've tested it in many scenarios, and seems to work fine. I've benchmarked

Re: RFC: Lightweight synchronization mechanism for gnumach

Justus Winter, on Sun 28 Feb 2016 18:01:03 +0100, wrote: > you implemented it using messages sent to the kernel using mach_msg, > and not as traps. This is surprising indeed. I don't think we will ever need this as an RPC. Samuel

Re: RFC: Lightweight synchronization mechanism for gnumach

Hi :) thanks for your prototype. I cannot comment on the primitive you implemented because I'm lacking the expertise, however Quoting Agustina Arzille (2016-02-28 02:53:12) > I've tested it in many scenarios, and seems to work fine. I've > benchmarked it as well, and it's far more faster than pt

Re: RFC: Lightweight synchronization mechanism for gnumach

As a followup, here's how one would use gsync to implement something akin to Linux futexes. === #include #include /* This bit signals that the lock is being held. The rest of * the word tells us how many waiters there are. */ #define BIT31 (1U << 31) #define at

Re: [PATCH] Fix use-after-free in libps.

On Sun, Feb 28, 2016 at 10:43:04AM +0100, Samuel Thibault wrote: > Esa Peuha, on Sun 28 Feb 2016 11:00:07 +0200, wrote: > > > The attachment is the entire output of git format-patch; I think it's > > the best I can do when using Gmail to send mail. > > That will work fine, but it'll be tedious fo

[bug #32770] /proc/$pid/maps should contain the file names backing the mappings

Follow-up Comment #5, bug #32770 (project hurd): That's what I suggested at the time, yes. ___ Reply to this item at: ___ Message posté via/par Savannah

[bug #32770] /proc/$pid/maps should contain the file names backing the mappings

Update of bug #32770 (project hurd): Summary: Add /proc/$pid/maps => /proc/$pid/maps should contain the file names backing the mappings ___ Follow-up Comment #4: Maybe we can get away with labeling the kernel objects l

[bug #32770] Add /proc/$pid/maps

Update of bug #32770 (project hurd): Status: Fixed => In Progress Open/Closed: Closed => Open Wiki-like text discussion box: => Mmm, I'd prefer to reopen this: /proc/$pid/maps d

[bug #32770] Add /proc/$pid/maps

Update of bug #32770 (project hurd): Wiki-like text discussion box: Mmm, I'd prefer to reopen this: /proc/$pid/maps does not contain the names of the files, which considerably reduces its usefulness. => ___ Follow-up

RFC: Lightweight synchronization mechanism for gnumach

Hello, everyone. Here's a patch for gnumach that implements a lightweight synchronization mechanism. It can be used as a basis to build many higher-level objects like mutexes, semaphores, etc. Given its genericity, and because I'm terrible at naming things, I decided to name this module "gsync

Re: [PATCH] Fix use-after-free in libps.

Esa Peuha, on Sun 28 Feb 2016 11:00:07 +0200, wrote: > Here is a patch to fix a use-after-free bug in libps. Good catch, thanks! > The attachment is the entire output of git format-patch; I think it's > the best I can do when using Gmail to send mail. That will work fine, but it'll be tedious fo

[PATCH] Fix use-after-free in libps.

Here is a patch to fix a use-after-free bug in libps. The attachment is the entire output of git format-patch; I think it's the best I can do when using Gmail to send mail. From c99837f5874c0983e0bcb1d2704c241d4a2aa10d Mon Sep 17 00:00:00 2001 From: Esa Peuha Date: Sat, 27 Feb 2016 09:59:13 +0200