Justus Winter, le Thu 15 May 2014 23:10:51 +0200, a écrit :
> * include/refcount.h: New file.
Ack.
> ---
> include/refcount.h | 263
> +
> 1 file changed, 263 insertions(+)
> create mode 100644 include/refcount.h
>
> diff --git a/include/ref
Justus Winter, le Thu 15 May 2014 23:10:50 +0200, a écrit :
> If libihash is used to implement a cache, a insertion is always
> preceeded by a lookup. hurd_ihash_add has to do the lookup again.
>
> Provide a new pair of functions, hurd_ihash_locp_add and
> hurd_ihash_locp_find, that can be used i
Justus Winter, le Thu 15 May 2014 23:10:49 +0200, a écrit :
> * libihash/ihash.h (hurd_ihash_value_valid): New function.
> * libihash/ihash.c (index_empty): Use hurd_ihash_value_valid.
Ack.
> ---
> libihash/ihash.c | 3 +--
> libihash/ihash.h | 7 +++
> 2 files changed, 8 insertions(+), 2 de
Justus Winter, le Thu 15 May 2014 23:10:48 +0200, a écrit :
> * libihash/ihash.c (hurd_ihash_add): Move the code computing the load
> factor of the hash table...
> * libihash/ihash.h (hurd_ihash_get_load): ... here, together with the
> comment describing the method and the rationale for chosing bin
Justus Winter, le Thu 15 May 2014 23:10:47 +0200, a écrit :
> * libihash/ihash.c (hurd_ihash_add): Fix typo.
Ack.
> ---
> libihash/ihash.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libihash/ihash.c b/libihash/ihash.c
> index 151c1a7..f20ba61 100644
> --- a/libihas
Svante Signell, le Fri 16 May 2014 10:03:05 +0200, a écrit :
> is used in gcc-4.9-4.9.0/src/libgo/go/net/fd_unix.go:
> func dupCloseOnExec(fd int) (newfd int, err error) {
> if atomic.LoadInt32(&tryDupCloexec) == 1 && syscall.F_DUPFD_CLOEXEC!=0 {
> r0, _, e1 := syscall.Syscall(syscall.SYS_FCNTL, ui
Richard Braun, le Wed 21 May 2014 00:45:51 +0200, a écrit :
> On Tue, May 20, 2014 at 11:50:28PM +0200, Samuel Thibault wrote:
> > Richard Braun, le Tue 20 May 2014 23:42:24 +0200, a écrit :
> > > On Tue, May 20, 2014 at 10:50:07PM +0200, Samuel Thibault wrote:
> > > > I would advise starting with
On Tue, May 20, 2014 at 11:50:28PM +0200, Samuel Thibault wrote:
> Richard Braun, le Tue 20 May 2014 23:42:24 +0200, a écrit :
> > On Tue, May 20, 2014 at 10:50:07PM +0200, Samuel Thibault wrote:
> > > I would advise starting with trivial system calls, such as
> > > mach_thread_self, mach_task_self
Richard Braun, le Tue 20 May 2014 23:42:24 +0200, a écrit :
> On Tue, May 20, 2014 at 10:50:07PM +0200, Samuel Thibault wrote:
> > I would advise starting with trivial system calls, such as
> > mach_thread_self, mach_task_self, and mach_host_self, which don't take
> > any parameter, and just return
On Tue, May 20, 2014 at 10:50:07PM +0200, Samuel Thibault wrote:
> I would advise starting with trivial system calls, such as
> mach_thread_self, mach_task_self, and mach_host_self, which don't take
> any parameter, and just returns a port. That'll make you implement the
> basic infrastructure for
I forgot to mention: please come and stay on #hurd, so we get to talk
whenever we happen to be connected at the same time. You will very
probably need help with diving into valgrind and gnumach, don't hesitate
to ask questions, we're here to help you! (but we can't help you if you
don't come and as
Hello,
I would advise starting with trivial system calls, such as
mach_thread_self, mach_task_self, and mach_host_self, which don't take
any parameter, and just returns a port. That'll make you implement the
basic infrastructure for the trap call.
Then calls like task_terminate, task_suspend, etc
Hello,
Justus Winter, le Sun 18 May 2014 15:24:52 +0200, a écrit :
> - ino64_t cache_id;
> -
>int author_tracks_uid;
> +
> + /* This is the last field. We do this so that if the node is
> + allocated with the disknode in an contiguous block, it sits right
> + next to the user suppli
Source: since
Version:
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
Hi,
Currently since fails to build from source on GNU/Hurd due to failed
tests. The problem is that dev_t is an unsigned integer, i.e. 4 bytes,
on Hurd but since expects dev_t to be 8 bytes
Justus Winter, le Tue 20 May 2014 09:46:02 +0200, a écrit :
> As of recently, fakeroot would fail to create symlinks:
>
> % fakeroot-hurd ln -s foo a
> ln: failed to create symbolic link ‘a’: Operation not permitted
>
> Fix this by overriding fshelp_isowner.
>
> Various netfs functions will call
As of recently, fakeroot would fail to create symlinks:
% fakeroot-hurd ln -s foo a
ln: failed to create symbolic link ‘a’: Operation not permitted
Fix this by overriding fshelp_isowner.
Various netfs functions will call fshelp_isowner to check whether USER
is allowed to do some operation. As f
16 matches
Mail list logo
