Re: Coppyright assignment

2016-03-04 Thread Ludovic Courtès
Justus Winter <4win...@informatik.uni-hamburg.de> skribis:

> I have learned that not all GNU projects require this.  For example,
> GnuPG uses DCO [0], and Guix doesn't even seem to require that.
>
> Maybe we can change this policy for Hurd, GNU Mach, and MIG too?

I general, we “cannot” (i.e., are invited not to) change GNU packages
from requiring-assignment to no-assignment policy (although I guess
GnuPG did exactly that…).

Hopefully paperwork is fast enough these days anyway.

Ludo’.




Re: Coppyright assignment

2016-03-04 Thread Justus Winter
Quoting Ludovic Courtès (2016-03-04 13:49:09)
> Justus Winter <4win...@informatik.uni-hamburg.de> skribis:
> 
> > I have learned that not all GNU projects require this.  For example,
> > GnuPG uses DCO [0], and Guix doesn't even seem to require that.
> >
> > Maybe we can change this policy for Hurd, GNU Mach, and MIG too?
> 
> I general, we “cannot” (i.e., are invited not to) change GNU packages
> from requiring-assignment to no-assignment policy (although I guess
> GnuPG did exactly that…).

So one can do that.  I see it as an barrier for contributing.

> Hopefully paperwork is fast enough these days anyway.

I don't know how it is nowadays (maybe someone can enlighten us?), but
when I did that like three years ago the process took weeks and
required quite a bit of nagging.

Justus



RFC: Lightweight synchronization mechanism for gnumach v2.0

2016-03-04 Thread Agustina Arzille

Hello, everyone,

I got some very positive feedback last time, so I decided to work on a 
new

version. I've streamlined things a bit, introducing a key type to handle
lookups, and moved a bit of code around into new functions.

The biggest change, however, is the 'gsync_requeue' RPC. It allows one 
to move
blocking threads so that they wait on a different address. It's not as 
useful
as the other 2 RPC's, but it can be used to optimize POSIX condition 
variables

to avoid the infamous 'thundering herd' problem.

This patch is a bit longer than the one before, so I'm sending it as an
attachment instead of copying its contents here.

As before, any comments, advice or questions are very welcomed.

