Re: Time for another round of releases

2016-10-14 Thread Samuel Thibault 
Manolis Ragkousis, on Fri 14 Oct 2016 16:42:42 +0300, wrote:
> ../libpthread/sysdeps/hurd/pt-key.h: In function ‘__pthread_key_lock_ready’:
> ../libpthread/sysdeps/pthread/bits/once.h:32:10: error: initializer
> element is not constant
>   (struct __pthread_once) { 0, __PTHREAD_SPIN_LOCK_INITIALIZER }
>   ^
> ../libpthread/include/pthread/pthread.h:757:27: note: in expansion of
> macro ‘__PTHREAD_ONCE_INIT’
>  #define PTHREAD_ONCE_INIT __PTHREAD_ONCE_INIT
>^
> ../libpthread/sysdeps/hurd/pt-key.h:55:29: note: in expansion of macro
> ‘PTHREAD_ONCE_INIT’
>static pthread_once_t o = PTHREAD_ONCE_INIT;

That's odd, I'm not getting such error. This really is constant...

Does the attached program fail to build too?  It should be equivalent
to the libpthread code at stake.

Samuel
typedef volatile int fooo;

struct foo {
int i;
fooo j;
};

static struct foo bar = (struct foo) { 0, ((fooo) 0)};

int main(void) {
}

Re: Time for another round of releases

2016-10-14 Thread Manolis Ragkousis 
Building the latest tschwinge/Roger_Whittaker fails with:

In file included from ../libpthread/include/pthread/pthreadtypes.h:120:0,
 from ../libpthread/include/pthread/pthread.h:55,
 from ../libpthread/include/pthread.h:2,
 from ../include/pthread.h:1,
 from ./pthread/../sysdeps/generic/pt-attr.c:20:
../libpthread/sysdeps/hurd/pt-key.h: In function ‘__pthread_key_lock_ready’:
../libpthread/sysdeps/pthread/bits/once.h:32:10: error: initializer
element is not constant
  (struct __pthread_once) { 0, __PTHREAD_SPIN_LOCK_INITIALIZER }
  ^
../libpthread/include/pthread/pthread.h:757:27: note: in expansion of
macro ‘__PTHREAD_ONCE_INIT’
 #define PTHREAD_ONCE_INIT __PTHREAD_ONCE_INIT
   ^
../libpthread/sysdeps/hurd/pt-key.h:55:29: note: in expansion of macro
‘PTHREAD_ONCE_INIT’
   static pthread_once_t o = PTHREAD_ONCE_INIT;
 ^

http://paste.lisp.org/display/328517

Manolis

Re: libpager multi-client support

2016-10-14 Thread Kalle Olavi Niemitalo 
"Brent W. Baccala"  writes:

> Second, I can't find anywhere in the hurd source tree where this function
> is actually used.

Commit 84cf9c0f312637b670cc87224ff7e7c4da659e36 on 2013-09-17
removed the ufs directory, in which the offer_data function used
to call pager_offer_page.  The last argument of pager_offer_page
always pointed to a page that was part of the global zeroblock,
which was the size of a filesystem block and filled with zeroes.

> Third, why would we want this feature?  Why would a memory server ever want
> to send an unsolicited page to a client?

One of the offer_data calls was preceded by a comment:

  /* Make sure that any pages of this block which just became allocated
 don't get paged in from disk. */

I don't know how ext2fs makes sure of that, or whether
pager_offer_page might again be needed for the same purpose in
the future.