Re: hurd and BIOS/RTC problem

2014-05-15 Thread Riccardo Mottola
Hi, Samuel Thibault wrote: The default seems to be yes, according to /etc/init.d/hwclock.sh. You could try to set it to no. Samuel I set it to "no" and uncommented the line, i still have the problem. It is interesting that a single-boot user too yields the problem. However if booting gets int

Re: implicit declaration of function 'thread_terminate_release'

2014-05-15 Thread Samuel Thibault
Hello, Manolis Ragkousis, le Thu 15 May 2014 21:08:41 +, a écrit : > I grep-searhed both glibc and libpthread and I can't find any > declaration of thread_terminate_release anywhere in them. > > Justus told me that it got recently added to gnumach. Yes, as an RPC. The declaration and defini

[PATCH 4/5] libihash: optimize lookup-or-insert operations

2014-05-15 Thread Justus Winter
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 in combination to avoid the second lookup. * libihash/ihash.c (hurd_ih

[PATCH 2/5] libihash: add hurd_ihash_get_load

2014-05-15 Thread Justus Winter
* 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 binary percent. --- libihash/ihash.c | 20 ++-- libiha

next round of patches

2014-05-15 Thread Justus Winter
Hi :) [PATCH 1/5] libihash: fix typo [PATCH 2/5] libihash: add hurd_ihash_get_load This also makes the description of binary percent more prominent. [PATCH 3/5] libihash: add hurd_ihash_value_valid [PATCH 4/5] libihash: optimize lookup-or-insert operations I'm replacing the node caches in {ext2

[PATCH 1/5] libihash: fix typo

2014-05-15 Thread Justus Winter
* libihash/ihash.c (hurd_ihash_add): Fix typo. --- 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/libihash/ihash.c +++ b/libihash/ihash.c @@ -302,7 +302,7 @@ hurd_ihash_add (hurd_ihash_t h

[PATCH 3/5] libihash: add hurd_ihash_value_valid

2014-05-15 Thread Justus Winter
* libihash/ihash.h (hurd_ihash_value_valid): New function. * libihash/ihash.c (index_empty): Use hurd_ihash_value_valid. --- libihash/ihash.c | 3 +-- libihash/ihash.h | 7 +++ 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/libihash/ihash.c b/libihash/ihash.c index 4d9cc18..5b7

[PATCH 5/5] include: add lock-less reference counting primitives

2014-05-15 Thread Justus Winter
* include/refcount.h: New file. --- include/refcount.h | 263 + 1 file changed, 263 insertions(+) create mode 100644 include/refcount.h diff --git a/include/refcount.h b/include/refcount.h new file mode 100644 index 000..5c3302d --- /dev/nu

Re: [PATCH 2/3] i386: add io_map_cached

2014-05-15 Thread Samuel Thibault
Justus Winter, le Thu 15 May 2014 12:32:41 +0200, a écrit : > accessing this physical address with phystokv() fails b/c it is > outside the mapped range Ah, right, I guess it's in very high addresses. Samuel

Re: [PATCH 2/3] i386: add io_map_cached

2014-05-15 Thread Justus Winter
Quoting Samuel Thibault (2014-05-15 02:13:13) > Hello, > > Justus Winter, le Fri 02 May 2014 21:33:01 +0200, a écrit : > > io_map_cached is like io_map, but reuses the old mapping if it is > > applicable. > > But AIUI, if it is not applicable, it does not unmap the previous > mapping, so we lose