diff --git a/include/mach/gnumach.defs b/include/mach/gnumach.defs
index dd4da87..5235df6 100644
--- a/include/mach/gnumach.defs
+++ b/include/mach/gnumach.defs
@@ -84,3 +84,55 @@ simpleroutine task_set_name(
 routine register_new_task_notification(
 		host_priv	: host_priv_t;
 		notification	: mach_port_send_t);
+
+/* Test that the contents of ADDR are equal to the 32-bit integer VAL1.
+ * If they are not, return immediately, otherwise, block until a
+ * matching 'gsync_wake' is done on the same address. FLAGS is used
+ * to control how the thread waits, and may be composed of:
+ * - GSYNC_SHARED: The address may be shared among tasks. If this
+ bit is not set, the address is assumed to be task-local.
+ * - GSYNC_QUAD: Additionally check that the adjacent 32-bit word
+ following ADDR matches the value VAL2.
+ * - GSYNC_TIMED: The call only blocks for MSEC milliseconds. */
+routine gsync_wait(
+  task : task_t;
+  addr : vm_offset_t;
+  val1 : unsigned;
+  val2 : unsigned;
+  msec : natural_t;
+  flags : int);
+
+/* Wake up threads waiting on the address ADDR. Much like with
+ * 'gsync_wait', the parameter FLAGS controls how it is done. In this
+ * case, it may be composed of the following:
+ * - GSYNC_SHARED: Same as with 'gsync_wait'.
+ * - GSYNC_BROADCAST: Wake up every thread waiting on the address. If
+ *   this flag is not set, the call wakes (at most) 1 thread.
+ * - GSYNC_MUTATE: Before waking any potential waiting threads, set the
+ *   contents of ADDR to VAL.
+ *
+ * This RPC is implemented as a simple routine for efficiency reasons,
+ * and because the return value rarely matters. */
+simpleroutine gsync_wake(
+  task : task_t;
+  addr : vm_offset_t;
+  val : unsigned;
+  flags : int);
+
+/* Arrange for threads waiting on address SRC_ADDR to instead
+ * wait on address DST_ADDR. If WAKE_ONE is true, additionally
+ * wake one of the threads waiting on SRC_ADDR. For this function,
+ * the parameter flags may be a combination of:
+ * - GSYNC_SHARED: Just like with 'gsync_wait' and 'gsync_wake'.
+ * - GSYNC_BROADCAST: Move all the threads waiting on SRC_ADDR. If
+ this flag is not set, the call moves (at most) 1 thread.
+ *
+ * This RPC is also a simple routine, and for the same reasons as
+ * with 'gsync_wake'. */
+simpleroutine gsync_requeue(
+  task : task_t;
+  src_addr : vm_offset_t;
+  dst_addr : vm_offset_t;
+  wake_one : boolean_t;
+  flags : int);
+
diff --git a/kern/gsync.c b/kern/gsync.c
new file mode 100644
index 000..12398ab
--- /dev/null
+++ b/kern/gsync.c
@@ -0,0 +1,381 @@
+/* Copyright (C) 2016 Free Software Foundation, Inc.
+   Contributed by Agustina Arzille , 2016.
+
+   This program is free software; you can redistribute it and/or
+   modify it under the terms of the GNU General Public License
+   as published by the Free Software Foundation; either
+   version 3 of the license, or (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public
+   License along with this program; if not, see
+   .
+*/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* An entry in the global hash table. */
+struct gsync_hbucket
+{
+  struct list entries;
+  decl_simple_lock_data (, lock)
+};
+
+/* A key used to uniquely identify an address that a thread is
+ * waiting on. Its members' values depend on whether said
+ * address is shared or task-local. */
+struct gsync_key
+{
+  unsigned long u;
+  unsigned long v;
+};
+
+/* A thread that is blocked on an address with 'gsync_wait'. */
+struct gsync_waiter
+{
+  struct list link;
+  struct gsync_key key;
+  thread_t waiter;
+};
+
+#define GSYNC_NBUCKETS   512
+static struct gsync_hbucket gsync_buckets[GSYNC_NBUCKETS];
+
+void gsync_setup (void)
+{
+  for (int i = 0; i < GSYNC_NBUCKETS; ++i)
+{
+  list_init (&gsync_buckets[i].entries);
+  simple_lock_init (&gsync_buckets[i].lock);
+}
+}
+
+/* Convenience comparison functions for gsync_key's. */
+
+static inline int
+gsync_key_eq (const struc

Re: GSoC ideas

2016-03-04 Thread Manolis Ragkousis
Hey

On 03/02/16 23:31, Ludovic Courtès wrote:
> Do you have examples of GNU/Linux uses that would make no sense?
> 

After a quick look in mount's man page I think that maybe Roland was
referring to some flags (like relatime for example) that when passed to
mount, expect the Linux kernel to handle the filesystem in a specific way.

> Other options include calling out to the ‘settrans’ command (inelegant
> IMO), writing Guile bindings for some of the Hurd libraries, and/or some
> sort of a MiG in Scheme (neat but takes some time!).

We could have a guile wrapper for the ‘settrans’ command that could
cover our needs. Isn't this feasible? WDYT?

Manolis



Re: Coppyright assignment

2016-03-04 Thread Ludovic Courtès
Justus Winter <4win...@informatik.uni-hamburg.de> skribis:

> Quoting Ludovic Courtès (2016-03-04 13:49:09)
>> Justus Winter <4win...@informatik.uni-hamburg.de> skribis:
>> 
>> > I have learned that not all GNU projects require this.  For example,
>> > GnuPG uses DCO [0], and Guix doesn't even seem to require that.
>> >
>> > Maybe we can change this policy for Hurd, GNU Mach, and MIG too?
>> 
>> I general, we “cannot” (i.e., are invited not to) change GNU packages
>> from requiring-assignment to no-assignment policy (although I guess
>> GnuPG did exactly that…).
>
> So one can do that.

Everything can be done, but ultimately it’s a matter of reaching
consensus.

> I see it as an barrier for contributing.

Right, but whether it’s a good idea depends on a number of other
factors.  For Guix, copyright assignment would have been a hindrance
IMO, but what’s at stake is different than for libc or GCC, for
instance.

>> Hopefully paperwork is fast enough these days anyway.
>
> I don't know how it is nowadays (maybe someone can enlighten us?), but
> when I did that like three years ago the process took weeks and
> required quite a bit of nagging.

Use of PDFs has helped a bit:

  https://www.gnu.org/prep/maintain/html_node/Copyright-Papers.html

as well as digital signatures in some cases:

  
https://www.fsf.org/blogs/licensing/fsf-to-begin-accepting-gpg-signed-assignments-from-the-u-s
  
https://www.fsf.org/blogs/licensing/fsf-to-begin-accepting-gpg-signatures-for-copyright-assignments-from-italy

Ludo’.




fakeroot-hurd doesn't work with scripts

2016-03-04 Thread Samuel Thibault
Hello,

We have an issue between fakeroot and scripts (from the borgbackup build
log):

> fakeroot dh_auto_test
> Can't open perl script "dh_auto_test": No such file or directory

I guess that's due to the way fakeauth starts the program, I haven't
looked further.

Samuel



Gsoc 2016 Ideas

2016-03-04 Thread Vasantha Ganesh K
Hello everyone,
  I would like to work on "Porting Valgrind to the Hurd" from the ideas page 
of gsoc 2016.
Vasantha Ganesh K