[PATCH] fix missing include header guard.

[guy fleury iteriteka]

* i386/i386/pit.h: Add header guard angaist multiple inclusion.
---
 i386/i386/pit.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/i386/i386/pit.h b/i386/i386/pit.h
index 6b682280..e004c37c 100644
--- a/i386/i386/pit.h
+++ b/i386/i386/pit.h
@@ -45,6 +45,9 @@ NEGLIGENCE, OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN 
CONNECTION
 WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
 */
 
+#ifndef_I386_PIT_H_
+#define_I386_PIT_H_
+
 #ifdefined(AT386) || defined(ATX86_64)
 /* Definitions for 8254 Programmable Interrupt Timer ports on AT 386 */
 #define PITCTR0_PORT   0x40/* counter 0 port */
@@ -79,3 +82,5 @@ WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
 #endif /* AT386 */
 
 extern void clkstart(void);
+
+#endif /* _I386_PIT_H_ */
-- 
2.20.1

[PATCH] remove mremap from open_issues

[guy fleury iteriteka]

[PATCH 01/11] remove libthreads.

[guy fleury iteriteka]

* hurd/libthreads.mdwn: delete file.
---
 hurd/libthreads.mdwn | 39 ---
 1 file changed, 39 deletions(-)
 delete mode 100644 hurd/libthreads.mdwn

diff --git a/hurd/libthreads.mdwn b/hurd/libthreads.mdwn
deleted file mode 100644
index aa429d8..000
--- a/hurd/libthreads.mdwn
+++ /dev/null
@@ -1,39 +0,0 @@
-[[!meta copyright="Copyright ?? 2011, 2012, 2013 Free Software Foundation,
-Inc."]]
-
-[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
-id="license" text="Permission is granted to copy, distribute and/or modify this
-document under the terms of the GNU Free Documentation License, Version 1.2 or
-any later version published by the Free Software Foundation; with no Invariant
-Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
-is included in the section entitled [[GNU Free Documentation
-License|/fdl]]."]]"""]]
-
-`libthreads` a.k.a. C threads.
-
-**Note**: since Hurd migrated to [[libpthread]] as threading library,
-the development and usage of libthreads has been discontinued.
-
-
-
-# Internals
-
-## Threading Model
-
-libthreads has a 1:1 threading model.
-
-
-## Threads' Death
-
-A thread's death doesn't actually free the thread's stack (and maybe not the
-associated Mach ports either).  That's because there's no way to free the stack
-after the thread dies (because the thread of control is gone); the stack needs
-to be freed by something else, and there's nothing convenient to do it.  There
-are many ways to make it work.
-
-However, it isn't really a leak, because the unfreed resources do get used for
-the next thread.  So the issue is that the shrinkage of resource consumption
-never happens, but it doesn't grow without bounds; it just stays at the maximum
-even if the current number of threads is lower.
-
-The same issue exists in [[libpthread]].
-- 
2.20.1

[PATCH 00/11] remove fixed issues

[guy fleury iteriteka]

Hello,

these patches remove some fixed issues.
*** BLURB HERE ***

guy fleury iteriteka (11):
  remove libthreads.
  remove mention of libthreads.
  rename open_issues/libpthread/t/fix_have_kernel_resources.mdwn ->
open_issues/libpthread/fix_have_kernel_resources.mdwn
  remove cthreader -> libpthread.
  remove sa_siginfo_sa_sigaction from open_issues.
  remove guile 'times' issues.
  replace cvs_tasks_file and cvs_todo_file files with todo.
  remove adduser from open_issues.
  remove crt0_o_crt1_o_debug_info_relocation_invalid_symbol issues.
  remove ifunc from open_issues.
  remove gnumach_i686 issue.

 hurd/libthreads.mdwn  |  39 -
 open_issues/adduser.mdwn  |  37 -
 ..._info_relocation_invalid_symbol_index.mdwn |  41 -
 open_issues/cvs_tasks_file.mdwn   |  18 -
 open_issues/gnumach_i686.mdwn |  26 -
 open_issues/ifunc.mdwn|  49 --
 open_issues/libpthread.mdwn   |  19 +-
 .../{t => }/fix_have_kernel_resources.mdwn|   0
 open_issues/multithreading.mdwn   |   2 -
 open_issues/sa_siginfo_sa_sigaction.mdwn  |  96 ---
 open_issues/time.mdwn | 765 --
 open_issues/{cvs_todo_file.mdwn => todo.mdwn} |   6 +-
 12 files changed, 6 insertions(+), 1092 deletions(-)
 delete mode 100644 hurd/libthreads.mdwn
 delete mode 100644 open_issues/adduser.mdwn
 delete mode 100644 
open_issues/crt0_o_crt1_o_debug_info_relocation_invalid_symbol_index.mdwn
 delete mode 100644 open_issues/cvs_tasks_file.mdwn
 delete mode 100644 open_issues/gnumach_i686.mdwn
 delete mode 100644 open_issues/ifunc.mdwn
 rename open_issues/libpthread/{t => }/fix_have_kernel_resources.mdwn (100%)
 delete mode 100644 open_issues/sa_siginfo_sa_sigaction.mdwn
 rename open_issues/{cvs_todo_file.mdwn => todo.mdwn} (79%)

-- 
2.20.1

[PATCH 02/11] remove mention of libthreads.

[guy fleury iteriteka]

* open_issues/multithreading.mdwn(libthreads): remove it.
---
 open_issues/multithreading.mdwn | 2 --
 1 file changed, 2 deletions(-)

diff --git a/open_issues/multithreading.mdwn b/open_issues/multithreading.mdwn
index a66202c..994625c 100644
--- a/open_issues/multithreading.mdwn
+++ b/open_issues/multithreading.mdwn
@@ -19,8 +19,6 @@ Hurd servers / VFS libraries are multithreaded.  They can 
even be said to be
 
   * well-known threading libraries
 
-  * [[hurd/libthreads]]
-
   * [[hurd/libpthread]]
 
 ## IRC, freenode, #hurd, 2011-04-20
-- 
2.20.1

[PATCH 07/11] replace cvs_tasks_file and cvs_todo_file files with todo.

[guy fleury iteriteka]

* open_issues/cvs_tasks_file.mdwn: delete file.
* open_issues/cvs_todo_file.mdwn: Likewise.
* open_issues/todo.mdwn: New file.
---
 open_issues/cvs_tasks_file.mdwn   | 18 --
 open_issues/{cvs_todo_file.mdwn => todo.mdwn} |  6 +++---
 2 files changed, 3 insertions(+), 21 deletions(-)
 delete mode 100644 open_issues/cvs_tasks_file.mdwn
 rename open_issues/{cvs_todo_file.mdwn => todo.mdwn} (79%)

diff --git a/open_issues/cvs_tasks_file.mdwn b/open_issues/cvs_tasks_file.mdwn
deleted file mode 100644
index 67b6465..000
--- a/open_issues/cvs_tasks_file.mdwn
+++ /dev/null
@@ -1,18 +0,0 @@
-[[!meta copyright="Copyright ?? 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009
-Free Software Foundation, Inc."]]
-
-[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
-id="license" text="Permission is granted to copy, distribute and/or modify this
-document under the terms of the GNU Free Documentation License, Version 1.2 or
-any later version published by the Free Software Foundation; with no Invariant
-Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
-is included in the section entitled
-[[GNU Free Documentation License|/fdl]]."]]"""]]
-
-[[!meta title="CVS tasks file"]]
-
-[[!tag open_issue_hurd]]
-
-The canonical [tasks
-file](http://savannah.gnu.org/cgi-bin/viewcvs/~checkout~/hurd/hurd/tasks?rev=HEAD&content-type=text/plain)
-from the CVS archive.
diff --git a/open_issues/cvs_todo_file.mdwn b/open_issues/todo.mdwn
similarity index 79%
rename from open_issues/cvs_todo_file.mdwn
rename to open_issues/todo.mdwn
index a42e6dc..00eb12d 100644
--- a/open_issues/cvs_todo_file.mdwn
+++ b/open_issues/todo.mdwn
@@ -9,10 +9,10 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts.  A 
copy of the license
 is included in the section entitled
 [[GNU Free Documentation License|/fdl]]."]]"""]]
 
-[[!meta title="CVS TODO file"]]
+[[!meta title="TODO file"]]
 
 [[!tag open_issue_hurd]]
 
 The canonical [TODO
-file](http://savannah.gnu.org/cgi-bin/viewcvs/~checkout~/hurd/hurd/TODO?rev=HEAD&content-type=text/plain)
-from the CVS archive.
+file](http://git.savannah.gnu.org/cgit/hurd/hurd.git/plain/TODO)
+from the git archive.
-- 
2.20.1

[PATCH 03/11] rename open_issues/libpthread/t/fix_have_kernel_resources.mdwn -> open_issues/libpthread/fix_have_kernel_resources.mdwn

[guy fleury iteriteka]

---
 open_issues/libpthread.mdwn   | 4 ++--
 open_issues/libpthread/{t => }/fix_have_kernel_resources.mdwn | 0
 2 files changed, 2 insertions(+), 2 deletions(-)
 rename open_issues/libpthread/{t => }/fix_have_kernel_resources.mdwn (100%)

diff --git a/open_issues/libpthread.mdwn b/open_issues/libpthread.mdwn
index c628bc7..f8d9e1f 100644
--- a/open_issues/libpthread.mdwn
+++ b/open_issues/libpthread.mdwn
@@ -1310,7 +1310,7 @@ Most of the issues raised on this page has been resolved, 
a few remain.
  thhe hurd must be plagued with wrong deallocations :(
  i have so many problems when trying to cleanly destroy threads
 
-[[libpthread/t/fix_have_kernel_resources]].
+[[libpthread/fix_have_kernel_resources]].
 
 
  IRC, freenode, #hurd, 2013-11-25
@@ -1322,7 +1322,7 @@ Most of the issues raised on this page has been resolved, 
a few remain.
 
  IRC, freenode, #hurd, 2013-11-29
 
-See also [[open_issues/libpthread/t/fix_have_kernel_resources]].
+See also [[open_issues/libpthread/fix_have_kernel_resources]].
 
  there still are some leak ports making servers spawn threads with
   non-elevated priorities :/
diff --git a/open_issues/libpthread/t/fix_have_kernel_resources.mdwn 
b/open_issues/libpthread/fix_have_kernel_resources.mdwn
similarity index 100%
rename from open_issues/libpthread/t/fix_have_kernel_resources.mdwn
rename to open_issues/libpthread/fix_have_kernel_resources.mdwn
-- 
2.20.1

[PATCH 10/11] remove ifunc from open_issues.

[guy fleury iteriteka]

* open_issues/ifunc.mdwn: delete it.
---
 open_issues/ifunc.mdwn | 49 --
 1 file changed, 49 deletions(-)
 delete mode 100644 open_issues/ifunc.mdwn

diff --git a/open_issues/ifunc.mdwn b/open_issues/ifunc.mdwn
deleted file mode 100644
index c357c99..000
--- a/open_issues/ifunc.mdwn
+++ /dev/null
@@ -1,49 +0,0 @@
-[[!meta copyright="Copyright ?? 2010, 2011 Free Software Foundation, Inc."]]
-
-[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
-id="license" text="Permission is granted to copy, distribute and/or modify this
-document under the terms of the GNU Free Documentation License, Version 1.2 or
-any later version published by the Free Software Foundation; with no Invariant
-Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
-is included in the section entitled [[GNU Free Documentation
-License|/fdl]]."]]"""]]
-
-[[!tag open_issue_binutils open_issue_gcc open_issue_glibc]]
-
-Needs porting / support in [[/binutils]] and [[/glibc]], and then some target
-configure magic for [[/GCC]].
-
- has a short summary about how to
-use it from GCC.
-
-  * binutils
-
-Already passes the ifunc testsuite bits for GAS, but notably for LD
-(`ld/testsuite/ld-ifunc/ifunc.exp`), too, but that one contains a bunch of
-stuff explicitly tailored towards Linux.  For example, we get *OS/ABI: UNIX
-- Linux*.  (This should be fixed through using [[toolchain/ELFOSABI_GNU]].)
-
-Most of the executables that the testsuite generates don't actually
-execute.  (Though, this is partly due to the [[static
-issue|binutils#static]].)
-
-$ tmpdir/local_prog 
-ifunc working correctly
-$ tmpdir/static_prog 
-Killed
-$ tmpdir/dynamic_prog 
-tmpdir/dynamic_prog: error while loading shared libraries: 
./tmpdir/libshared_ifunc.so: ELF file OS ABI invalid
-$ tmpdir/static_nonifunc_prog 
-Killed
-$ tmpdir/test-1
-tmpdir/test-1: error while loading shared libraries: 
tmpdir/libshared_ifunc.so: ELF file OS ABI invalid
-
-  * [[glibc]]
-
-  * [[libc_variant_selection]]
-
-  * [[GCC]]
-
-In `gcc/config.gcc`, set `default_gnu_indirect_function=yes` for us, like
-done for GNU/Linux.  See thread starting at [[!message-id
-"CAFULd4YZsAQ6ckFjXtU5-yyv=3tyqwtjophu9zmjxfornot...@mail.gmail.com"]].
-- 
2.20.1

[PATCH 08/11] remove adduser from open_issues.

[guy fleury iteriteka]

* open_issues/adduser.mdwn: delete file.
---
 open_issues/adduser.mdwn | 37 -
 1 file changed, 37 deletions(-)
 delete mode 100644 open_issues/adduser.mdwn

diff --git a/open_issues/adduser.mdwn b/open_issues/adduser.mdwn
deleted file mode 100644
index 713a1dd..000
--- a/open_issues/adduser.mdwn
+++ /dev/null
@@ -1,37 +0,0 @@
-[[!meta copyright="Copyright ?? 2008, 2009 Free Software Foundation, Inc."]]
-
-[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
-id="license" text="Permission is granted to copy, distribute and/or modify this
-document under the terms of the GNU Free Documentation License, Version 1.2 or
-any later version published by the Free Software Foundation; with no Invariant
-Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
-is included in the section entitled
-[[GNU Free Documentation License|/fdl]]."]]"""]]
-
-[[!meta title="adduser: posix_spawn() error=1073741826"]]
-
-[[!tag open_issue_porting]]
-
-`adduser` does work as expected, the following warnings are spurious, they just
-appear when one doesn't have the nscd package. They do not appear on Linux 
boxes
-because there posix_spawn doesn't report ENOENT for exec(). POSIX indeed says
-that `if the error occurs after the calling process successfully returns, the
-child process shall exit with exit status 127'. The Hurd however reports all
-errors, thus the warning.
-
-$ sudo adduser foo
-Adding user `foo' ...
-Adding new group `foo' (1002) ...
-posix_spawn() error=1073741826
-posix_spawn() error=1073741826
-posix_spawn() error=1073741826
-Adding new user `foo' (1002) with group `foo' ...
-posix_spawn() error=1073741826
-posix_spawn() error=1073741826
-posix_spawn() error=1073741826
-posix_spawn() error=1073741826
-Creating home directory `/home/foo' ...
-Copying files from `/etc/skel' ...
-[...]
-
-Reported at [[!debbug 623199]].
-- 
2.20.1

[PATCH 05/11] remove sa_siginfo_sa_sigaction from open_issues.

[guy fleury iteriteka]

* open_issues/sa_siginfo_sa_sigaction.mdwn: delete file.
---
 open_issues/sa_siginfo_sa_sigaction.mdwn | 96 
 1 file changed, 96 deletions(-)
 delete mode 100644 open_issues/sa_siginfo_sa_sigaction.mdwn

diff --git a/open_issues/sa_siginfo_sa_sigaction.mdwn 
b/open_issues/sa_siginfo_sa_sigaction.mdwn
deleted file mode 100644
index 4e1fa84..000
--- a/open_issues/sa_siginfo_sa_sigaction.mdwn
+++ /dev/null
@@ -1,96 +0,0 @@
-[[!meta copyright="Copyright ?? 2010, 2011, 2012 Free Software Foundation,
-Inc."]]
-
-[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
-id="license" text="Permission is granted to copy, distribute and/or modify this
-document under the terms of the GNU Free Documentation License, Version 1.2 or
-any later version published by the Free Software Foundation; with no Invariant
-Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
-is included in the section entitled [[GNU Free Documentation
-License|/fdl]]."]]"""]]
-
-[[!meta title="SA_SIGINFO, SA_SIGACTION"]]
-
-[[!tag open_issue_glibc]]
-
-Note: SA_SIGINFO has now been implemented by J??r??mie Koenig.  It will be
-uploaded in Debian eglibc 2.13-19.
-
-IRC, #hurd, August / September 2010:
-
- Hy, I came across SA_SIGINFO in cherokee, I have the void 
sighandler(int num) prototype but how do I add the sa_handler field?
- if SA_SIGACTION is not defined, then you use sa_handler instead 
of sa_sigaction, and not add SA_SIGINFO in the sa_flags
- SA_SIGINFO is not defined
- s/SA_SIGACTION/SA_SIGINFO/ above, yes
- K
- I am not sure if I fully understand this, there is the  line 
"act.sa_flags = SA_SIGINFO" and how do I have to change that >_>
- can you paste the source in a pastebin?
- k
- http://archhurd.pastebin.com/N8BCnG6g at line 790
- something along the lines of 
http://www.archhurd.pastebin.com/tdpcFD5G
- note that in the handler the siginfo_t parameter is used, which 
cannot be done if SA_SIGINFO is not defined
- (that code still won't compile, yet)
- btw: is there a reason why SA_SIGINFO is not implemented?
- the guildlines only say "It's not implemented"
- 09:43 < azeem> signal stuff is tricky :-/
- basically it was pending on a complete rewrite by Roland, which 
never occured
- I have an almost complete implementation, just not finished yet
- (only the siginfo part)
- nobody really groked that code for years until youpi showed up, 
but he added partial support AFAIK, not having much time on his hand
- ah, he's here
- :)
- oh, should I just wait ?
- no
- k
- there are OSes which don't have SA_SIGINFO
- just cope with them: use sa_handler instead of sa_sigaction, and 
don't set SA_SIGINFO
- (i.e. replace with 0 in your example)
- ok
- when SA_SIGINFO becomes available, it'll just be used
-
-IRC, freenode, #hurd, 2011-08-20:
-
-< youpi> erf, tcpwrappers will need si_pid
-< jkoenig> I could implement it not too far away in the future, we just
-  need a version of msg_sig_post() with a siginfo argument or something.
-< youpi> I can also see a lot of packages using SA_SIGINFO for no reason...
-< youpi> (probably copy/pasty code)
-< youpi>   sa.sa_flags = SA_SIGINFO;
-< youpi>   sa.sa_handler = parse_config;
-< youpi> void parse_config(int)
-< youpi> yay
-< youpi> if(siginf->si_signo == SIGXCPU)
-< youpi>   fprintf(stderr, "Exceeded CPU usage.\n");
-< youpi> ...
-< youpi> jkoenig: actually most package don't actually use the SA_SIGINFO
-  they request...
-< youpi> jkoenig: si_pid should get us almost all actually used coverage
-< youpi> I've seen only one example using si_errno
-< jkoenig> ok
-< youpi> oh, it's actually supported by your patch
-< youpi> (errno)
-< jkoenig> but I guess since implementing si_pid will require a new RPC, we
-  might as well plan for the rest
-< youpi> jkoenig: indeed
-< jkoenig> youpi, hmm I doubt it's properly filled in in all circumstances?
-< youpi> ok, well, we'll see
-< pinotree> jkoenig: if it can be of help, boost::unit_test queries various
-  fields of siginfo_t depending on the signal
-< pinotree> jkoenig: also, pulseaudio uses siginfo_t for remapping faulting
-  memory on SIGBUS
-< jkoenig> pinotree, oh ok good to know
-< pinotree> *faulty
-< youpi> jkoenig: well, I guess you had checked that the si_addr field is
-  correct in a few simple testcase :)
-< jkoenig> hmm I think so, yes
-< jkoenig> I ran like, "* (char *) 0x12345678;" or something IIRC
-< youpi> ok
-< jkoenig> I seem to remember mach generated SIGBUS instead of SIGSEGV
-  depending on the upper bit, or something (I can't quite remember)
-< jkoenig> but when sigsegv was generated si_addr was right.
-< pinotree> jkoenig: (see boost/test/impl/execution_monitor.ipp in boost
-  sources)
- 

[PATCH 06/11] remove guile 'times' issues.

[guy fleury iteriteka]

* open_issues/time.mdwn(guile): remove it.
---
 open_issues/time.mdwn | 765 --
 1 file changed, 765 deletions(-)

diff --git a/open_issues/time.mdwn b/open_issues/time.mdwn
index 99c2cbe..2d4f928 100644
--- a/open_issues/time.mdwn
+++ b/open_issues/time.mdwn
@@ -86,768 +86,3 @@ This causes a different code path in `resuse.c` to be used; 
such code path does
 not get a define for `HZ`, which is then defined with a fallback value of 60.
 
 [[!debbug 704283]] has been filed with a fix for this no-wait3 case.
-
-
-# `times`
-
-## guile
-
-### IRC, freenode, #hurd, 2013-08-21
-
- does guile2 on hurd fixed? times issue
- nalaginrut: does not look good
- scheme@(guile-user)> (times)
- $1 = #(0 0 0 0 0)
- well, seems not a fixed version, if there's fixed version
- since it's not Guile's bug, I can do nothing for it
- ah
- in spite of this, Guile2 works I think
- all tests passed but 2 fail
- one of the failure is version shows "UNKNOWN" which is
-  trivials
- well, did you try to fix the times issue in Hurd?
- I didn't , I have to get more familiar with hurd first
- I'm playing hurd these days
- :)
- anyway, I think times issue is beyond my ability at present
- ;-P
- times is implemented in the glibc, in sysdeps/mach/hurd/times.c
- don't say that before you had a look
- yes, you're right
- but I think times has something to do with the kernel time
-  mechanism, dunno if it's related to the issue
- how did you get the times.c under hurd?
- apt-get source glibc?
- well, I'd clone git://sourceware.org/git/glibc.git
- and yes, the kernel is involved
- task_info is used to obtain the actual values
-
-  http://www.gnu.org/software/hurd/gnumach-doc/Task-Information.html
- I'd guess that something fails, but the times(2) interface is
-  not able to communicate the exact failure
- maybe it's not proper to get src from upstream git? since it's
-  OK under Linux which uses it too
- but apt-get source glibc has nothing
- so I would copy the times(2) implementation from the libc so
-  that you can modify it and run it as a standalone program
- well, the libc has system dependent stuff, times(2) on Linux is
-  different from the Hurd version
- it has to be
- alright, I got what you mean ;-)
- and the debian libc is built from the eglibc sources, so the
-  source package is called eglibc iirc
- ah~I'll try
- have you tried to rpctrace your times test program? the small c
-  snippet you posted the other day?
- I haven't build all the tools & debug environment on my hurd
-  ;-(
- what tools?
- well, I don't even have git on it, and I'm installing but
-  speed is slow, I'm looking for a new mirror
- ah well, no need to do all this on the Hurd directly
- building the libc takes like ages anyway
- oops ;-)
- I'll take your advice to concentrate on times.c only
- oh well, it might be difficult after all, not sure though
- times sends two task_info messages, once with TASK_BASIC_INFO,
-  once with TASK_THREAD_TIMES_INFO
- here is the relevant rpctrace of your test program:
- task131(pid14726)->task_info (1 10) = 0 {0 25 153427968 643072 0
-  0 0 0 1377065590 57}
- task131(pid14726)->task_info (3 4) = 0 {0 0 0 1}
- ok, I don't know enough about that to be honest, but
-  TASK_THREAD_TIMES_INFO behaves funny
- I put a sleep(1) into your test program, and if I rpctrace it,
-  it behaves differently o_O
-* nalaginrut is reading task-information page to get what it could be
- maybe I have to do the same steps under Linux to find some
-  clue
- no, this is Mach specific, there is no such thing on Linux
- on Linux, times(2) is a system call
- on Hurd, times is a function implemented in the libc that
-  behaves roughly the same way
- OK~so different
- look at struct task_basic_info and struct task_thread_times_info
-  in the task-information page for the meaning of the values in the
-  rpctrace
- yes, very
- nalaginrut: you may want to try a patch i did but which is still
-  waiting to be merged in glibc
- braunr:  ah~thanks for did it ;-)
- can I have the link?
- i'm getting it
- teythoon: funny things happen with rpctrace, that's expected
- keep in mind rpctrace doesn't behave like ptrace at all
- it acts as a proxy
- nalaginrut:
-  
http://git.savannah.gnu.org/cgit/hurd/glibc.git/commit/?h=rbraun/getclktck_100_hz&id=90404d6d1aa01f6ce1557841f5a675bb6a30f508
- nalaginrut: you need to add it to the debian eglibc patch list,
-  rebuild the packages, and install the resulting .debs
- if you have trouble doing it, i'll make packages when i have time
- braunr:  I think your test result is expected? ;-)
- what test result ?
- times test 

[PATCH 04/11] remove cthreader -> libpthread.

[guy fleury iteriteka]

* open_issues/libpthread.mdwn(cthreader->libpthread): remove it.
---
 open_issues/libpthread.mdwn | 15 +--
 1 file changed, 1 insertion(+), 14 deletions(-)

diff --git a/open_issues/libpthread.mdwn b/open_issues/libpthread.mdwn
index f8d9e1f..1a06897 100644
--- a/open_issues/libpthread.mdwn
+++ b/open_issues/libpthread.mdwn
@@ -13,20 +13,7 @@ License|/fdl]]."]]"""]]
 
 [[!toc]]
 
-
-# cthreads -> pthreads
-
-Get rid of cthreads; switch to pthreads.
-Most of the issues raised on this page has been resolved, a few remain.
-
-
-## IRC, freenode, #hurd, 2012-04-26
-
- youpi: just to be sure: even if libpthread is compiled inside
-  glibc (with proper symbols forwarding etc), it doesn't change that you
-  cannot use both cthreads and pthreads in the same app, right?
-
-[[Packaging_libpthread]].
+# Packaging_libpthread.
 
  it's the same libpthread
  symbol forwarding does not magically resolve that libpthread lacks
-- 
2.20.1

[PATCH 09/11] remove crt0_o_crt1_o_debug_info_relocation_invalid_symbol issues.

[guy fleury iteriteka]

* open_issues/crt0_o_crt1_o_debug_info_relocation_invalid_symbol_index.mdwn:
  delete it.
---
 ..._info_relocation_invalid_symbol_index.mdwn | 41 ---
 1 file changed, 41 deletions(-)
 delete mode 100644 
open_issues/crt0_o_crt1_o_debug_info_relocation_invalid_symbol_index.mdwn

diff --git 
a/open_issues/crt0_o_crt1_o_debug_info_relocation_invalid_symbol_index.mdwn 
b/open_issues/crt0_o_crt1_o_debug_info_relocation_invalid_symbol_index.mdwn
deleted file mode 100644
index b94c0c1..000
--- a/open_issues/crt0_o_crt1_o_debug_info_relocation_invalid_symbol_index.mdwn
+++ /dev/null
@@ -1,41 +0,0 @@
-[[!meta copyright="Copyright ?? 2010 Free Software Foundation, Inc."]]
-
-[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
-id="license" text="Permission is granted to copy, distribute and/or modify this
-document under the terms of the GNU Free Documentation License, Version 1.2 or
-any later version published by the Free Software Foundation; with no Invariant
-Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
-is included in the section entitled [[GNU Free Documentation
-License|/fdl]]."]]"""]]
-
-[[!tag open_issue_glibc open_issue_gcc]]
-
-$ gcc -o /dev/null -x c /dev/null 
-/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 0 has 
invalid symbol index 12
-/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 1 has 
invalid symbol index 13
-/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 2 has 
invalid symbol index 2
-/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 3 has 
invalid symbol index 2
-/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 4 has 
invalid symbol index 12
-/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 5 has 
invalid symbol index 14
-/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 6 has 
invalid symbol index 14
-/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 7 has 
invalid symbol index 14
-/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 8 has 
invalid symbol index 2
-/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 9 has 
invalid symbol index 2
-/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 10 has 
invalid symbol index 13
-/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 11 has 
invalid symbol index 14
-/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 12 has 
invalid symbol index 14
-/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 13 has 
invalid symbol index 14
-/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 14 has 
invalid symbol index 14
-/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 15 has 
invalid symbol index 14
-/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 16 has 
invalid symbol index 14
-/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 17 has 
invalid symbol index 14
-/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 18 has 
invalid symbol index 14
-/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 19 has 
invalid symbol index 14
-/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 20 has 
invalid symbol index 14
-/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 21 has 
invalid symbol index 14
-/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 22 has 
invalid symbol index 22
-/usr/lib/gcc/i486-gnu/4.4.5/../../../crt1.o: In function `_start':
-(.text+0x18): undefined reference to `main'
-collect2: ld returned 1 exit status
-
-Likewise for `-static`, `crt0.o`.
-- 
2.20.1

[PATCH 11/11] remove gnumach_i686 issue.

[guy fleury iteriteka]

* open_issues/gnumach_i686.mdwn: delete it.
---
 open_issues/gnumach_i686.mdwn | 26 --
 1 file changed, 26 deletions(-)
 delete mode 100644 open_issues/gnumach_i686.mdwn

diff --git a/open_issues/gnumach_i686.mdwn b/open_issues/gnumach_i686.mdwn
deleted file mode 100644
index b34df73..000
--- a/open_issues/gnumach_i686.mdwn
+++ /dev/null
@@ -1,26 +0,0 @@
-[[!meta copyright="Copyright ?? 2012 Free Software Foundation, Inc."]]
-
-[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
-id="license" text="Permission is granted to copy, distribute and/or modify this
-document under the terms of the GNU Free Documentation License, Version 1.2 or
-any later version published by the Free Software Foundation; with no Invariant
-Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
-is included in the section entitled [[GNU Free Documentation
-License|/fdl]]."]]"""]]
-
-[[!tag open_issue_gnumach]]
-
-
-# IRC, freenode, #hurd, 2012-07-05
-
- we could use a gnumach-i686 too
- how would you compile gnumach as i686 variant btw? add
-  -march=.. or something like that in CFLAGS?
- yes
- at least we'll get some cmovs :)
-
-
-## IRC, freenode, #hurd, 2012-07-07
-
- it was rejected in the past because we didn't think it would bring
-  real performance benefit, but it actually may
-- 
2.20.1

Re: [PATCH 00/11] remove fixed issues

[guy fleury iteriteka]

Samuel Thibault  writes:

> guy fleury iteriteka, le sam. 02 janv. 2021 12:12:06 +0200, a ecrit:
>> these patches remove some fixed issues.
>> *** BLURB HERE ***
>
> Mostly applied, thanks!
>
Thanks!
> One thing, however: somehow you produced mails with 
>
> Content-Type: text/plain; charset=yes
>
> and "yes" is not a valid charset :)
>
Ooh! `git send-email` asks if i want to declare enconding
as "UTF-8", i just say "yes" and think it will set it.

I will continue to improve myself.
> Samuel

[PATCH 3/3] remove open_symlink issue.

[guy fleury iteriteka]

* open_issues/open_symlink.mdwn: delete file.
---
 open_issues/open_symlink.mdwn | 30 --
 1 file changed, 30 deletions(-)
 delete mode 100644 open_issues/open_symlink.mdwn

diff --git a/open_issues/open_symlink.mdwn b/open_issues/open_symlink.mdwn
deleted file mode 100644
index 663bfcb..000
--- a/open_issues/open_symlink.mdwn
+++ /dev/null
@@ -1,30 +0,0 @@
-[[!meta copyright="Copyright © 2012, 2013 Free Software Foundation, Inc."]]
-
-[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
-id="license" text="Permission is granted to copy, distribute and/or modify this
-document under the terms of the GNU Free Documentation License, Version 1.2 or
-any later version published by the Free Software Foundation; with no Invariant
-Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
-is included in the section entitled [[GNU Free Documentation
-License|/fdl]]."]]"""]]
-
-[[!tag open_issue_glibc]]
-
-
-# IRC, freenode, #hurd, 2012-01-02
-
- hm, is it a known issue that open("somesymlink", O_RDONLY |
-  O_NOFOLLOW) does not fail with ELOOP?
- pinotree: iirc there is code for it, maybe not the same behavior as
-  on linux
-
-
-## IRC, OFTC, #debian-hurd, 2013-05-08
-
- the hurd issue is that O_NOFOLLOW seems broken on symlinks, and
-  thus open(symlink, O_NOFOLLOW) doesn't fail with ELOOP
- I don't really see why it should fail
- since NOFOLLOW says not to follow the symlink
- yeah, but you cannot open a symlink
- ah right ok
- interesting :)
-- 
2.20.1

[PATCH 1/3] remove faccessat issue.

[guy fleury iteriteka]

* open_issues/faccessat.mdwn: delete file.
  open_issues/faccessat/faccessat.c: Likewise
---
 open_issues/faccessat.mdwn| 21 -
 open_issues/faccessat/faccessat.c | 26 --
 2 files changed, 47 deletions(-)
 delete mode 100644 open_issues/faccessat.mdwn
 delete mode 100644 open_issues/faccessat/faccessat.c

diff --git a/open_issues/faccessat.mdwn b/open_issues/faccessat.mdwn
deleted file mode 100644
index 911acbb..000
--- a/open_issues/faccessat.mdwn
+++ /dev/null
@@ -1,21 +0,0 @@
-[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
-
-[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
-id="license" text="Permission is granted to copy, distribute and/or modify this
-document under the terms of the GNU Free Documentation License, Version 1.2 or
-any later version published by the Free Software Foundation; with no Invariant
-Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
-is included in the section entitled [[GNU Free Documentation
-License|/fdl]]."]]"""]]
-
-[[!tag open_issue_glibc open_issue_hurd]]
-
-`faccessat()` fails on some cases; in particular when:
-
-* flags does not have `AT_EACCESS`
-* dirfd is not `AT_FDCWD`
-* pathname is not an absolute path
-
-In such case, it will return -1 setting `ENOTSUP` as errno.
-
-[[faccessat.c]]
diff --git a/open_issues/faccessat/faccessat.c 
b/open_issues/faccessat/faccessat.c
deleted file mode 100644
index 24b1233..000
--- a/open_issues/faccessat/faccessat.c
+++ /dev/null
@@ -1,26 +0,0 @@
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#define TESTFN "faccessat-test-file"
-
-int main()
-{
-  int fd;
-  int ret;
-
-  system("touch " TESTFN );
-  fd = open(".", O_RDONLY);
-  printf("> open: %d\n", fd);
-
-  errno = 0;
-  ret = faccessat(fd, TESTFN, R_OK, 0);
-  printf("> faccessat: %d, %d (%s)\n", ret, errno, strerror(errno));
-
-  close(fd);
-
-  return 0;
-}
-- 
2.20.1

[PATCH 2/3] remove glibc_madvise_vs_static_linking issue.

[guy fleury iteriteka]

* open_issues/glibc_madvise_vs_static_linking.mdwn: delete file.
---
 .../glibc_madvise_vs_static_linking.mdwn  | 48 ---
 1 file changed, 48 deletions(-)
 delete mode 100644 open_issues/glibc_madvise_vs_static_linking.mdwn

diff --git a/open_issues/glibc_madvise_vs_static_linking.mdwn 
b/open_issues/glibc_madvise_vs_static_linking.mdwn
deleted file mode 100644
index 4af4193..000
--- a/open_issues/glibc_madvise_vs_static_linking.mdwn
+++ /dev/null
@@ -1,48 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2011, 2012, 2013 Free Software Foundation,
-Inc."]]
-
-[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
-id="license" text="Permission is granted to copy, distribute and/or modify this
-document under the terms of the GNU Free Documentation License, Version 1.2 or
-any later version published by the Free Software Foundation; with no Invariant
-Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
-is included in the section entitled [[GNU Free Documentation
-License|/fdl]]."]]"""]]
-
-[[!tag open_issue_glibc]]
-
-[[!sourceware_PR 4822]].
-
-$ echo 'int main() {}' | gcc -o /dev/null -static -x c -
-/usr/lib/gcc/i486-gnu/4.4.5/../../../libcrt.a(malloc.o): In function 
`_int_free':
-(.text+0xdc3): warning: warning: madvise is not implemented and will 
always fail
-
-This is correct, but it does confuse GNU Autoconf, for example, which then
-thinks that static linking is not supported and sets a flag accordingly, which
-luckly no / not many packages use.
-
-*This call does not influence the semantics of the application (except in the
-case of MADV_DONTNEED), but may influence its performance.  The kernel is free
-to ignore the advice.* (`man madvise`), so we may simply want to turn it into a
-no-op in glibc, avoiding the link-time warning.
-
-GCC c5db973fdab3db3e13db575e5650c0bcfd3630f4 (2011-10-17) makes use of this.
-As we now export the symbol (and `MADV_DONTNEED`, too), GCC will no longer
-`munmap` pages, but will keep them mapped for later re-use.  This may increase
-memory usage.  The discussion in [[!message-id
-"20120720162519.734e02eb@spoyarek"]] touches related topics.
-
-2011-07: This is what Samuel has [done for Debian
-glibc](http://anonscm.debian.org/viewvc/pkg-glibc/glibc-package/trunk/debian/patches/hurd-i386/local-madvise_warn.diff).
-
-
-# IRC, freenode, #hurd, 2012-02-16
-
- youpi: With Roland's fix the situation will be that just using
-  gcc -static doesn't emit the stub warning, but still will do so in case
-  that the source code itself links in madvise.  Is this acceptable for
-  you/Debian/...?
- packages with -Werror will still bug out
- not that I consider -Werror to be a good idea, though :)
- youpi: Indeed.  Compiler warnings can be caused by all kinds of
-  things.  -Werror is good for development, but not for releases.
-- 
2.20.1

[PATCH] add a missing include header guard.

[guy fleury iteriteka]

* i386/i386at/comreg.h: Add header guard angaist multiple inclusion.
---
 i386/i386at/comreg.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/i386/i386at/comreg.h b/i386/i386at/comreg.h
index 12174a1..7356574 100644
--- a/i386/i386at/comreg.h
+++ b/i386/i386at/comreg.h
@@ -52,6 +52,9 @@ NEGLIGENCE, OR OTHER TORTIOUS ACTION, ARISING OUR OF OR IN 
CONNECTION
 WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
 */
 
+#ifndef_COMREG_H_
+#define_COMREG_H_
+
 #define TXRX(addr) (addr + 0)
 #define BAUD_LSB(addr) (addr + 0)
 #define BAUD_MSB(addr) (addr + 1)
@@ -132,3 +135,5 @@ WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
 #defineiFIFO4CH0x40/* Receive fifo trigger level 4 
chars*/
 #defineiFIFO8CH0x80/* Receive fifo trigger level 8 
chars*/
 #defineiFIFO14CH   0xc0/* Receive fifo trigger level 
14 chars*/
+
+#endif /* _COMREG_H_ */
-- 
2.20.1

[PATCH] doc: Add a missing field for 'struct thread_sched_info'.

[Guy-Fleury Iteriteka]

* doc/mach.texi(struct thread_sched_info): Add 'int last_processor' item.
---
 doc/mach.texi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/doc/mach.texi b/doc/mach.texi
index ff15a95..cfa5189 100644
--- a/doc/mach.texi
+++ b/doc/mach.texi
@@ -4399,6 +4399,9 @@ The current scheduling priority of the thread.
 
 @item int depress_priority
 The priority the thread was depressed from.
+
+@item int last_processor
+The last processor used by the thread.
 @end table
 @end deftp
 
-- 
2.20.1

[PATCH 1/2] pfinet: fix missed include files.

[Guy-Fleury Iteriteka]

* pfinet/glue-include/linux/socket.h: include '' for 'memcpy'
  and '' for 'abort'.
---
 pfinet/glue-include/linux/socket.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/pfinet/glue-include/linux/socket.h 
b/pfinet/glue-include/linux/socket.h
index a7475ea..87ddedc 100644
--- a/pfinet/glue-include/linux/socket.h
+++ b/pfinet/glue-include/linux/socket.h
@@ -8,7 +8,8 @@
 #include 
 #include 
 #include 
-
+#include 
+#include 
 
 /* #define IP_MAX_MEMBERSHIPS 10 */
 
-- 
2.20.1

[PATCH 2/2] pfinet: fix a missed 'return' keyword.

[Guy-Fleury Iteriteka]

* pfinet/ethernet.c(ethernet_close): Add 'return 0;' at the
  end of function.
---
 pfinet/ethernet.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/pfinet/ethernet.c b/pfinet/ethernet.c
index 1b3b5d0..5c69b54 100644
--- a/pfinet/ethernet.c
+++ b/pfinet/ethernet.c
@@ -263,6 +263,8 @@ ethernet_close (struct device *dev)
   device_close (edev->ether_port);
   mach_port_deallocate (mach_task_self (), edev->ether_port);
   edev->ether_port = MACH_PORT_NULL;
+
+  return 0;
 }
 
 /* Transmit an ethernet frame */
-- 
2.20.1

Re: [VULN 0/4] Hurd vulnerability details

[Guy-Fleury Iteriteka]

Thank you very much!
I now understand things that I desperately want to know about hurd internal.

On November 2, 2021 6:31:17 PM GMT+02:00, Sergey Bugaev  
wrote:
>Hello!
>
>As promised [0], here are the details of the Hurd vulnerabilities I have found
>earlier this year [1] [2].
>
>[0]: https://lists.gnu.org/archive/html/bug-hurd/2021-10/msg6.html
>[1]: https://lists.gnu.org/archive/html/bug-hurd/2021-05/msg00079.html
>[2]: https://lists.gnu.org/archive/html/bug-hurd/2021-08/msg8.html
>
>(You'll notice that I'm formatting this just like a patch series. I'll even try
>to send it out with git send-email; if you're reading this, it has worked!)
>
>These texts are partly based on the mails and write-ups I sent to Samuel at the
>time, but most of the text is new, rewritten to incorporate the better
>understanding that I now have as the result of exploring the issues and working
>with Samuel on fixing them.
>
>I've grouped the information by the four "major" vulnerabilities -- ones that I
>have actually written an exploit for. Other related vulnerabilities are briefly
>mentioned in the notes sections.
>
>Each text contains a short and a detailed description of the relevant issue,
>source code of the exploit I have written for the issue, commentary on how the
>exploit works, and a description of how we fixed the issue. While this should
>hopefully be an interesting read for everyone, understanding some of the 
>details
>requires some familiarity with the Mach and Hurd mechanisms involved. I've 
>tried
>to briefly describe the necessary bits (as I understand them myself) in the
>"Background" sections throughout the texts -- hopefully this will make it 
>easier
>to understand. Please don't hesitate to ask me questions (while I can still
>answer them)!
>
>I also hope that all this info should be enough to finally allocate official
>CVEs for these vulnerabilities, if anyone is willing to go forward with that in
>my absence.
>
>While all of the vulnerabilities described have been fixed, most of the fixes
>are not yet in the main Hurd tree for legal reasons: namely, my FSF copyright
>assignment process is still unfinished. All the out-of-tree patches with the
>fixes can be found in the Debian repo [3].
>
>[3]: https://salsa.debian.org/hurd-team/hurd/-/tree/master/debian/patches
>
>Our work on fixing these vulnerabilities required some large changes and 
>touches
>most of the major Hurd components (now I can actually name them: glibc, GNU
>Mach, libports, libpager, libfshelp, libshouldbeinlibc, lib*fs, proc server,
>exec server, *fs, ...) -- and this was even more true of the previous designs
>that we have considered (the final design ended up being the most compact one).
>Still, it's kind of amazing _how little_ has changed: we managed to keep most
>things working just as they were (with the notable exception of mremap ()). The
>Hurd still looks and behaves like the Hurd, despite all the changes.
>
>Finally, I should note that there still are unfixed vulnerabilities in the 
>Hurd.
>There's another "major" vulnerability that I have already written an exploit
>for, but I can't publish the details since it's still unfixed. I won't be there
>to see it fixed (assuming it will take less than a year to fix it -- which I
>hope it will), but Samuel should have all the details.
>
>Let me know what you think!
>
>Sergey
>

Re: patch lost at samba

[Guy-Fleury Iteriteka]

Hello,

Sorry in advance for my bad English,

I faced that problem with the latest image. What I did was to resize the image 
with +5GB see
https://cdimage.debian.org/cdimage/ports/latest/hurd-i386/README.txt

The issue seems that the latest image missed space for swap out or for another 
reason. I don't know if diagnosis is correct or I was lucky.

Try to increase the image size to see it solves your issue.

Le 30 mars 2022 17:29:05 GMT+02:00, jbra...@dismail.de a écrit :
>March 30, 2022 2:54 AM, "Samuel Thibault"  wrote:
>
>> jbra...@dismail.de, le mer. 30 mars 2022 01:51:07 +, a ecrit:
>> 
>>> I run into various issues all the time. Networking doesn't work, weird 
>>> issues that I assume
>>> are hardware corruption, etc.
>> 
>> How do you run the Hurd?
>> 
>> I'm not getting issues when running in qemu.
>> 
>>> Maybe I am just not technical enough to help out.
>> 
>> Technicity is something one can *acquire*, it's not a divine gift.
>> 
>> Samuel
>
>Thanks for reaching out Samuel!  I actually just tried the latest qemu image,
>and the ext2fs translator died on 1st boot.  Then it tries to reboot.  The 
>following is just my long summation of what I did:
>
>** Trying out the vm image [2022-03-30 Wed]
>
>
>Add yourself to the kvm group.  This group lets you start a kernel-ized 
>virtual machine.
>You can check to which groups you belong with:
>#+BEGIN_SRC sh :results output :exports both
>groups joshua
>#+END_SRC
>
>#+RESULTS:
>:  http video audio
>
>#+BEGIN_SRC sh :results output :exports both
>$ wget http://people.debian.org/~sthibault/hurd-i386/debian-hurd.img.tar.gz
>$ tar -xz < debian-hurd.img.tar.gz
>#+END_SRC
>
>Then I went to read the readme:
>https://cdimage.debian.org/cdimage/ports/latest/hurd-i386/README
>
>#+BEGIN_EXAMPLE
>Make sure that you can access /dev/kvm to get full KVM speed (otherwise KVM 
>will
>be terribly slow). You can easily check with
>
>  $ file -s /dev/kvm
>
>that you properly get "ERROR: cannot read `/dev/kvm' (Invalid argument)",
>which means that "file" was properly able to open kvm, just not smart enough
>to use it :)
>#+END_EXAMPLE
>
>That's what happened to me.  Let's run this monster!
>
>#+BEGIN_SRC shell
>$ qemu-system-i386 -m 4G -display curses -drive 
>cache=writeback,file=./debian-hurd-20220226.img
>#+END_SRC
>
>So you're not gonna believe this, but it booted, then immediately rebooted.  No
>idea why it needed to reboot.  But this is the error message that I recieve
>after fsck fails:
>
>#+BEGIN_EXAMPLE
>/dev/hd0s2: Entry 'dmesg' in /var/log (8107) has deleted/unused inode 8808.  
>CLEARED.
>/dev/hd0s2: Entry 'dmesg.1.gz' in /var/log (8107) has deleted/unused inode 
>8807.
>  CLEARED.
>/dev/hd0s2: Entry 'resolv.conf' in /etc (16193) has deleted/unused inode 17182.
> CLEARED.
>/dev/hd0s2: Entry '.clean' in /tmp (72881) has deleted/unused inode 73676.  
>CLEA
>RED.
>/dev/hd0s2: Missing '.' in directory inode 98103.
>
>
>/dev/hd0s2: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
>(i.e., without -a or -p options)
>fsck exited with status code 4
>failed (code 4).
>An automatic file system check (fsck) of the root filesystem failed. A manual 
>fs
>ck must be performed, then the system restarted. The fsck should be performed 
>in
> maintenance mode with the root filesystem mounted in read-only mode. ... 
> failed
>!
>The root filesystem is currently mounted in read-only mode. A maintenance shell
>will now be started. After performing system maintenance, press CONTROL-D to 
>ter
>minate the maintenance shell and restart the system. ... (warning).
>Press Enter for maintenance
>
>#+END_EXAMPLE
>
>That's probably my fault! I was using termite, which is an upsupported terminal
>(it's developers tell you to use something else) and I was running the fish
>shell to start the hurd. Perhaps that just did something funky. And I don't 
>feel
>like re-learn how to run fsck on the root filesystem. Also if I have to run 
>fsck
>on the root filesystem at first boot, then it is probably best just to start
>over.  This time I as using xfce4-terminal and bash only.
>
>#+BEGIN_SRC scheme
>$ rm debian-hurd-20220226.img
>$ tar -xz < debian-hurd.img.tar.gz
>$ qemu-system-i386 -m 4G -display curses -drive 
>cache=writeback,file=./debian-hurd-20220226.img
>#+END_SRC
>
>While it's booting let's go read up on some of the documentation:
>
>Hey I found the actual hurd wiki that is more up to date!
>https://darnassus.sceen.net/~hurd-web/hurd/running/qemu/
>
>Ahh!  That page has some more tips on how to hurd the Hurd in qemu:
>Namely '-no-reboot'
>
>Also when I started this time, I am pretty sure that it booted twice again.  It
>did NOT leave me in a "you need to run fsck", but it did have a warning about
>the root filesystem not having enough room mounting /tmp.  Also It did get to a
>login screen after what I think was a reboot.  Again not entirely certain
>because I was half watching the boot up and looking at documentation.
>
>BUT when it did get to the login screen
>
>#+BEGIN_EXAMPLE

[PATCH] mig: remove local definition of 'vprintf'

[Guy-Fleury Iteriteka]

autoconf consider that 'AC_FUNC_VPRINTF' is obsolescent.
see 'info autoconf AC_FUNC_VPRINTF'

* Makefile.am: remove 'vprint.c' on src files.
  configure.ac: remove 'AC_FUNC_VPRINTF' macro.
  vprint.c: delete file.
---
 Makefile.am  |   2 +-
 configure.ac |   4 -
 vprint.c | 433 ---
 3 files changed, 1 insertion(+), 438 deletions(-)
 delete mode 100644 vprint.c

diff --git a/Makefile.am b/Makefile.am
index 5d924da..918efa1 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -19,7 +19,7 @@ migcom_SOURCES = boolean.h error.c error.h global.c global.h  
\
 header.c lexxer.h lexxer.l message.h mig_string.h  \
 migcom.c parser.h parser.y routine.c routine.h \
 server.c statement.c statement.h string.c  \
-type.c type.h user.c utils.c utils.h vprint.c write.h
+type.c type.h user.c utils.c utils.h write.h
 migcom_LDADD = @LEXLIB@
 
 SUFFIXES = .h .symo .symc .sym
diff --git a/configure.ac b/configure.ac
index d992264..e4645bd 100644
--- a/configure.ac
+++ b/configure.ac
@@ -38,10 +38,6 @@ AC_PROG_INSTALL
 dnl Checks for header files.
 AC_HEADER_STDC
 
-dnl Checks for library functions.
-AC_FUNC_VPRINTF
-
-
 [if [ "$target" = "$host" ]; then
   TARGET_CC='${CC}'
 else]
diff --git a/vprint.c b/vprint.c
deleted file mode 100644
index db5d2cb..000
--- a/vprint.c
+++ /dev/null
@@ -1,433 +0,0 @@
-/*
- * Copyright (c) 1990,1992,1993 Carnegie Mellon University
- * All Rights Reserved.
- *
- * Permission to use, copy, modify and distribute this software and its
- * documentation is hereby granted, provided that both the copyright
- * notice and this permission notice appear in all copies of the
- * software, derivative works or modified versions, and any portions
- * thereof, and that both notices appear in supporting documentation.
- *
- * CARNEGIE MELLON ALLOWS FREE USE OF THIS SOFTWARE IN ITS "AS IS"
- * CONDITION.  CARNEGIE MELLON DISCLAIMS ANY LIABILITY OF ANY KIND FOR
- * ANY DAMAGES WHATSOEVER RESULTING FROM THE USE OF THIS SOFTWARE.
- *
- * Carnegie Mellon requests users of this software to return to
- *
- *  Software Distribution Coordinator  or  software_distribut...@cs.cmu.edu
- *  School of Computer Science
- *  Carnegie Mellon University
- *  Pittsburgh PA 15213-3890
- *
- * any improvements or extensions that they make and grant Carnegie Mellon
- * the rights to redistribute these changes.
- */
-
-#ifndef HAVE_VPRINTF
-
-/*
- * ansi varargs versions of printf routines
- * This are directly included to deal with nonansi libc's.
- */
-#include 
-#include 
-#include 
-#include 
-
-/*
- * Forward declaration.
- */
-static void _doprnt_ansi(const char *_fmt, va_list _args, FILE *_stream);
-
-int
-vprintf(const char *fmt, va_list args)
-{
-   _doprnt_ansi(fmt, args, stdout);
-   return (ferror(stdout) ? EOF : 0);
-}
-
-int
-vfprintf(FILE *f, const char *fmt, va_list args)
-{
-   _doprnt_ansi(fmt, args, f);
-   return (ferror(f) ? EOF : 0);
-}
-
-int
-vsprintf(char *s, const char *fmt, va_list args)
-{
-   FILE fakebuf;
-
-   fakebuf._flag = _IOSTRG;/* no _IOWRT: avoid stdio bug */
-   fakebuf._ptr = s;
-   fakebuf._cnt = 32767;
-   _doprnt_ansi(fmt, args, &fakebuf);
-   putc('\0', &fakebuf);
-   return (strlen(s));
-}
-
-int
-vsnprintf(char *s, int n, const char *fmt, va_list args)
-{
-   FILE fakebuf;
-
-   fakebuf._flag = _IOSTRG;/* no _IOWRT: avoid stdio bug */
-   fakebuf._ptr = s;
-   fakebuf._cnt = n-1;
-   _doprnt_ansi(fmt, args, &fakebuf);
-   fakebuf._cnt++;
-   putc('\0', &fakebuf);
-   if (fakebuf._cnt<0)
-   fakebuf._cnt = 0;
-   return (n-fakebuf._cnt-1);
-}
-
-/*
- *  Common code for printf et al.
- *
- *  The calling routine typically takes a variable number of arguments,
- *  and passes the address of the first one.  This implementation
- *  assumes a straightforward, stack implementation, aligned to the
- *  machine's wordsize.  Increasing addresses are assumed to point to
- *  successive arguments (left-to-right), as is the case for a machine
- *  with a downward-growing stack with arguments pushed right-to-left.
- *
- *  To write, for example, fprintf() using this routine, the code
- *
- * fprintf(fd, format, args)
- * FILE *fd;
- * char *format;
- * {
- * _doprnt_ansi(format, &args, fd);
- * }
- *
- *  would suffice.  (This example does not handle the fprintf's "return
- *  value" correctly, but who looks at the return value of fprintf
- *  anyway?)
- *
- *  This version implements the following printf features:
- *
- * %d  decimal conversion
- * %u  unsigned conversion
- * %x  hexadecimal conversion
- * %X  hexadecimal conversion with capital letters
- * %o  octal conversion
- * %c  character
- * %s  string
- * %m.nfield width, precision
- * %

[PATCH] convert k&R to ansi.

[Guy-Fleury Iteriteka]

---
 util/atoi.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/util/atoi.c b/util/atoi.c
index e56f50d..507be6b 100644
--- a/util/atoi.c
+++ b/util/atoi.c
@@ -90,9 +90,7 @@ WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  *
  */
 int
-mach_atoi(cp, nump)
-const u_char   *cp;
-int*nump;
+mach_atoi(const u_char *cp,int *nump)
 {
int number;
const u_char*original;
-- 
2.30.2

[PATCH] convert K&R into ansi

[Guy-Fleury Iteriteka]

---
 i386/i386/ast_check.c  |  6 ++
 i386/i386/fpu.c| 10 --
 i386/i386/kttd_interface.c |  3 +--
 i386/i386/pcb.c|  9 -
 i386/i386/trap.c   |  3 +--
 i386/i386/user_ldt.c   | 12 ++--
 i386/i386at/kd_event.c |  8 ++--
 i386/i386at/kd_mouse.c |  5 +
 i386/i386at/kd_queue.c | 10 +++---
 i386/i386at/model_dep.c|  5 +
 i386/intel/pmap.c  | 28 ++--
 kern/machine.c |  7 ++-
 kern/profile.c | 15 +--
 13 files changed, 42 insertions(+), 79 deletions(-)

diff --git a/i386/i386/ast_check.c b/i386/i386/ast_check.c
index f3e1c35..36c665b 100644
--- a/i386/i386/ast_check.c
+++ b/i386/i386/ast_check.c
@@ -37,16 +37,14 @@
 /*
  * Initialize for remote invocation of ast_check.
  */
-void init_ast_check(processor)
-   const processor_t processor;
+void init_ast_check(const processor_t processor)
 {
 }
 
 /*
  * Cause remote invocation of ast_check.  Caller is at splsched().
  */
-void cause_ast_check(processor)
-   const processor_t processor;
+void cause_ast_check(const processor_t processor)
 {
 }
 
diff --git a/i386/i386/fpu.c b/i386/i386/fpu.c
index b47bd33..e57227d 100644
--- a/i386/i386/fpu.c
+++ b/i386/i386/fpu.c
@@ -380,9 +380,8 @@ twd_fxsr_to_i387 (struct i386_xfp_save *fxsave)
  * concurrent fpu_set_state or fpu_get_state.
  */
 kern_return_t
-fpu_set_state(thread, state)
-   const thread_t  thread;
-   struct i386_float_state *state;
+fpu_set_state(const thread_t thread,
+ struct i386_float_state *state)
 {
pcb_t pcb = thread->pcb;
struct i386_fpsave_state *ifps;
@@ -491,9 +490,8 @@ ASSERT_IPL(SPL0);
  * concurrent fpu_set_state or fpu_get_state.
  */
 kern_return_t
-fpu_get_state(thread, state)
-   const thread_t  thread;
-   struct i386_float_state *state;
+fpu_get_state(const thread_t thread,
+ struct i386_float_state *state)
 {
pcb_t pcb = thread->pcb;
struct i386_fpsave_state *ifps;
diff --git a/i386/i386/kttd_interface.c b/i386/i386/kttd_interface.c
index c6caa76..f48fe8e 100644
--- a/i386/i386/kttd_interface.c
+++ b/i386/i386/kttd_interface.c
@@ -499,8 +499,7 @@ struct int_regs {
 };
 
 void
-kttd_netentry(int_regs)
-   struct int_regs *int_regs;
+kttd_netentry(struct int_regs *int_regs)
 {
struct i386_interrupt_state *is = int_regs->is;
int s;
diff --git a/i386/i386/pcb.c b/i386/i386/pcb.c
index 2358532..0324584 100644
--- a/i386/i386/pcb.c
+++ b/i386/i386/pcb.c
@@ -829,11 +829,10 @@ user_stack_low(vm_size_t stack_size)
  * Allocate argument area and set registers for first user thread.
  */
 vm_offset_t
-set_user_regs(stack_base, stack_size, exec_info, arg_size)
-   vm_offset_t stack_base; /* low address */
-   vm_offset_t stack_size;
-   const struct exec_info *exec_info;
-   vm_size_t   arg_size;
+set_user_regs(vm_offset_t stack_base, /* low address */
+ vm_offset_t stack_size,
+ const struct exec_info *exec_info,
+ vm_size_t arg_size)
 {
vm_offset_t arg_addr;
struct i386_saved_state *saved_state;
diff --git a/i386/i386/trap.c b/i386/i386/trap.c
index cbf4591..4f8612b 100644
--- a/i386/i386/trap.c
+++ b/i386/i386/trap.c
@@ -643,8 +643,7 @@ i386_exception(
  * return saved state for interrupted user thread
  */
 unsigned
-interrupted_pc(t)
-   const thread_t t;
+interrupted_pc(const thread_t t)
 {
struct i386_saved_state *iss;
 
diff --git a/i386/i386/user_ldt.c b/i386/i386/user_ldt.c
index 09500b4..fdff518 100644
--- a/i386/i386/user_ldt.c
+++ b/i386/i386/user_ldt.c
@@ -253,12 +253,12 @@ i386_set_ldt(
 }
 
 kern_return_t
-i386_get_ldt(thread, first_selector, selector_count, desc_list, count)
-   const thread_t  thread;
-   int first_selector;
-   int selector_count; /* number wanted */
-   struct real_descriptor **desc_list; /* in/out */
-   unsigned int*count; /* in/out */
+i386_get_ldt(const thread_t thread,
+int first_selector,
+int selector_count, /* number wanted */
+struct real_descriptor **desc_list, /* in/out */
+unsigned int *count/* in/out */
+   )
 {
struct user_ldt *user_ldt;
pcb_t   pcb;
diff --git a/i386/i386at/kd_event.c b/i386/i386at/kd_event.c
index bed9240..518e485 100644
--- a/i386/i386at/kd_event.c
+++ b/i386/i386at/kd_event.c
@@ -110,10 +110,7 @@ kbdinit(void)
 
 /*ARGSUSED*/
 int
-kbdopen(dev, flags, ior)
-   dev_t dev;
-   int flags;
-   io_req_t ior;
+kbdopen(dev_t dev, int flags, io_req_t ior)
 {
spl_t o_pri = spltty();
kdinit();
@@ -308,8 +305,7 @@ u_int X_kdb_enter_str[512], X_kdb_exit_str[512];
 int   X_kdb_enter_len = 0,  X_kdb_exit_len = 0;
 
 void
-kdb_in_out(p)
-const u_int *p;

[PATCH] remove `libfshelp_in_hurdlibs` issue

[Guy-Fleury Iteriteka]

---
 open_issues/libfshelp_in_hurdlibs.mdwn | 17 -
 1 file changed, 17 deletions(-)
 delete mode 100644 open_issues/libfshelp_in_hurdlibs.mdwn

diff --git a/open_issues/libfshelp_in_hurdlibs.mdwn 
b/open_issues/libfshelp_in_hurdlibs.mdwn
deleted file mode 100644
index 0700b06..000
--- a/open_issues/libfshelp_in_hurdlibs.mdwn
+++ /dev/null
@@ -1,17 +0,0 @@
-[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]]
-
-[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
-id="license" text="Permission is granted to copy, distribute and/or modify this
-document under the terms of the GNU Free Documentation License, Version 1.2 or
-any later version published by the Free Software Foundation; with no Invariant
-Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
-is included in the section entitled
-[[GNU Free Documentation License|/fdl]]."]]"""]]
-
-[[!meta title="libfshelp in HURDLIBS"]]
-
-[[!tag open_issue_hurd]]
-
-[[hurd/libtrivfs]] seems to use [[hurd/libfshelp]], but doesn't have it listed
-in `HURDLIBS`.  Should we change that?  Same for [[hurd/libnetfs]] and
-[[hurd/libdiskfs]]?
-- 
2.30.2

[PATCH] remove `mmap_crash_etc` issue

[Guy-Fleury Iteriteka]

---
 open_issues/mmap_crash_etc.mdwn | 95 -
 1 file changed, 95 deletions(-)
 delete mode 100644 open_issues/mmap_crash_etc.mdwn

diff --git a/open_issues/mmap_crash_etc.mdwn b/open_issues/mmap_crash_etc.mdwn
deleted file mode 100644
index 4946a5a..000
--- a/open_issues/mmap_crash_etc.mdwn
+++ /dev/null
@@ -1,95 +0,0 @@
-[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
-
-[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
-id="license" text="Permission is granted to copy, distribute and/or modify this
-document under the terms of the GNU Free Documentation License, Version 1.2 or
-any later version published by the Free Software Foundation; with no Invariant
-Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
-is included in the section entitled [[GNU Free Documentation
-License|/fdl]]."]]"""]]
-
-Several issues here:
-
-  * [[!tag open_issue_glibc open_issue_gnumach]] Even invalid `mmap` shoudn't
-crash the process.
-
-  * [[!tag open_issue_documentation]] The memory layout example should be
-documented.
-
-  * [[!tag open_issue_gnumach]] New `vm_map` allocation strategy may be
-desirable; see also [[placement_of_virtual_memory_regions]].
-
-  * [[!tag open_issue_glibc]] *task X deallocating an invalid port Y, most
-probably a bug*.
-
-IRC, freenode, #hurd, 2011-08-11
-
-< zyg> oh, mmap sigsegvs, strange.
-< braunr> hwo do you see that ?
-< zyg> braunr: I'll try to paste a minimal case
-< braunr> zyg: make sure you have a sane memory setup
-< braunr> 512 RAM / 1G swap seems good
-< braunr> have more swap than RAM
-< zyg> I have those. Still it shouldn't sigsegv.
-< braunr> gnumach is picky about that
-< braunr> and yes, the hurd shouldn't have bugs
-< zyg> braunr: ready to crash? #include  #include  int
-  main (int argc, char **argv) { mmap(0x1, 0x8000, PROT_READ, MAP_ANON
-  | MAP_FIXED, -1, 0); return 0; }
-< braunr> a fixed mapping at such an address is likely to fail, yes
-< braunr> but a crash, hm
-< zyg> why should it fail?
-< braunr> because the hurd doesn't have a common text data bss heap stack
-  layout
-< braunr> e.g. there are mappings below text, as show by vminfo :
-< braunr> $ vminfo $$
-< braunr>  0[0x1000] (prot=0)
-< braunr> 0x1000[0x21000] (prot=RX, max_prot=RWX, mem_obj=105)
-< braunr>0x22000[0x1000] (prot=R, max_prot=RWX, mem_obj=105)
-< braunr>0x23000[0x1000] (prot=RW, max_prot=RWX, mem_obj=105)
-< braunr>0x24000[0x1000] (prot=0, max_prot=RWX)
-< braunr>0x25000[0xfff000] (prot=RWX, mem_obj=106)
-< braunr>  0x1024000[0x1000] (prot=RWX, mem_obj=107)
-< braunr>  0x1025000[0x1000] (prot=RW, max_prot=RWX, mem_obj=108)
-< braunr>  0x1026000[0x1000] (prot=RW, max_prot=RWX, mem_obj=108,
-  offs=0x1000)
-< braunr>  0x1027000[0x1000] (prot=RW, max_prot=RWX, mem_obj=109)
-< braunr>  0x1028000[0x2000] (prot=RW, max_prot=RWX, mem_obj=110,
-  offs=0x1000)
-< braunr>  0x102a000[0x1000] (prot=RW, max_prot=RWX, mem_obj=111)
-< braunr> (sorry for the long paste)
-< zyg> oh.. my mmap falls into an occupied range?
-< braunr> seems so
-< zyg> thanks, that was really useful.
-< braunr> MAP_FIXED isn't portable, this is clearly stated in most man
-  pages
-< zyg> yes, implementation specific it says
-< braunr> well the behaviour isn't specific, it's well defined, but the
-  memory layout isn't
-< braunr> i personally think vm_map() should be slightly changed to include
-  a new flag for top-down allocations
-< braunr> so that our stack and libraries are at high addresses, below the
-  kernel
-< braunr> zyg: what kind of error do you get ? i don't get sigsegv
-< zyg> I get both sigsegv and sigill depending on addr
-< braunr> ok
-< braunr> i get sigill with your example
-< braunr> the error is the same (wrong memory access) but the behaviour
-  changes because of the special memory configuration
-< zyg> yes.. I guess the usecase is too uncommon. Else mmap would have an
-  guard
-< braunr> some accesses cause invalid page faults (which are sent as
-  segmentation faults) while other cause general protection faults (which
-  are sent as illegal instructions)
-< braunr> (this is quite weird since the GP fault is likely because the
-  access targets something out of the data or code segment eh)
-< zyg> braunr: that's very os-specific. Do you mean hurd behaves that way?
-< braunr> gnumach
-< braunr> on i386
-< braunr> the segmant configuration isn't completely flat
-< braunr> segment*
-< braunr> hm nice
-< braunr> your small program triggers the "task X deallocating an invalid
-  port Y, most probably a bug." message
-< zyg> where do you see that?
-< braunr> on the mach console
-- 
2.30.

[PATCH] remove pth issue

[Guy-Fleury Iteriteka]

---
 open_issues/pth.mdwn | 28 
 1 file changed, 28 deletions(-)
 delete mode 100644 open_issues/pth.mdwn

diff --git a/open_issues/pth.mdwn b/open_issues/pth.mdwn
deleted file mode 100644
index 12bf509..000
--- a/open_issues/pth.mdwn
+++ /dev/null
@@ -1,28 +0,0 @@
-[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation,
-Inc."]]
-
-[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
-id="license" text="Permission is granted to copy, distribute and/or modify this
-document under the terms of the GNU Free Documentation License, Version 1.2 or
-any later version published by the Free Software Foundation; with no Invariant
-Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
-is included in the section entitled
-[[GNU Free Documentation License|/fdl]]."]]"""]]
-
-[[!tag open_issue_porting]]
-
-IRC, unknown channel, unknown date.
-
- seems pth still doesn't work
- Doesn't build or doesn't work?
- both
- some configure test keep grinding the CPU, same for the test suite
- which apparently runs pth_init() and never returns
-
- actually, pth fails to build right now
- pth_mctx.c:477: error: request for member '__pc' in something not 
a structure or union
-
- I know the pth test suite fails (it locks up the machine) or used 
to fail, so I guess porting work for pth would be needed
- < marcusb> from reading the pth/PORTING document, porting libpth 
shouldn't be too hard...
-
- dropped pth [from the channel's topic], as we think we know why it 
fails (sigaltstack is bogus)
-- 
2.30.2

Re: [PATCH] remove `mmap_crash_etc` issue

[Guy-Fleury Iteriteka]

On May 30, 2022 10:17:29 PM GMT+02:00, Samuel Thibault 
 wrote:
>Why removing it?

The test case in log doesn't crash.
>
>Guy-Fleury Iteriteka, le lun. 30 mai 2022 22:03:12 +0200, a ecrit:
>> -  * [[!tag open_issue_documentation]] The memory layout example should be
>> -documented.
>
>That one could be useful.
>
>> -  * [[!tag open_issue_gnumach]] New `vm_map` allocation strategy may be
>> -desirable; see also [[placement_of_virtual_memory_regions]].
>
>That one would be really desirable.
>
I admit that I haven't look well to others implication
>Samuel

Re: GNU System

[Guy-Fleury Iteriteka]

On September 14, 2022 9:26:30 PM GMT+02:00, carlosgonz 
 wrote:
>Hi friends.
>
>I success install Debian Hurd on my Thinkpad T60, but i having some issues,
>
great.
>1. when is booting the system can not reach boot gnome enviroment, it stock on 
>terminal, so not sure what to do to pass to gnome shell.
>
I don't think gnome will work. Try icevm or may be xfce4 
>2. The other issues is that when booting first or second time it showing on 
>the screen a Filesystem error, also that the Filesystem can not be unmonted.
>
Use sudo hurd-halt( or halt-hurd i don't remamber well) to shutdown the system 
instead of 'halt' 
>Thank of advance

[PATCH 0/4] move some htl symbol into libc

[Guy-Fleury Iteriteka]

Hello,

Samuel can you help moving the pthread_self into libc as an
example so that i can go ahead and move others that are not difficult
for me.

pthread_equal is removed from libpthread.so but
with the patch for pthread_self is in both libc.so and libpthread.so.

this is libpthread.so
---
 U ___pthread_self@GLIBC_PRIVATE
6630 t __pthread_self
6630 t pthread_self
---

and this libc.so
---
0028 b __GIpthread_self
0028 B ___pthread_self
001cf570 T __pthread_self
001cf570 W pthread_self
---

i was thinking that it is with this makefile rule
--
extra-B-pthread.so = -B$(common-objpfx)htl/
--
in htl/Makefile that will force the pthread_self inclusion.
that would explain why pthread_equal is remove because it is in 
sysdeps/htl/.

thanks.
Guy-Fleury Iteriteka (4):
  htl: move __pthread-total into libc.
  htl: move ___pthread_self to libc
  htl: move pthread_equal into libc
  htl: move pthread_self into libc

 htl/Makefile  |  5 ++---
 htl/Versions  | 11 ++-
 htl/forward.c |  8 
 htl/pt-create.c   |  6 --
 htl/pt-initialize.c   |  2 --
 htl/pt-internal.h |  1 +
 htl/pt-total.c| 23 +++
 sysdeps/htl/pthread-functions.h   |  4 
 sysdeps/mach/hurd/htl/pt-dep-self.c   | 22 ++
 sysdeps/mach/hurd/htl/pt-sysdep.c |  2 +-
 sysdeps/mach/hurd/htl/pt-sysdep.h |  3 +++
 sysdeps/mach/hurd/i386/libc.abilist   |  2 ++
 sysdeps/mach/hurd/i386/libpthread.abilist |  2 --
 13 files changed, 60 insertions(+), 31 deletions(-)
 create mode 100644 htl/pt-total.c
 create mode 100644 sysdeps/mach/hurd/htl/pt-dep-self.c

-- 
2.37.2

[PATCH 3/4] htl: move pthread_equal into libc

[Guy-Fleury Iteriteka]

---
 htl/Makefile  | 3 +--
 htl/Versions  | 2 +-
 htl/forward.c | 4 
 htl/pt-initialize.c   | 1 -
 sysdeps/htl/pthread-functions.h   | 2 --
 sysdeps/mach/hurd/i386/libc.abilist   | 1 +
 sysdeps/mach/hurd/i386/libpthread.abilist | 1 -
 7 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/htl/Makefile b/htl/Makefile
index 72e37fbd..a7b013ec 100644
--- a/htl/Makefile
+++ b/htl/Makefile
@@ -46,7 +46,6 @@ libpthread-routines := pt-attr pt-attr-destroy 
pt-attr-getdetachstate \
pt-alloc\
pt-create   \
pt-getattr  \
-   pt-equal\
pt-dealloc  \
pt-detach   \
pt-exit \
@@ -165,7 +164,7 @@ headers :=  \
 distribute :=
 
 routines := forward libc_pthread_init alloca_cutoff htlfreeres pt-total \
-   pt-dep-self
+   pt-dep-self pt-equal
 shared-only-routines = forward
 
 extra-libs := libpthread
diff --git a/htl/Versions b/htl/Versions
index 9ec84811..1ef8a6d0 100644
--- a/htl/Versions
+++ b/htl/Versions
@@ -83,7 +83,7 @@ libpthread {
 pthread_condattr_getpshared; pthread_condattr_init;
 pthread_condattr_setclock; pthread_condattr_setpshared;
 
-pthread_create; pthread_detach; pthread_equal; pthread_exit;
+pthread_create; pthread_detach; pthread_exit;
 
 pthread_getattr_np;
 
diff --git a/htl/forward.c b/htl/forward.c
index 00527348..d0f775a2 100644
--- a/htl/forward.c
+++ b/htl/forward.c
@@ -102,10 +102,6 @@ FORWARD (pthread_cond_timedwait,
 (pthread_cond_t *cond, pthread_mutex_t *mutex,
  const struct timespec *abstime), (cond, mutex, abstime), 0)
 
-FORWARD (pthread_equal, (pthread_t thread1, pthread_t thread2),
-(thread1, thread2), 1)
-
-
 /* Use an alias to avoid warning, as pthread_exit is declared noreturn.  */
 FORWARD_NORETURN (__pthread_exit, void, (void *retval), (retval),
  exit (EXIT_SUCCESS))
diff --git a/htl/pt-initialize.c b/htl/pt-initialize.c
index 02e6ad6b..1d948c40 100644
--- a/htl/pt-initialize.c
+++ b/htl/pt-initialize.c
@@ -47,7 +47,6 @@ static const struct pthread_functions pthread_functions = {
   .ptr_pthread_cond_signal = __pthread_cond_signal,
   .ptr_pthread_cond_wait = __pthread_cond_wait,
   .ptr_pthread_cond_timedwait = __pthread_cond_timedwait,
-  .ptr_pthread_equal = __pthread_equal,
   .ptr___pthread_exit = __pthread_exit,
   .ptr_pthread_getschedparam = __pthread_getschedparam,
   .ptr_pthread_setschedparam = __pthread_setschedparam,
diff --git a/sysdeps/htl/pthread-functions.h b/sysdeps/htl/pthread-functions.h
index c8e5..095a61e6 100644
--- a/sysdeps/htl/pthread-functions.h
+++ b/sysdeps/htl/pthread-functions.h
@@ -45,7 +45,6 @@ int __pthread_cond_signal (pthread_cond_t *);
 int __pthread_cond_wait (pthread_cond_t *, pthread_mutex_t *);
 int __pthread_cond_timedwait (pthread_cond_t *, pthread_mutex_t *,
 const struct timespec *);
-int __pthread_equal (pthread_t, pthread_t);
 void __pthread_exit (void *) __attribute__ ((__noreturn__));
 int __pthread_getschedparam (pthread_t, int *, struct sched_param *);
 int __pthread_setschedparam (pthread_t, int,
@@ -101,7 +100,6 @@ struct pthread_functions
   int (*ptr_pthread_cond_wait) (pthread_cond_t *, pthread_mutex_t *);
   int (*ptr_pthread_cond_timedwait) (pthread_cond_t *, pthread_mutex_t *,
 const struct timespec *);
-  int (*ptr_pthread_equal) (pthread_t, pthread_t);
   void (*ptr___pthread_exit) (void *) __attribute__ ((__noreturn__));
   int (*ptr_pthread_getschedparam) (pthread_t, int *, struct sched_param *);
   int (*ptr_pthread_setschedparam) (pthread_t, int,
diff --git a/sysdeps/mach/hurd/i386/libc.abilist 
b/sysdeps/mach/hurd/i386/libc.abilist
index 4e3200ef..26552958 100644
--- a/sysdeps/mach/hurd/i386/libc.abilist
+++ b/sysdeps/mach/hurd/i386/libc.abilist
@@ -28,6 +28,7 @@ GLIBC_2.11 mkostemps F
 GLIBC_2.11 mkostemps64 F
 GLIBC_2.11 mkstemps F
 GLIBC_2.11 mkstemps64 F
+GLIBC_2.12 pthread_equal F
 GLIBC_2.13 __fentry__ F
 GLIBC_2.14 syncfs F
 GLIBC_2.15 __fdelt_chk F
diff --git a/sysdeps/mach/hurd/i386/libpthread.abilist 
b/sysdeps/mach/hurd/i386/libpthread.abilist
index b9c9b75c..84f2643b 100644
--- a/sysdeps/mach/hurd/i386/libpthread.abilist
+++ b/sysdeps/mach/hurd/i386/libpthread.abilist
@@ -65,7 +65,6 @@ GLIBC_2.12 pthread_condattr_setclock F
 GLIBC_2.12 pthread_condattr_setpshared F
 GLIBC_2.12 pthread_create F
 GLIBC_2.12 pthread_detach F
-GLIBC_2.12 pthread_equal F
 GLIBC_2.

[PATCH 2/4] htl: move ___pthread_self to libc

[Guy-Fleury Iteriteka]

htl/Makefile(routine): add pt-dep-self
htl/Versions(___pthread_self): add to libc symbol
sysdeps/mach/hurd/htl/pt-dep-self.c: New file
sysdeps/mach/hurd/htl/pt-sysdep.c(___pthread_seld): remove
definition.
sysdeps/mach/hurd/htl/pt-sysdep.h(___pthread_self):
add hidden property
---
 htl/Makefile|  3 ++-
 htl/Versions|  1 +
 sysdeps/mach/hurd/htl/pt-dep-self.c | 22 ++
 sysdeps/mach/hurd/htl/pt-sysdep.c   |  2 +-
 sysdeps/mach/hurd/htl/pt-sysdep.h   |  3 +++
 5 files changed, 29 insertions(+), 2 deletions(-)
 create mode 100644 sysdeps/mach/hurd/htl/pt-dep-self.c

diff --git a/htl/Makefile b/htl/Makefile
index ad0e2645..72e37fbd 100644
--- a/htl/Makefile
+++ b/htl/Makefile
@@ -164,7 +164,8 @@ headers :=  \
 
 distribute :=
 
-routines := forward libc_pthread_init alloca_cutoff htlfreeres pt-total
+routines := forward libc_pthread_init alloca_cutoff htlfreeres pt-total \
+   pt-dep-self
 shared-only-routines = forward
 
 extra-libs := libpthread
diff --git a/htl/Versions b/htl/Versions
index 113110f4..9ec84811 100644
--- a/htl/Versions
+++ b/htl/Versions
@@ -31,6 +31,7 @@ libc {
 __libc_pthread_init;
 __pthread_cleanup_stack;
 __pthread_total;
+___pthread_self;
   }
 }
 
diff --git a/sysdeps/mach/hurd/htl/pt-dep-self.c 
b/sysdeps/mach/hurd/htl/pt-dep-self.c
new file mode 100644
index ..82cb0524
--- /dev/null
+++ b/sysdeps/mach/hurd/htl/pt-dep-self.c
@@ -0,0 +1,22 @@
+/* Thread counter variable.
+   Copyright (C) 2021-2022 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   The GNU C Library 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
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library; if not, see
+   .  */
+
+#include "pt-sysdep.h"
+
+__thread struct __pthread *___pthread_self;
+libc_hidden_tls_def (___pthread_self)
diff --git a/sysdeps/mach/hurd/htl/pt-sysdep.c 
b/sysdeps/mach/hurd/htl/pt-sysdep.c
index 2d828545..3597166d 100644
--- a/sysdeps/mach/hurd/htl/pt-sysdep.c
+++ b/sysdeps/mach/hurd/htl/pt-sysdep.c
@@ -26,7 +26,7 @@
 #include 
 #include 
 
-__thread struct __pthread *___pthread_self;
+#include "pt-sysdep.h"
 
 static void
 reset_pthread_total (void)
diff --git a/sysdeps/mach/hurd/htl/pt-sysdep.h 
b/sysdeps/mach/hurd/htl/pt-sysdep.h
index 854c365c..b28c60d0 100644
--- a/sysdeps/mach/hurd/htl/pt-sysdep.h
+++ b/sysdeps/mach/hurd/htl/pt-sysdep.h
@@ -20,6 +20,7 @@
 #define _PT_SYSDEP_H   1
 
 #include 
+#include 
 
 /* XXX */
 #define _POSIX_THREAD_THREADS_MAX  64
@@ -32,6 +33,8 @@
   mach_msg_header_t wakeupmsg;
 
 extern __thread struct __pthread *___pthread_self;
+libc_hidden_tls_proto (___pthread_self)
+
 #ifdef DEBUG
 #define _pthread_self()\
({ \
-- 
2.37.2

[PATCH 4/4] htl: move pthread_self into libc

[Guy-Fleury Iteriteka]

---
 htl/Makefile  | 3 +--
 htl/Versions  | 7 +++
 htl/forward.c | 4 
 htl/pt-initialize.c   | 1 -
 sysdeps/htl/pthread-functions.h   | 2 --
 sysdeps/mach/hurd/i386/libc.abilist   | 1 +
 sysdeps/mach/hurd/i386/libpthread.abilist | 1 -
 7 files changed, 5 insertions(+), 14 deletions(-)

diff --git a/htl/Makefile b/htl/Makefile
index a7b013ec..57bb22a2 100644
--- a/htl/Makefile
+++ b/htl/Makefile
@@ -51,7 +51,6 @@ libpthread-routines := pt-attr pt-attr-destroy 
pt-attr-getdetachstate \
pt-exit \
pt-initialize   \
pt-join \
-   pt-self \
pt-sigmask  \
pt-spin-inlines \
pt-cleanup  \
@@ -164,7 +163,7 @@ headers :=  \
 distribute :=
 
 routines := forward libc_pthread_init alloca_cutoff htlfreeres pt-total \
-   pt-dep-self pt-equal
+   pt-dep-self pt-equal pt-self
 shared-only-routines = forward
 
 extra-libs := libpthread
diff --git a/htl/Versions b/htl/Versions
index 1ef8a6d0..59070181 100644
--- a/htl/Versions
+++ b/htl/Versions
@@ -25,7 +25,9 @@ libc {
   GLIBC_2.32 {
 thrd_current; thrd_equal; thrd_sleep; thrd_yield;
   }
-
+  GLIBC_2.36 {
+__pthread_self;
+  }
   GLIBC_PRIVATE {
 __libc_alloca_cutoff;
 __libc_pthread_init;
@@ -119,9 +121,6 @@ libpthread {
 pthread_rwlockattr_destroy; pthread_rwlockattr_getpshared;
 pthread_rwlockattr_init; pthread_rwlockattr_setpshared;
 
-pthread_self;
-__pthread_self;
-
 pthread_setcancelstate; pthread_setcanceltype;
 pthread_setconcurrency; pthread_setschedparam;
 pthread_setschedprio; pthread_setspecific;
diff --git a/htl/forward.c b/htl/forward.c
index d0f775a2..41985f14 100644
--- a/htl/forward.c
+++ b/htl/forward.c
@@ -126,10 +126,6 @@ FORWARD (pthread_mutex_lock, (pthread_mutex_t *mutex), 
(mutex), 0)
 
 FORWARD (pthread_mutex_unlock, (pthread_mutex_t *mutex), (mutex), 0)
 
-
-FORWARD2 (pthread_self, pthread_t, (void), (), return 0)
-
-
 FORWARD (__pthread_setcancelstate, (int state, int *oldstate),
 (state, oldstate), 0)
 strong_alias (__pthread_setcancelstate, pthread_setcancelstate);
diff --git a/htl/pt-initialize.c b/htl/pt-initialize.c
index 1d948c40..225736fe 100644
--- a/htl/pt-initialize.c
+++ b/htl/pt-initialize.c
@@ -55,7 +55,6 @@ static const struct pthread_functions pthread_functions = {
   .ptr_pthread_mutex_lock = __pthread_mutex_lock,
   .ptr_pthread_mutex_trylock = __pthread_mutex_trylock,
   .ptr_pthread_mutex_unlock = __pthread_mutex_unlock,
-  .ptr_pthread_self = __pthread_self,
   .ptr___pthread_setcancelstate = __pthread_setcancelstate,
   .ptr_pthread_setcanceltype = __pthread_setcanceltype,
   .ptr___pthread_get_cleanup_stack = __pthread_get_cleanup_stack,
diff --git a/sysdeps/htl/pthread-functions.h b/sysdeps/htl/pthread-functions.h
index 095a61e6..4d9896ea 100644
--- a/sysdeps/htl/pthread-functions.h
+++ b/sysdeps/htl/pthread-functions.h
@@ -55,7 +55,6 @@ int _pthread_mutex_init (pthread_mutex_t *,
 int __pthread_mutex_lock (pthread_mutex_t *);
 int __pthread_mutex_trylock (pthread_mutex_t *);
 int __pthread_mutex_unlock (pthread_mutex_t *);
-pthread_t __pthread_self (void);
 int __pthread_setcancelstate (int, int *);
 int __pthread_setcanceltype (int, int *);
 struct __pthread_cancelation_handler **__pthread_get_cleanup_stack (void);
@@ -110,7 +109,6 @@ struct pthread_functions
   int (*ptr_pthread_mutex_lock) (pthread_mutex_t *);
   int (*ptr_pthread_mutex_trylock) (pthread_mutex_t *);
   int (*ptr_pthread_mutex_unlock) (pthread_mutex_t *);
-  pthread_t (*ptr_pthread_self) (void);
   int (*ptr___pthread_setcancelstate) (int, int *);
   int (*ptr_pthread_setcanceltype) (int, int *);
   struct __pthread_cancelation_handler **(*ptr___pthread_get_cleanup_stack) 
(void);
diff --git a/sysdeps/mach/hurd/i386/libc.abilist 
b/sysdeps/mach/hurd/i386/libc.abilist
index 26552958..bfa47282 100644
--- a/sysdeps/mach/hurd/i386/libc.abilist
+++ b/sysdeps/mach/hurd/i386/libc.abilist
@@ -29,6 +29,7 @@ GLIBC_2.11 mkostemps64 F
 GLIBC_2.11 mkstemps F
 GLIBC_2.11 mkstemps64 F
 GLIBC_2.12 pthread_equal F
+GLIBC_2.12 pthread_self F
 GLIBC_2.13 __fentry__ F
 GLIBC_2.14 syncfs F
 GLIBC_2.15 __fdelt_chk F
diff --git a/sysdeps/mach/hurd/i386/libpthread.abilist 
b/sysdeps/mach/hurd/i386/libpthread.abilist
index 84f2643b..d15ba070 100644
--- a/sysdeps/mach/hurd/i386/libpthread.abilist
+++ b/sysdeps/mach/hurd/i386/libpthread.abilist
@@ -108,7 +108,6 @@ GLIBC_2.12 pthread_rwlockattr_destroy F
 GLIBC_2.12 pthread

[PATCH 1/4] htl: move __pthread-total into libc.

[Guy-Fleury Iteriteka]

* htl/Makefile(routine): add pt-total.
  htl/Versions(libc[PRIVATE]): add __pthread-total.
  htl/pt-create.c(__pthread-total): remove it
  htl/pt-total.c: New file.
  htl/pt-total.c(__pthread-total): move definition here.
  htl/pt-internal(__pthread-total): add to it libc_hidden_proto
proprerty.
---
 htl/Makefile  |  2 +-
 htl/Versions  |  1 +
 htl/pt-create.c   |  6 --
 htl/pt-internal.h |  1 +
 htl/pt-total.c| 23 +++
 5 files changed, 26 insertions(+), 7 deletions(-)
 create mode 100644 htl/pt-total.c

diff --git a/htl/Makefile b/htl/Makefile
index 0b403e2f..ad0e2645 100644
--- a/htl/Makefile
+++ b/htl/Makefile
@@ -164,7 +164,7 @@ headers :=  \
 
 distribute :=
 
-routines := forward libc_pthread_init alloca_cutoff htlfreeres
+routines := forward libc_pthread_init alloca_cutoff htlfreeres pt-total
 shared-only-routines = forward
 
 extra-libs := libpthread
diff --git a/htl/Versions b/htl/Versions
index 4e0ebac2..113110f4 100644
--- a/htl/Versions
+++ b/htl/Versions
@@ -30,6 +30,7 @@ libc {
 __libc_alloca_cutoff;
 __libc_pthread_init;
 __pthread_cleanup_stack;
+__pthread_total;
   }
 }
 
diff --git a/htl/pt-create.c b/htl/pt-create.c
index 5d37edbb..34a63b6a 100644
--- a/htl/pt-create.c
+++ b/htl/pt-create.c
@@ -36,12 +36,6 @@
 # include 
 #endif
 
-/* The total number of pthreads currently active.  This is defined
-   here since it would be really stupid to have a threads-using
-   program that doesn't call `pthread_create'.  */
-unsigned int __pthread_total;
-
-
 /* The entry-point for new threads.  */
 static void
 entry_point (struct __pthread *self, void *(*start_routine) (void *), void 
*arg)
diff --git a/htl/pt-internal.h b/htl/pt-internal.h
index f01cb7ce..b787acf8 100644
--- a/htl/pt-internal.h
+++ b/htl/pt-internal.h
@@ -165,6 +165,7 @@ __pthread_dequeue (struct __pthread *thread)
 
 /* The total number of threads currently active.  */
 extern unsigned int __pthread_total;
+libc_hidden_proto (__pthread_total)
 
 /* Concurrency hint.  */
 extern int __pthread_concurrency;
diff --git a/htl/pt-total.c b/htl/pt-total.c
new file mode 100644
index ..8188131c
--- /dev/null
+++ b/htl/pt-total.c
@@ -0,0 +1,23 @@
+/* Thread counter variable.
+   Copyright (C) 2021-2022 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   The GNU C Library 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
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library; if not, see
+   .  */
+
+#include 
+
+/* Number of threads running.  */
+unsigned int __pthread_total;
+libc_hidden_data_def (__pthread_total)
-- 
2.37.2

Re: [PATCH 0/4] move some htl symbol into libc

[Guy-Fleury Iteriteka]

On October 29, 2022 3:34:38 PM GMT+02:00, Samuel Thibault 
 wrote:
>Hello,
>
>Guy-Fleury Iteriteka, le sam. 29 oct. 2022 12:56:22 +0100, a ecrit:
>> Samuel can you help moving the pthread_self into libc as an
>> example so that i can go ahead and move others that are not difficult
>> for me.
>
>I'd say contact on libc-alpha the people who did it on Linux, they do
>know the pitfalls of the operation.

Thanks, done so
>
>Samuel
>
>> pthread_equal is removed from libpthread.so but
>> with the patch for pthread_self is in both libc.so and libpthread.so.
>> 
>> this is libpthread.so
>> ---
>>  U ___pthread_self@GLIBC_PRIVATE
>> 6630 t __pthread_self
>> 6630 t pthread_self
>> ---
>> 
>> and this libc.so
>> ---
>> 0028 b __GIpthread_self
>> 0028 B ___pthread_self
>> 001cf570 T __pthread_self
>> 001cf570 W pthread_self
>> ---
>> 
>> i was thinking that it is with this makefile rule
>> --
>> extra-B-pthread.so = -B$(common-objpfx)htl/
>> --
>> in htl/Makefile that will force the pthread_self inclusion.
>> that would explain why pthread_equal is remove because it is in 
>> sysdeps/htl/.
>> 
>> thanks.
>> Guy-Fleury Iteriteka (4):
>>   htl: move __pthread-total into libc.
>>   htl: move ___pthread_self to libc
>>   htl: move pthread_equal into libc
>>   htl: move pthread_self into libc
>> 
>>  htl/Makefile  |  5 ++---
>>  htl/Versions  | 11 ++-
>>  htl/forward.c |  8 
>>  htl/pt-create.c   |  6 --
>>  htl/pt-initialize.c   |  2 --
>>  htl/pt-internal.h |  1 +
>>  htl/pt-total.c| 23 +++
>>  sysdeps/htl/pthread-functions.h   |  4 
>>  sysdeps/mach/hurd/htl/pt-dep-self.c   | 22 ++
>>  sysdeps/mach/hurd/htl/pt-sysdep.c |  2 +-
>>  sysdeps/mach/hurd/htl/pt-sysdep.h |  3 +++
>>  sysdeps/mach/hurd/i386/libc.abilist   |  2 ++
>>  sysdeps/mach/hurd/i386/libpthread.abilist |  2 --
>>  13 files changed, 60 insertions(+), 31 deletions(-)
>>  create mode 100644 htl/pt-total.c
>>  create mode 100644 sysdeps/mach/hurd/htl/pt-dep-self.c
>> 
>> -- 
>> 2.37.2
>> 
>> 
>

[PATCH] remove pthread_atfork issue

[Guy-Fleury Iteriteka]

* open_issues/pthread_atfork.mdwn: delete file
---
 open_issues/pthread_atfork.mdwn | 111 
 1 file changed, 111 deletions(-)
 delete mode 100644 open_issues/pthread_atfork.mdwn

diff --git a/open_issues/pthread_atfork.mdwn b/open_issues/pthread_atfork.mdwn
deleted file mode 100644
index d386e5c..000
--- a/open_issues/pthread_atfork.mdwn
+++ /dev/null
@@ -1,111 +0,0 @@
-[[!meta copyright="Copyright © 2011, 2013 Free Software Foundation, Inc."]]
-
-[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
-id="license" text="Permission is granted to copy, distribute and/or modify this
-document under the terms of the GNU Free Documentation License, Version 1.2 or
-any later version published by the Free Software Foundation; with no Invariant
-Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
-is included in the section entitled [[GNU Free Documentation
-License|/fdl]]."]]"""]]
-
-[[!tag open_issue_glibc open_issue_libpthread]]
-
-`pthread_atfork` is not actually implemented, making some programs fail. Code
-can probably be borrowed from `nptl/sysdeps/unix/sysv/linux/register-atfork.c`.
-
-
-# IRC, OFTC, #debian-hurd, 2013-08-21
-
- SRCDIR/opal/mca/memory/linux/arena.c:387: warning: warning:
-  pthread_atfork is not implemented and will always fail
-
-
-# Samuel's implementation
-
-TODO.
-
-
-## IRC, OFTC, #debian-hurd, 2013-10-08
-
- youpi: if you need/want to test your pthread_atfork
-  implementation, you can check libposix-atfork-perl and its test suite
-  (whose test 004 hangs now, with eglibc -93)
- while it failed previously indeed
- we might simply need to rebuild perl against it
- (I see ifdef pthread_atfork in perl)
-
-
-## undefined reference to `__start__hurd_atfork_prepare_hook'
-
-### IRC, freenode, #hurd, 2013-10-16
-
- tschwinge: I'd love to try your cross-gnu tool, the wiki page
-  suggests that the list of required source packages is outdated. can you
-  give me some hints?
- tschwinge: I got this error running cross-gnu:
-  http://paste.debian.net/58303/
-make[4]: Leaving directory 
`/home/teythoon/repos/hurd/cross/src/glibc/setjmp'
-make subdir=string -C ../string ..=../ 
objdir=/home/teythoon/repos/hurd/cross/obj/glibc -f Makefile -f 
../elf/rtld-Rules rtld-all rtld-modules='rtld-strchr.os rtld-strcmp.os 
rtld-strcpy.os rtld-strlen.os rtld-strnlen.os rtld-memchr.os rtld-memcmp.os 
rtld-memmove.os rtld-memset.os rtld-mempcpy.os rtld-stpcpy.os rtld-memcpy.os 
rtld-rawmemchr.os rtld-argz-count.os rtld-argz-extract.os rtld-stpncpy.os'
-make[4]: Entering directory 
`/home/teythoon/repos/hurd/cross/src/glibc/string'
-make[4]: Leaving directory 
`/home/teythoon/repos/hurd/cross/src/glibc/string'
-make[4]: Entering directory 
`/home/teythoon/repos/hurd/cross/src/glibc/string'
-make[4]: Nothing to be done for `rtld-all'.
-make[4]: Leaving directory 
`/home/teythoon/repos/hurd/cross/src/glibc/string'
-make[3]: Leaving directory 
`/home/teythoon/repos/hurd/cross/src/glibc/elf'
-i686-pc-gnu-gcc   -shared -static-libgcc -Wl,-O1  -Wl,-z,defs 
-Wl,-dynamic-linker=/lib/ld.so.1  
-B/home/teythoon/repos/hurd/cross/obj/glibc/csu/  
-Wl,--version-script=/home/teythoon/repos/hurd/cross/obj/glibc/libc.map 
-Wl,-soname=libc.so.0.3 -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both 
-nostdlib -nostartfiles -e __libc_main 
-L/home/teythoon/repos/hurd/cross/obj/glibc 
-L/home/teythoon/repos/hurd/cross/obj/glibc/math 
-L/home/teythoon/repos/hurd/cross/obj/glibc/elf 
-L/home/teythoon/repos/hurd/cross/obj/glibc/dlfcn 
-L/home/teythoon/repos/hurd/cross/obj/glibc/nss 
-L/home/teythoon/repos/hurd/cross/obj/glibc/nis 
-L/home/teythoon/repos/hurd/cross/obj/glibc/rt 
-L/home/teythoon/repos/hurd/cross/obj/glibc/resolv 
-L/home/teythoon/repos/hurd/cross/obj/glibc/crypt 
-L/home/teythoon/repos/hurd/cross/obj/glibc/mach 
-L/home/teythoon/repos/hurd/cross/obj/glibc/hurd 
-Wl,-rpath-link=/home/teythoon/repos/hurd/cross/obj/glibc:/home/teythoon/repos/hurd/cross/obj/glibc/math:/home/teythoon/repos/hurd/cross/obj/glibc/elf:/home/teythoon/repos/hurd/cross/obj/glibc/dlfcn:/home/teythoon/repos/hurd/cross/obj/glibc/nss:/home/teythoon/repos/hurd/cross/obj/glibc/nis:/home/teythoon/repos/hurd/cross/obj/glibc/rt:/home/teythoon/repos/hurd/cross/obj/glibc/resolv:/home/teythoon/repos/hurd/cross/obj/glibc/crypt:/home/teythoon/repos/hurd/cross/obj/glibc/mach:/home/teythoon/repos/hurd/cross/obj/glibc/hurd
 -o /home/teythoon/repos/hurd/cross/obj/glibc/libc.so -T 
/home/teythoon/repos/hurd/cross/obj/glibc/shlib.lds 
/home/teythoon/repos/hurd/cross/obj/glibc/csu/abi-note.o 
/home/teythoon/repos/hurd/cross/obj/glibc/elf/soinit.os 
/home/teythoon/repos/hurd/cross/obj/glibc/libc_pic.os 
/home/teythoon/repos/hurd/cross/obj/glibc/elf/sofini.os 
/home/teythoon/repos/hurd/cross/obj/glibc/elf/interp.os 
/home/teythoon/repos/hurd/cross/obj/glibc/elf/ld.s

Re: lost ssh access - where is a log?

[Guy-Fleury Iteriteka]

Hi,

On November 29, 2022 1:27:00 AM GMT+02:00, Riccardo Mottola 
 wrote:
>Hi!
>
>after some updates and other works, I can no longer ssh into my HURD system.
>
>I can do a local log-in and I can telnet to it.
>
>ssh yields:
>
>$ ssh -Y 192.168.1.154
>Connection reset by 192.168.1.154 port 22
>
>I do not find any useful log in /var/log ! how can I get a ssh log?
>
There is a thread from bugaev that explain the issue and a partial fix :

https://floss.social/@bugaevc/109422269238549581

>Cheers,
>
>
>Riccardo
>
>

Thanks

[PATCH 1/2] convert K&R into ansi.

[Guy-Fleury Iteriteka]

---
 kern/mach_clock.c | 20 +++-
 1 file changed, 7 insertions(+), 13 deletions(-)

diff --git a/kern/mach_clock.c b/kern/mach_clock.c
index c6e54c2..ad986c6 100644
--- a/kern/mach_clock.c
+++ b/kern/mach_clock.c
@@ -433,9 +433,7 @@ read_time_stamp (time_value_t *stamp, time_value_t *result)
  * Read the time.
  */
 kern_return_t
-host_get_time(host, current_time)
-   const host_thost;
-   time_value_t*current_time;  /* OUT */
+host_get_time(const host_t host, time_value_t *current_time)
 {
if (host == HOST_NULL)
return(KERN_INVALID_HOST);
@@ -448,9 +446,7 @@ host_get_time(host, current_time)
  * Set the time.  Only available to privileged users.
  */
 kern_return_t
-host_set_time(host, new_time)
-   const host_thost;
-   time_value_tnew_time;
+host_set_time(const host_t host, time_value_t new_time)
 {
spl_t   s;
 
@@ -487,10 +483,10 @@ host_set_time(host, new_time)
  * Adjust the time gradually.
  */
 kern_return_t
-host_adjust_time(host, new_adjustment, old_adjustment)
-   const host_thost;
-   time_value_tnew_adjustment;
-   time_value_t*old_adjustment;/* OUT */
+host_adjust_time(
+   const host_thost,
+   time_value_tnew_adjustment,
+   time_value_t*old_adjustment /* OUT */)
 {
time_value_toadj;
unsigned intndelta;
@@ -598,9 +594,7 @@ void timeout(
  * Returns a boolean indicating whether the timeout element was found
  * and removed.
  */
-boolean_t untimeout(fcn, param)
-   void(*fcn)( void * param );
-   const void *param;
+boolean_t untimeout(void (*fcn)( void * param ), const void *param)
 {
spl_t   s;
timer_elt_t elt;
-- 
2.38.1

[PATCH 2/2] convert K&R into ansi

[Guy-Fleury Iteriteka]

---
 ddb/db_aout.c| 55 +---
 ddb/db_break.c   | 67 ++--
 ddb/db_command.c | 20 ++---
 ddb/db_examine.c | 44 ++---
 ddb/db_lex.c |  6 ++--
 ddb/db_macro.c   |  6 ++--
 ddb/db_print.c   | 56 +---
 ddb/db_run.c | 48 +++
 ddb/db_sym.c | 28 +-
 ddb/db_task_thread.c | 23 ++-
 ddb/db_variables.c   | 14 -
 ddb/db_watch.c   | 40 +++---
 ddb/db_write_cmd.c   | 10 +++
 13 files changed, 191 insertions(+), 226 deletions(-)

diff --git a/ddb/db_aout.c b/ddb/db_aout.c
index d3f2e31..8f344d6 100644
--- a/ddb/db_aout.c
+++ b/ddb/db_aout.c
@@ -133,8 +133,7 @@ aout_db_sym_init(
  * check file name or not (check .x pattern)
  */
 private boolean_t __attribute__ ((pure))
-aout_db_is_filename(name)
-   const char *name;
+aout_db_is_filename(const char *name)
 {
while (*name) {
if (*name == '.') {
@@ -150,9 +149,7 @@ aout_db_is_filename(name)
  * special name comparison routine with a name in the symbol table entry
  */
 private boolean_t __attribute__ ((pure))
-aout_db_eq_name(sp, name)
-   const struct nlist *sp;
-   const char *name;
+aout_db_eq_name(const struct nlist *sp, const char * name)
 {
const char *s1, *s2;
 
@@ -185,12 +182,12 @@ aout_db_eq_name(sp, name)
  * fp(in,out): last found text file name symbol entry
  */
 private struct nlist *
-aout_db_search_name(sp, ep, name, type, fp)
-   struct nlist*sp;
-   const struct nlist  *ep;
-   const char  *name;
-   int type;
-   struct nlist**fp;
+aout_db_search_name(
+   struct nlist*sp,
+   const struct nlist  *ep,
+   const char  *name,
+   int type,
+   struct nlist**fp)
 {
struct nlist*file_sp = *fp;
struct nlist*found_sp = 0;
@@ -231,11 +228,11 @@ aout_db_search_name(sp, ep, name, type, fp)
  * search a symbol with file, func and line qualification
  */
 private db_sym_t
-aout_db_qualified_search(stab, file, sym, line)
-   db_symtab_t *stab;
-   const char  *file;
-   const char  *sym;
-   int line;
+aout_db_qualified_search(
+   db_symtab_t *stab,
+   const char  *file,
+   const char  *sym,
+   int line)
 {
struct nlist *sp = (struct nlist *)stab->start;
struct nlist*ep = (struct nlist *)stab->end;
@@ -395,13 +392,13 @@ aout_db_symbol_values(
  * search symbol by value
  */
 private boolean_t
-aout_db_search_by_addr(stab, addr, file, func, line, diff)
-   const db_symtab_t   *stab;
-   vm_offset_t addr;
-   char**file;
-   char**func;
-   int *line;
-   unsigned long   *diff;
+aout_db_search_by_addr(
+   const db_symtab_t   *stab,
+   vm_offset_t addr,
+   char**file,
+   char**func,
+   int *line,
+   unsigned long   *diff)
 {
struct nlist*sp;
struct nlist*line_sp, *func_sp, *file_sp, *line_func;
@@ -488,12 +485,12 @@ aout_db_search_by_addr(stab, addr, file, func, line, diff)
  * Find filename and lineno within, given the current pc.
  */
 boolean_t
-aout_db_line_at_pc(stab, sym, file, line, pc)
-   db_symtab_t *stab;
-   db_sym_tsym;
-   char**file;
-   int *line;
-   db_addr_t   pc;
+aout_db_line_at_pc(
+   db_symtab_t *stab,
+   db_sym_tsym,
+   char**file,
+   int *line,
+   db_addr_t   pc)
 {
char*func;
unsigned long   diff;
diff --git a/ddb/db_break.c b/ddb/db_break.c
index c096216..0456f5f 100644
--- a/ddb/db_break.c
+++ b/ddb/db_break.c
@@ -81,19 +81,18 @@ db_breakpoint_alloc()
 }
 
 static void
-db_breakpoint_free(bkpt)
-   db_breakpoint_t bkpt;
+db_breakpoint_free(db_breakpoint_t bkpt)
 {
bkpt->link = db_free_breakpoints;
db_free_breakpoints = bkpt;
 }
 
 static int
-db_add_thread_breakpoint(bkpt, task_thd, count, task_bpt)
-   const db_breakpoint_t bkpt;
-   vm_offset_t task_thd;
-   int count;
-   boolean_t task_bpt;
+db_add_thread_breakpoint(
+   const db_breakpoint_t bkpt,
+   vm_offset_t task_thd,
+   int count,
+   boolean_t task_bpt)
 {
db_thread_breakpoint_t tp;
 
@@ -155,9 +154,9 @@ db_delete_thread_breakpoint(
 }
 
 static db_thread_breakpoint_t __attribute__ ((pure))
-db_find_thread_breakpoint(bkpt, thread)
-   const db_breakpoint_t bkpt;
-   const thread_t thread;
+db_find_thread_breakpoint(
+  

[PATCH] fix warning from -Wstrict-prototypes

[Guy-Fleury Iteriteka]

---
 ddb/db_sym.c | 2 +-
 ddb/db_sym.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/ddb/db_sym.c b/ddb/db_sym.c
index e78173c..585e0ea 100644
--- a/ddb/db_sym.c
+++ b/ddb/db_sym.c
@@ -192,7 +192,7 @@ db_lookup(char *symstr)
  */
 db_sym_t
 db_sym_parse_and_lookup(
-   db_sym_t(*func)(),
+   db_sym_t(*func) (db_symtab_t *, char*, char*, int),
db_symtab_t *symtab,
char*symstr)
 {
diff --git a/ddb/db_sym.h b/ddb/db_sym.h
index d8f3387..da4a062 100644
--- a/ddb/db_sym.h
+++ b/ddb/db_sym.h
@@ -263,7 +263,7 @@ db_search_in_task_symbol(
 
 extern db_sym_t
 db_sym_parse_and_lookup(
-   db_sym_t(*func)(),
+   db_sym_t(*func) (db_symtab_t *, char*, char*, int),
db_symtab_t *symtab,
char*symstr);
 
-- 
2.38.1

[PATCH 2/3] htl: move ___pthread_self into libc.

[Guy-Fleury Iteriteka]

sysdeps/mach/hurd/htl/pt-pthread_self.c: New file.
htl/Makefile: .. Add it to libc routine.
sysdeps/mach/hurd/htl/pt-sysdep.c(__pthread_self): Remove it.
sysdeps/mach/hurd/htl/pt-sysdep.h(__pthread_self): Add hidden propertie.
htl/Versions(__pthread_self) Version it as private symbol.
---
 htl/Makefile|  2 +-
 htl/Versions|  1 +
 sysdeps/mach/hurd/htl/pt-pthread_self.c | 22 ++
 sysdeps/mach/hurd/htl/pt-sysdep.c   |  2 --
 sysdeps/mach/hurd/htl/pt-sysdep.h   |  3 +++
 5 files changed, 27 insertions(+), 3 deletions(-)
 create mode 100644 sysdeps/mach/hurd/htl/pt-pthread_self.c

diff --git a/htl/Makefile b/htl/Makefile
index 61944148..b569cfcd 100644
--- a/htl/Makefile
+++ b/htl/Makefile
@@ -164,7 +164,7 @@ headers :=  \
 
 distribute :=
 
-routines := forward libc_pthread_init alloca_cutoff htlfreeres pt-nthreads
+routines := forward libc_pthread_init alloca_cutoff htlfreeres pt-nthreads 
pt-pthread_self
 shared-only-routines = forward
 
 extra-libs := libpthread
diff --git a/htl/Versions b/htl/Versions
index 113110f4..9ec84811 100644
--- a/htl/Versions
+++ b/htl/Versions
@@ -31,6 +31,7 @@ libc {
 __libc_pthread_init;
 __pthread_cleanup_stack;
 __pthread_total;
+___pthread_self;
   }
 }
 
diff --git a/sysdeps/mach/hurd/htl/pt-pthread_self.c 
b/sysdeps/mach/hurd/htl/pt-pthread_self.c
new file mode 100644
index ..6398af65
--- /dev/null
+++ b/sysdeps/mach/hurd/htl/pt-pthread_self.c
@@ -0,0 +1,22 @@
+/* Thread counter variable.
+   Copyright (C) 2021-2023 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   The GNU C Library 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
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library; if not, see
+   .  */
+
+#include 
+
+__thread struct __pthread *___pthread_self;
+libc_hidden_tls_def (___pthread_self)
diff --git a/sysdeps/mach/hurd/htl/pt-sysdep.c 
b/sysdeps/mach/hurd/htl/pt-sysdep.c
index 2d828545..4cd6ba3a 100644
--- a/sysdeps/mach/hurd/htl/pt-sysdep.c
+++ b/sysdeps/mach/hurd/htl/pt-sysdep.c
@@ -26,8 +26,6 @@
 #include 
 #include 
 
-__thread struct __pthread *___pthread_self;
-
 static void
 reset_pthread_total (void)
 {
diff --git a/sysdeps/mach/hurd/htl/pt-sysdep.h 
b/sysdeps/mach/hurd/htl/pt-sysdep.h
index 854c365c..94d77678 100644
--- a/sysdeps/mach/hurd/htl/pt-sysdep.h
+++ b/sysdeps/mach/hurd/htl/pt-sysdep.h
@@ -19,6 +19,7 @@
 #ifndef _PT_SYSDEP_H
 #define _PT_SYSDEP_H   1
 
+#include 
 #include 
 
 /* XXX */
@@ -32,6 +33,8 @@
   mach_msg_header_t wakeupmsg;
 
 extern __thread struct __pthread *___pthread_self;
+libc_hidden_tls_proto (___pthread_self)
+
 #ifdef DEBUG
 #define _pthread_self()\
({ \
-- 
2.38.1

[PATCH 0/3] htl: move __pthtread_total, ___pthread_self, pthread_self

[Guy-Fleury Iteriteka]

With this patch i boot up a hurd system with flavio scripts.

Guy-Fleury Iteriteka (3):
  htl: move __pthtread_total into libc
  htl: move __pthread_self into libc.
  htl: move pthread_self into libc

 htl/Makefile  |  3 +--
 htl/Versions  | 15 ---
 htl/forward.c |  4 
 htl/pt-create.c   |  6 --
 htl/pt-initialize.c   |  1 -
 htl/pt-internal.h |  2 ++
 htl/pt-nthreads.c | 23 +++
 htl/pt-self.c |  8 ++--
 sysdeps/htl/pthread-functions.h   |  2 --
 sysdeps/mach/hurd/htl/pt-pthread_self.c   | 22 ++
 sysdeps/mach/hurd/htl/pt-sysdep.c |  2 --
 sysdeps/mach/hurd/htl/pt-sysdep.h |  3 +++
 sysdeps/mach/hurd/i386/libc.abilist   |  2 ++
 sysdeps/mach/hurd/i386/libpthread.abilist |  2 --
 14 files changed, 71 insertions(+), 24 deletions(-)
 create mode 100644 htl/pt-nthreads.c
 create mode 100644 sysdeps/mach/hurd/htl/pt-pthread_self.c

-- 
2.38.1

[PATCH 1/3] htl: move __pthtread_total into libc

[Guy-Fleury Iteriteka]

htl/pt-nthreads.c: new file.
htl/Makefile: Add it to routine.
htl/Versions: version it as private libc symbol.
htl/pt-create.c: remove his definition here.
htl/pt-internal.h: add propertie to it declaration.
---
 htl/Makefile  |  2 +-
 htl/Versions  |  1 +
 htl/pt-create.c   |  6 --
 htl/pt-internal.h |  1 +
 htl/pt-nthreads.c | 23 +++
 5 files changed, 26 insertions(+), 7 deletions(-)
 create mode 100644 htl/pt-nthreads.c

diff --git a/htl/Makefile b/htl/Makefile
index 0b403e2f..61944148 100644
--- a/htl/Makefile
+++ b/htl/Makefile
@@ -164,7 +164,7 @@ headers :=  \
 
 distribute :=
 
-routines := forward libc_pthread_init alloca_cutoff htlfreeres
+routines := forward libc_pthread_init alloca_cutoff htlfreeres pt-nthreads
 shared-only-routines = forward
 
 extra-libs := libpthread
diff --git a/htl/Versions b/htl/Versions
index 4e0ebac2..113110f4 100644
--- a/htl/Versions
+++ b/htl/Versions
@@ -30,6 +30,7 @@ libc {
 __libc_alloca_cutoff;
 __libc_pthread_init;
 __pthread_cleanup_stack;
+__pthread_total;
   }
 }
 
diff --git a/htl/pt-create.c b/htl/pt-create.c
index 5d37edbb..34a63b6a 100644
--- a/htl/pt-create.c
+++ b/htl/pt-create.c
@@ -36,12 +36,6 @@
 # include 
 #endif
 
-/* The total number of pthreads currently active.  This is defined
-   here since it would be really stupid to have a threads-using
-   program that doesn't call `pthread_create'.  */
-unsigned int __pthread_total;
-
-
 /* The entry-point for new threads.  */
 static void
 entry_point (struct __pthread *self, void *(*start_routine) (void *), void 
*arg)
diff --git a/htl/pt-internal.h b/htl/pt-internal.h
index f01cb7ce..b787acf8 100644
--- a/htl/pt-internal.h
+++ b/htl/pt-internal.h
@@ -165,6 +165,7 @@ __pthread_dequeue (struct __pthread *thread)
 
 /* The total number of threads currently active.  */
 extern unsigned int __pthread_total;
+libc_hidden_proto (__pthread_total)
 
 /* Concurrency hint.  */
 extern int __pthread_concurrency;
diff --git a/htl/pt-nthreads.c b/htl/pt-nthreads.c
new file mode 100644
index ..9a6140ee
--- /dev/null
+++ b/htl/pt-nthreads.c
@@ -0,0 +1,23 @@
+/* Thread counter variable.
+   Copyright (C) 2021-2023 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   The GNU C Library 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
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library; if not, see
+   .  */
+
+#include 
+
+/* Number of threads running.  */
+unsigned int __pthread_total;
+libc_hidden_data_def (__pthread_total)
-- 
2.38.1

[PATCH 3/3] htl: move pthread_self into libc

[Guy-Fleury Iteriteka]

---
 htl/Makefile  |  3 +--
 htl/Versions  | 13 ++---
 htl/forward.c |  4 
 htl/pt-initialize.c   |  1 -
 htl/pt-internal.h |  1 +
 htl/pt-self.c |  8 ++--
 sysdeps/htl/pthread-functions.h   |  2 --
 sysdeps/mach/hurd/i386/libc.abilist   |  2 ++
 sysdeps/mach/hurd/i386/libpthread.abilist |  2 --
 9 files changed, 20 insertions(+), 16 deletions(-)

diff --git a/htl/Makefile b/htl/Makefile
index b569cfcd..c75855ad 100644
--- a/htl/Makefile
+++ b/htl/Makefile
@@ -52,7 +52,6 @@ libpthread-routines := pt-attr pt-attr-destroy 
pt-attr-getdetachstate \
pt-exit \
pt-initialize   \
pt-join \
-   pt-self \
pt-sigmask  \
pt-spin-inlines \
pt-cleanup  \
@@ -164,7 +163,7 @@ headers :=  \
 
 distribute :=
 
-routines := forward libc_pthread_init alloca_cutoff htlfreeres pt-nthreads 
pt-pthread_self
+routines := forward libc_pthread_init alloca_cutoff htlfreeres pt-nthreads 
pt-pthread_self pt-self
 shared-only-routines = forward
 
 extra-libs := libpthread
diff --git a/htl/Versions b/htl/Versions
index 9ec84811..e1cb362c 100644
--- a/htl/Versions
+++ b/htl/Versions
@@ -1,4 +1,9 @@
 libc {
+  GLIBC_2.12 {
+ pthread_self;
+__pthread_self;
+  }
+
   GLIBC_2.21 {
 pthread_attr_destroy; pthread_attr_getdetachstate;
 pthread_attr_getinheritsched; pthread_attr_getschedparam;
@@ -26,6 +31,11 @@ libc {
 thrd_current; thrd_equal; thrd_sleep; thrd_yield;
   }
 
+  GLIBC_2.37 {
+pthread_self;
+__pthread_self;
+  }
+
   GLIBC_PRIVATE {
 __libc_alloca_cutoff;
 __libc_pthread_init;
@@ -119,9 +129,6 @@ libpthread {
 pthread_rwlockattr_destroy; pthread_rwlockattr_getpshared;
 pthread_rwlockattr_init; pthread_rwlockattr_setpshared;
 
-pthread_self;
-__pthread_self;
-
 pthread_setcancelstate; pthread_setcanceltype;
 pthread_setconcurrency; pthread_setschedparam;
 pthread_setschedprio; pthread_setspecific;
diff --git a/htl/forward.c b/htl/forward.c
index 00527348..57b0b66c 100644
--- a/htl/forward.c
+++ b/htl/forward.c
@@ -130,10 +130,6 @@ FORWARD (pthread_mutex_lock, (pthread_mutex_t *mutex), 
(mutex), 0)
 
 FORWARD (pthread_mutex_unlock, (pthread_mutex_t *mutex), (mutex), 0)
 
-
-FORWARD2 (pthread_self, pthread_t, (void), (), return 0)
-
-
 FORWARD (__pthread_setcancelstate, (int state, int *oldstate),
 (state, oldstate), 0)
 strong_alias (__pthread_setcancelstate, pthread_setcancelstate);
diff --git a/htl/pt-initialize.c b/htl/pt-initialize.c
index 02e6ad6b..fcad3b13 100644
--- a/htl/pt-initialize.c
+++ b/htl/pt-initialize.c
@@ -56,7 +56,6 @@ static const struct pthread_functions pthread_functions = {
   .ptr_pthread_mutex_lock = __pthread_mutex_lock,
   .ptr_pthread_mutex_trylock = __pthread_mutex_trylock,
   .ptr_pthread_mutex_unlock = __pthread_mutex_unlock,
-  .ptr_pthread_self = __pthread_self,
   .ptr___pthread_setcancelstate = __pthread_setcancelstate,
   .ptr_pthread_setcanceltype = __pthread_setcanceltype,
   .ptr___pthread_get_cleanup_stack = __pthread_get_cleanup_stack,
diff --git a/htl/pt-internal.h b/htl/pt-internal.h
index b787acf8..ade71b24 100644
--- a/htl/pt-internal.h
+++ b/htl/pt-internal.h
@@ -192,6 +192,7 @@ extern int __pthread_max_threads;
 extern struct __pthread *_pthread_self (void);
 #endif
 
+libc_hidden_proto (__pthread_self)
 /* Stores the stack of cleanup handlers for the thread.  */
 extern __thread struct __pthread_cancelation_handler *__pthread_cleanup_stack;
 
diff --git a/htl/pt-self.c b/htl/pt-self.c
index e05ec69b..dc37d5dc 100644
--- a/htl/pt-self.c
+++ b/htl/pt-self.c
@@ -17,7 +17,7 @@
.  */
 
 #include 
-
+#include 
 #include 
 
 /* Return the thread ID of the calling thread.  */
@@ -36,4 +36,8 @@ __pthread_self (void)
   return self->thread;
 }
 
-weak_alias (__pthread_self, pthread_self);
+libc_hidden_def (__pthread_self)
+versioned_symbol (libc, __pthread_self, pthread_self, GLIBC_2_37);
+#if OTHER_SHLIB_COMPAT (libpthread, GLIBC_2_12, GLIBC_2_37)
+compat_symbol (libc, __pthread_self, pthread_self, GLIBC_2_12);
+#endif
\ No newline at end of file
diff --git a/sysdeps/htl/pthread-functions.h b/sysdeps/htl/pthread-functions.h
index c8e5..2f0e3df0 100644
--- a/sysdeps/htl/pthread-functions.h
+++ b/sysdeps/htl/pthread-functions.h
@@ -56,7 +56,6 @@ int _pthread_mutex_init (pthread_mutex_t *,
 int __pthread_mutex_lock (pthread_mutex_t *);
 in

Re: [PATCH 0/3] htl: move __pthtread_total, ___pthread_self, pthread_self

[Guy-Fleury Iteriteka]

On January 3, 2023 7:22:20 PM GMT+02:00, Zack Weinberg  
wrote:
>
>> With this patch i boot up a hurd system with flavio scripts.
>
>Can we get a link to these scripts, please?  So we know why they care
>about these symbols being in libc.

https://github.com/flavioc/cross-hurd

We are trying to move htl(hurd pthread library) like it was done for linux nptl.

>
>zw

Re: On wiki and patches (was Re: Building Hurd)

[Guy-Fleury Iteriteka]

Hello

On January 25, 2023 9:48:35 AM GMT+02:00, Sergey Bugaev  
wrote:
>On Wed, Jan 25, 2023 at 4:10 AM Samuel Thibault  
>wrote:
>> Hello,
>
>Hi!
>
>> It'd be useful that all these small cross-compilation howtos here and
>> there be merged into the corresponding wiki page where it belongs,
>>
>> ./toolchain/cross-gnu.mdwn
>>
>> https://darnassus.sceen.net/~hurd-web/toolchain/cross-gnu/
>
>I must have already asked this before, but: how do I modify the wiki?
>Do I just send patches to bug-hurd? Is
I usually do that
>http://git.savannah.gnu.org/cgit/hurd/web.git the wiki's repo, or is
>it https://darnassus.sceen.net/cgit/hurd-web.git, or something else?
>
>Other than it apparently being Markdown, how do I run the wiki locally
>/ preview my changes? I do see there is a ./render_locally script,
>which calls an ikiwiki executable; is that it?
>
Yes
>Alternatively: I see there's an edit action, as in
>https://darnassus.sceen.net/cgi-bin/hurd-web?page=index&do=edit, which
>wants me to log in somehow ("Select your account provider").
>
I have seen some do that way
>What is the right way?
>
>Now, onto something else: I'm still waiting for any review/feedback on
>my glibc patches [0] (and now I see they lack Signed-off-by...) and
>the symlink rewrite [1]. I understand that you're busy (and so am I)
>and that Flavio's and Damien's work that you're merging is more
>important, so — just a gentle bump.
>
I don't think Samuel so. It might happen that  the patch need careful review 
when he have time but just forget after. Just ping if it takes a long time 
>[0]: https://sourceware.org/pipermail/libc-alpha/2022-December/143985.html
>[1]: https://mail.gnu.org/archive/html/bug-hurd/2021-06/msg00016.html
>
>By the way, I see my/our patches from summer 2021 (remember those
>vulnerabilities?) have been pushed; does that mean the copyright
>assignment has been completed and I can make larger contributions to
>the Hurd repo? I don't see any new letters from FSF.
>
Samuel might get the paper other than that he couldn't commit. 

He will answer more that I can
>Sergey
>

Re: [PATCH] faq/64-bit.mdwn: added up to date 64-bit porting info open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

[Guy-Fleury Iteriteka]

On May 13, 2023 6:38:15 PM GMT+02:00, "jbra...@dismail.de"  
wrote:
>---
> faq/64-bit.mdwn  | 11 ---
> open_issues/64-bit_port.mdwn |  6 +-
> 2 files changed, 5 insertions(+), 12 deletions(-)
>
>diff --git a/faq/64-bit.mdwn b/faq/64-bit.mdwn
>index 2e1278cb..36afbbc3 100644
>--- a/faq/64-bit.mdwn
>+++ b/faq/64-bit.mdwn
>@@ -13,11 +13,8 @@ License|/fdl]]."]]"""]]
> 
> [[!meta title="Is there a 64-bit version?"]]
> 
>-There are currently no plan for 64-bit userland for the short term, but there
>-are plans for 64-bit kernelland with 32-bit userland, which will notably 
>permit
>-to efficiently make use of more than 2 GiB memory and provide 4 GiB userland
>-addressing space. The kernel support was merged into GNU Mach, the currently
>-missing bit is the 32/64 mig translation for kernel RPCs.
>+Hurd developers are adding 64-bit support, and they plan to drop the
>+32-bit support, once the 64-bit support is deemed stable.  
I don't think anyone told the drop of 32 bit support
>+
>+
> 
>-That being said, you can always run a 32-bit version on a 64-bit machine, it
>-just works, processes are just limited to a couple GiB available memory.
>diff --git a/open_issues/64-bit_port.mdwn b/open_issues/64-bit_port.mdwn
>index 95761828..2cb77d90 100644
>--- a/open_issues/64-bit_port.mdwn
>+++ b/open_issues/64-bit_port.mdwn
>@@ -13,11 +13,7 @@ License|/fdl]]."]]"""]]
> 
> [[!inline pages="title(Is there a 64-bit version?)" feeds="no" raw="yes"]]
> 
>-**What is left for initial support (32-on-64) is**
>-
>-  * Fixing bugs :)
>-
>-**For pure 64bit support, we need to**
>+**For 64bit support, we need to**
> 
>   * Fix bugs :)
>   * bootstrap a distrib

Hello,

Re: [PATCH] faq/64-bit.mdwn: added up to date 64-bit porting info open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

[Guy-Fleury Iteriteka]

On May 15, 2023 4:38:34 PM GMT+02:00, "jbra...@dismail.de"  
wrote:
>---
>I explained that the Hurd has initial 64-bit support, but I 
>did not mention if the project plans to drop 32-bit
>support.  Joshua
>
> faq/64-bit.mdwn  | 10 +++---
> open_issues/64-bit_port.mdwn |  6 +-
> 2 files changed, 4 insertions(+), 12 deletions(-)
>
>diff --git a/faq/64-bit.mdwn b/faq/64-bit.mdwn
>index 2e1278cb..82513d25 100644
>--- a/faq/64-bit.mdwn
>+++ b/faq/64-bit.mdwn
>@@ -13,11 +13,7 @@ License|/fdl]]."]]"""]]
> 
> [[!meta title="Is there a 64-bit version?"]]
> 
>-There are currently no plan for 64-bit userland for the short term, but there
>-are plans for 64-bit kernelland with 32-bit userland, which will notably 
>permit
>-to efficiently make use of more than 2 GiB memory and provide 4 GiB userland
>-addressing space. The kernel support was merged into GNU Mach, the currently
>-missing bit is the 32/64 mig translation for kernel RPCs.
>+As of May 2023, the Hurd developers have a bootable 64-bit Debian
Are sure a debian hurd boot??
>+GNU/Hurd.  The 64 bit kernel and userspace is mostly working, but bugs
>+still need to be fixed.
> 
>-That being said, you can always run a 32-bit version on a 64-bit machine, it
>-just works, processes are just limited to a couple GiB available memory.
>diff --git a/open_issues/64-bit_port.mdwn b/open_issues/64-bit_port.mdwn
>index 95761828..ca30ba64 100644
>--- a/open_issues/64-bit_port.mdwn
>+++ b/open_issues/64-bit_port.mdwn
>@@ -13,11 +13,7 @@ License|/fdl]]."]]"""]]
> 
> [[!inline pages="title(Is there a 64-bit version?)" feeds="no" raw="yes"]]
> 
>-**What is left for initial support (32-on-64) is**
>-
>-  * Fixing bugs :)
>-
>-**For pure 64bit support, we need to**
>+**For 64-bit support, we need to**
> 
>   * Fix bugs :)
>   * bootstrap a distrib

Hi,

Re: [PATCH] faq/64-bit.mdwn: added up to date 64-bit porting info open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

[Guy-Fleury Iteriteka]

On May 15, 2023 5:58:12 PM GMT+02:00, Sergey Bugaev  wrote:
>On Mon, May 15, 2023 at 6:12 PM Guy-Fleury Iteriteka
> wrote:
>> On May 15, 2023 4:38:34 PM GMT+02:00, "jbra...@dismail.de" 
>>  wrote:
>> >+As of May 2023, the Hurd developers have a bootable 64-bit Debian
>> Are sure a debian hurd boot??
>
>I'm rather sure some patches required to get anything serious (e.g.
>ext2fs) booting and working still only exist on my tablet, so this
>must be talking about me.
>
>What I have here is not really a bootable Debian... it's a Frankenhurd
>made partly out of Samuel's debs, partly built myself. There's not
>much of a system, there are the Hurd servers, libraries, and /bin/sh
>(and some utilities I'm calling from it like uname). This is in many
>ways like booting Linux with init=/bin/sh, surely you wouldn't call
>that 'booting Debian'?

Yes, i know that. I fallow you on mastodon.
It should be interesting to use flavio's script.
Also as you are good in writing you can documents how you created and launch it 
 but when you finished your great work 
>
>A more correct description would be:
>
>Work on the x8_64 userland port started in Feb 2023 [note: I'm
>counting from my first x86_64 glibc patches, but surely there's been
>related work before, e.g. Flavio's MIG changes]. As of May 2023, the
>x86_64 port works well enough to start all the essential Hurd servers
>and run /bin/sh.
>
>(If you want more specific dates: I first got ld.so and libc.so
>building on March 11th, the bootstrap task first ran all the way to
>main on April 20th, and I got /bin/sh running on May12th).
>
>Sergey
>

Re: [PATCH] faq/64-bit.mdwn: added up to date 64-bit porting info open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

[Guy-Fleury Iteriteka]

On May 15, 2023 6:45:40 PM GMT+02:00, Samuel Thibault  
wrote:
>Guy-Fleury Iteriteka, le lun. 15 mai 2023 18:28:36 +0200, a ecrit:
>> It should be interesting to use flavio's script.
>
>I don't think Flavio aims to bootstrap various libraries and whatnot :)
>
I meant to test just the hurd core would be perhaps easy
>Samuel
>

Re: [PATCH] faq/64-bit.mdwn: added up to date 64-bit porting info open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

[Guy-Fleury Iteriteka]

On May 15, 2023 7:51:54 PM GMT+02:00, Sergey Bugaev  wrote:
>On Mon, May 15, 2023 at 7:28 PM Guy-Fleury Iteriteka
> wrote:
>> Yes, i know that. I fallow you on mastodon.
>
>Then you get to see all the shitposts :D
>
All posts yes :)
>> Also as you are good in writing you can documents how you created and launch 
>> it  but when you finished your great work
>
>Ah, :blush: thank you for your kind words... I don't think I'm that good,

I can tell you are really good especially with your analyse of code flow
>
>but I would surely love to write a blog post about the x86_64 port on
>the official blog, along with everyone else who's involved in the port
>(I'm certainly not the only one, and I don't mean to imply that I am).
>Let's maybe do this once the system can run a persistent writable
>store (= rumpdisk, not ramdisk) and nano? :)
Yeah that will be great
>
>Sergey

Re: Sample command output

[Guy-Fleury Iteriteka]

On May 17, 2023 7:49:24 PM GMT+02:00, Sergey Bugaev  wrote:
>Hello,
>
>now that /bin/sh is working, I'm playing with the system a bit, and
>thought it might be interesting to share some sample output from
>various commands (I only have the Hurd itself and partly binutils
>installed):
>
># uname -a
>GNU  0.9 GNU-Mach 1.8/Hurd-0.9 x86_64-AT386 GNU
>
># /bin/echo --version
>echo (GNU coreutils) 9.1
>Copyright (C) 2022 Free Software Foundation, Inc.
>License GPLv3+: GNU GPL version 3 or later .
>This is free software: you are free to change and redistribute it.
>There is NO WARRANTY, to the extent permitted by law.
>
>Written by Brian Fox and Chet Ramey.
>
># ls /dev
>MAKEDEV
>mach-console
>
># fsysopts /
>ext2fs --readonly --relatime --store-type=device rd0
>
># ls -l /lib
>total 12
>lrwxrwxrwx 1 0 0   25 May 11 16:04 ld-x86-64.so.1 -> x86_64-gnu/ld-x86-64.so.1
>drwxr-xr-x 3 0 0 4096 May 17 11:26 x86_64-gnu
>
># LD_TRACE_LOADED_OBJECTS=1 /hurd/ext2fs
>libdiskfs.so.0.3 => /lib/x86_64-gnu/libdiskfs.so.0.3 (0x01042000)
>libpager.so.0.3 => /lib/x86_64-gnu/libpager.so.0.3 (0x01079000)
>libstore.so.0.3 => /lib/x86_64-gnu/libstore.so.0.3 (0x01083000)
>libports.so.0.3 => /lib/x86_64-gnu/libports.so.0.3 (0x01096000)
>libihash.so.0.3 => /lib/x86_64-gnu/libihash.so.0.3 (0x010a1000)
>libshouldbeinlibc.so.0.3 =>
>/lib/x86_64-gnu/libshouldbeinlibc.so.0.3 (0x010a5000)
>libpthread.so.0.3 => /lib/x86_64-gnu/libpthread.so.0.3 (0x010b5000)
>libc.so.0.3 => /lib/x86_64-gnu/libc.so.0.3 (0x010cb000)
>libfshelp.so.0.3 => /lib/x86_64-gnu/libfshelp.so.0.3 (0x0136b000)
>libiohelp.so.0.3 => /lib/x86_64-gnu/libiohelp.so.0.3 (0x01374000)
>/lib/ld-x86-64.so.1 (0x1000)
>libmachuser.so.1 => /lib/x86_64-gnu/libmachuser.so.1 (0x01378000)
>libhurduser.so.0.3 => /lib/x86_64-gnu/libhurduser.so.0.3
>(0x0138e000)
>
>(I cannot run full ldd because that requires bash)
>
># env
>LD_ORIGIN_PATH=/usr/bin
>PWD=/
>
># tty
>not a ttty
>
>(this is the Mach console device via streamio, not the Hurd console translator)
>
># ps-hurd 1 2 3 4 6 7 8
>  PID TT STAT TIME COMMAND
>1  - 2  - 3  ? D4  ? 6  - 7  - 
>(ps-hurd crashes on PID 5 for some reason, to be investigated, also those ?s)
>
>Sergey
>

Hello,

That's great. Thanks very much!!

Re: [PATCH glibc] Stop checking if MiG supports retcode.

[Guy-Fleury Iteriteka]

On May 26, 2023 2:00:00 PM GMT+02:00, "Flávio Cruz"  
wrote:
>Hi Sergey
>
>On Fri, May 19, 2023 at 4:02 AM Sergey Bugaev  wrote:
>
>> Hi,
>>
>> On Fri, May 19, 2023 at 9:43 AM Flávio Cruz  wrote:
>> > I have made changes so that it does daily builds and I'm able to boot
>> small programs. However, I haven't had the time to boot programs built
>> against Glibc. How do you package and boot the static binaries using a
>> ramdisk? I've been reading the other threads about the Guix/rumpkernel so I
>> might be able to piece something together and try it this weekend.
>>
>> You just put the entirety of the root filesystem (containing /usr,
>> /bin, /lib, /hurd, and so on) as an ext2 image into a *file* that you
>> place onto the actual drive (a CD disk in my case), and then you ask
>> GRUB to load the file from the drive into memory, tell gnumach to make
>> a ramdisk device out of it (you'll need to apply [0]), and tell ext2fs
>> to use that device. Here's the relevant piece of my grub config
>> script:
>>
>> [0]:
>> https://salsa.debian.org/hurd-team/gnumach/-/blob/master/debian/patches/50_initrd.patch
>>
>> multiboot /boot/gnumach console=com0
>> module /boot/initrd.ext2 initrd.ext2 '$(ramdisk-create)'
>> module /sbin/ext2fs.static ext2fs
>> --multiboot-command-line='${kernel-command-line}' --readonly
>> --host-priv-port='${host-port}' --device-master-port='${device-port}'
>> --exec-server-task='${exec-task}' --kernel-task='${kernel-task}' -T
>> device rd0 '$(fs-task=task-create)' '$(prompt-task-resume)'
>> module /lib/ld.so.1 ld.so.1 /hurd/exec
>> --device-master-port='${device-port}' '$(exec-task=task-create)'
>> boot
>>
>> (I should probably change it to not hardcode 'rd0', but whatever).
>> Note that /boot/gnumach, /boot/initrd.ext2, /sbin/ext2fs.static, and
>> /lib/ld.so.1 are all paths inside the CD image (those are going to be
>> loaded by GRUB), and /boot/initrd.ext2 is the ext2 filesystem image
>> containing the actual Hurd root. /hurd/exec however is already a path
>> inside the fs image -- this is where ld.so (not grub) is going to load
>> the exec server from. The only static binary here is ext2fs.static,
>> the rest are all dynamically linked.
>>
>> Then in /libexec/console-run (inside the filesystem image), I have
>> written the following:
>>
>> #! /bin/sh
>>
>> settrans -ac /dev/mach-console /hurd/streamio console
>> exec <>/dev/mach-console >&0 2>&0
>> echo Hello from /bin/sh!
>> exec /bin/sh -i
>>
>> (If you're going to do the same, don't forget to create the
>> /dev/mach-console node beforehand, since the fs is read-only.) I also
>> had to patch streamio a little to do the \r -> \n conversion like
>> glibc already does in devstream:
>>
>> diff --git a/trans/streamio.c b/trans/streamio.c
>> index 272a002c..0af1aea3 100644
>> --- a/trans/streamio.c
>> +++ b/trans/streamio.c
>> @@ -500,6 +500,9 @@ trivfs_S_io_read (struct trivfs_protid *cred,
>>   cred->po->openmodes & O_NONBLOCK);
>>pthread_mutex_unlock (&global_lock);
>>*data_len = data_size;
>> +  for (size_t i = 0; i < data_size; i++)
>> +if ((*data)[i] == '\r')
>> +  (*data)[i] = '\n';
>>return err;
>>  }
>>
>> (maybe I should also add echoing of input characters in the same way,
>> which is also what glibc's devstream does -- otherwise currently I
>> don't see what I'm typing on the console).
>>
>> Make sure to use the very latest glibc (Samuel has already pushed all
>> of my patches upstream!) + the BRK_START hack.
>>
>
>Thanks for the instructions. I was able to make it work and pushed my
>changes to Github.
>
>For people that might want to try out the new port using
>https://github.com/flavioc/cross-hurd,
>the following will download the packages and build a disk image with the
>ram disk:
>
>$ export CPU=x86_64
>$ bash download.sh && bash bootstrap.sh && bash compile.sh && bash
>create-initrd.sh
>
>Then, to run qemu:
>
>$ bash start-qemu-debug.sh
>
Thanks. I wonder how i can run create.sh in docker. I use debian in docker on 
fedora 38.
>
>> Sergey
>>

Re: [PATCH glibc] Stop checking if MiG supports retcode.

[Guy-Fleury Iteriteka]

On May 27, 2023 8:42:27 AM GMT+02:00, "Flávio Cruz"  
wrote:
>On Fri, May 26, 2023 at 9:42 AM Guy-Fleury Iteriteka 
>wrote:
>
>> On May 26, 2023 2:00:00 PM GMT+02:00, "Flávio Cruz" 
>> wrote:
>> >Hi Sergey
>> >
>> >On Fri, May 19, 2023 at 4:02 AM Sergey Bugaev  wrote:
>> >
>> >> Hi,
>> >>
>> >> On Fri, May 19, 2023 at 9:43 AM Flávio Cruz 
>> wrote:
>> >> > I have made changes so that it does daily builds and I'm able to boot
>> >> small programs. However, I haven't had the time to boot programs built
>> >> against Glibc. How do you package and boot the static binaries using a
>> >> ramdisk? I've been reading the other threads about the Guix/rumpkernel
>> so I
>> >> might be able to piece something together and try it this weekend.
>> >>
>> >> You just put the entirety of the root filesystem (containing /usr,
>> >> /bin, /lib, /hurd, and so on) as an ext2 image into a *file* that you
>> >> place onto the actual drive (a CD disk in my case), and then you ask
>> >> GRUB to load the file from the drive into memory, tell gnumach to make
>> >> a ramdisk device out of it (you'll need to apply [0]), and tell ext2fs
>> >> to use that device. Here's the relevant piece of my grub config
>> >> script:
>> >>
>> >> [0]:
>> >>
>> https://salsa.debian.org/hurd-team/gnumach/-/blob/master/debian/patches/50_initrd.patch
>> >>
>> >> multiboot /boot/gnumach console=com0
>> >> module /boot/initrd.ext2 initrd.ext2 '$(ramdisk-create)'
>> >> module /sbin/ext2fs.static ext2fs
>> >> --multiboot-command-line='${kernel-command-line}' --readonly
>> >> --host-priv-port='${host-port}' --device-master-port='${device-port}'
>> >> --exec-server-task='${exec-task}' --kernel-task='${kernel-task}' -T
>> >> device rd0 '$(fs-task=task-create)' '$(prompt-task-resume)'
>> >> module /lib/ld.so.1 ld.so.1 /hurd/exec
>> >> --device-master-port='${device-port}' '$(exec-task=task-create)'
>> >> boot
>> >>
>> >> (I should probably change it to not hardcode 'rd0', but whatever).
>> >> Note that /boot/gnumach, /boot/initrd.ext2, /sbin/ext2fs.static, and
>> >> /lib/ld.so.1 are all paths inside the CD image (those are going to be
>> >> loaded by GRUB), and /boot/initrd.ext2 is the ext2 filesystem image
>> >> containing the actual Hurd root. /hurd/exec however is already a path
>> >> inside the fs image -- this is where ld.so (not grub) is going to load
>> >> the exec server from. The only static binary here is ext2fs.static,
>> >> the rest are all dynamically linked.
>> >>
>> >> Then in /libexec/console-run (inside the filesystem image), I have
>> >> written the following:
>> >>
>> >> #! /bin/sh
>> >>
>> >> settrans -ac /dev/mach-console /hurd/streamio console
>> >> exec <>/dev/mach-console >&0 2>&0
>> >> echo Hello from /bin/sh!
>> >> exec /bin/sh -i
>> >>
>> >> (If you're going to do the same, don't forget to create the
>> >> /dev/mach-console node beforehand, since the fs is read-only.) I also
>> >> had to patch streamio a little to do the \r -> \n conversion like
>> >> glibc already does in devstream:
>> >>
>> >> diff --git a/trans/streamio.c b/trans/streamio.c
>> >> index 272a002c..0af1aea3 100644
>> >> --- a/trans/streamio.c
>> >> +++ b/trans/streamio.c
>> >> @@ -500,6 +500,9 @@ trivfs_S_io_read (struct trivfs_protid *cred,
>> >>   cred->po->openmodes & O_NONBLOCK);
>> >>pthread_mutex_unlock (&global_lock);
>> >>*data_len = data_size;
>> >> +  for (size_t i = 0; i < data_size; i++)
>> >> +if ((*data)[i] == '\r')
>> >> +  (*data)[i] = '\n';
>> >>return err;
>> >>  }
>> >>
>> >> (maybe I should also add echoing of input characters in the same way,
>> >> which is also what glibc's devstream does -- otherwise currently I
>> >> don't see what I'm typing on the console).
>> >>
>> >> Make sure to use the very latest glibc (Samuel has already pushed all
>> >> of my patches upstream!) + the BRK_START hack.
>> >>
>> >
>> >Thanks for the instructions. I was able to make it work and pushed my
>> >changes to Github.
>> >
>> >For people that might want to try out the new port using
>> >https://github.com/flavioc/cross-hurd,
>> >the following will download the packages and build a disk image with the
>> >ram disk:
>> >
>> >$ export CPU=x86_64
>> >$ bash download.sh && bash bootstrap.sh && bash compile.sh && bash
>> >create-initrd.sh
>> >
>> >Then, to run qemu:
>> >
>> >$ bash start-qemu-debug.sh
>> >
>> Thanks. I wonder how i can run create.sh in docker. I use debian in docker
>> on fedora 38.
>>
>
>I think one blocker is to be able to use loopback devices inside the
>container
>which is not supported unless the container is run with the SYS_ADMIN
>capability.
>That's usually not recommended since it gives "root" access to the host. I
>think there
>might be a way to build the ramdisk without using any of the loopback/mount
>machinery (maybe with genext2fs?) but never tried to use that before.
>
>
Thanks i was able to make it work. I will install qemu and play with it
>
>> >
>> >> Sergey
>> >>
>>
>>

Re: [PATCH rumpkernel] prune.sh: Remove ~1.1G of currently unused bits.

[Guy-Fleury Iteriteka]

On June 19, 2023 10:00:32 PM GMT+02:00, Janneke Nieuwenhuizen  
wrote:
>Hi!
>
>The rumpkernel archive is ridiculously large.  It manages to grow so big
>mainly by adopting the evil practice of bundling other packages.  The
>archive contains copies of many GNU utilities, a copy of llvm, and even
>a copy of postfix.
>
>The archive can most probably be pruned a lot further without
>consequences, but this is a helpful start.  I'm built the Guix
>rumpkernel using this pruned archive and it works fine.  The same list
>of librump* libraries are built and there are no messages in the build
>log that suggest things are missing.
>
And how about the size of runtime binary?
>Because the patches are so big I'm only sharing the prune.sh script that
>will create some 'prune: ...' commits.
>
>Greetings,
>Janneke
>

Hi,

Re: [PATCH hurd] rumpdisk: Include complete USB stack to enable mass storage driver

[Guy-Fleury Iteriteka]

On June 25, 2023 2:35:51 PM GMT+02:00, Damien Zammit  
wrote:
>This simple change allows hurd to be bootable off usb!

A running hurd can then recognize a usb storage
>
>It is not ideal to have entire usb stack with the mass storage driver
>and combined with SATA, but there is no easy way to separate
>the usb stack into host/device yet.  This centralises all the disk
>support, (and unfortunately also all the usb support).
>
>Caveats: USB seems to share IRQs with network device,
>which does not seem to work well currently.
>I am not sure of the status of irq sharing but it seems broken.
>---
> rumpdisk/Makefile | 2 +-
> rumpdisk/block-rump.c | 3 ++-
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
>diff --git a/rumpdisk/Makefile b/rumpdisk/Makefile
>index b59aaf9a..9ee8a1d3 100644
>--- a/rumpdisk/Makefile
>+++ b/rumpdisk/Makefile
>@@ -15,7 +15,7 @@
> #   along with this program; if not, write to the Free Software
> #   Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> 
>-RUMPLIBS=rump rumpuser rumpdev rumpdev_disk rumpdev_pci rumpvfs 
>rumpdev_ahcisata rumpdev_piixide rumpdev_ata
>+RUMPLIBS=rump rumpuser rumpdev rumpdev_disk rumpdev_pci rumpvfs 
>rumpdev_ahcisata rumpdev_piixide rumpdev_ata rumpdev_usb rumpdev_pci_usbhc 
>rumpdev_umass
> RUMPEXTRA=rumpdev_scsipi
> 
> # If we have a configured tree, include the configuration so that we
>diff --git a/rumpdisk/block-rump.c b/rumpdisk/block-rump.c
>index 5ceb14ae..0a8cbe44 100644
>--- a/rumpdisk/block-rump.c
>+++ b/rumpdisk/block-rump.c
>@@ -46,7 +46,7 @@
> #define BLKRRPART  0x125F /* re-read partition table */
> 
> #define DISK_NAME_LEN 32
>-#define MAX_DISK_DEV 2
>+#define MAX_DISK_DEV 3
> 
> static bool disabled;
> 
>@@ -108,6 +108,7 @@ is_disk_device (const char *name)
>   const char *dev;
>   const char *allowed_devs[MAX_DISK_DEV] = {
> "wd",
>+"sd",
> "cd"
>   };
>   uint8_t i;

Hello,

Fix itinerate struct beep array

[guy fleury iteriteka]

Hello,

http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/console-client/generic-speaker.c#n417

for (i = 0; i < sizeof (*beep); i++)
should be:
for (i = 0; i < (sizeof(beep) / sizeof (*beep)); i++)

I don't have a hurd vm right now to send patch.

Fix vm_map_msync

[guy fleury iteriteka]

hello hurd,

See if this patch is good!
thanks.
From c13cb7a92c1b6d3be590950b075b5cb7104132b6 Mon Sep 17 00:00:00 2001
From: guy fleury iteriteka 
Date: Fri, 30 Aug 2019 18:52:33 +0200
Subject: [PATCH] Fix vm_map_msync:Force return KERN_INVALID_ARGUMENT and fix
 sync_flags flags check.

* vm/vm_map.c(vm_map_msync): Force to return when map == VM_MAP_NULL and
  sync_flags == VM_SYNC_ASYNCHRONOUS | VM_SYNC_SYNCHRONOUS.
* vm/vm_map.c(vm_map_msync): remove unnecesary check of sync_flags.
---
 vm/vm_map.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/vm/vm_map.c b/vm/vm_map.c
index aadaec1..37dd070 100644
--- a/vm/vm_map.c
+++ b/vm/vm_map.c
@@ -4880,12 +4880,11 @@ kern_return_t vm_map_msync(
 	vm_size_t	size,
 	vm_sync_t	sync_flags)
 {
-	if (map == VM_MAP_NULL)
-		KERN_INVALID_ARGUMENT;
-
-	if (sync_flags & (VM_SYNC_ASYNCHRONOUS | VM_SYNC_SYNCHRONOUS) ==
-			 (VM_SYNC_ASYNCHRONOUS | VM_SYNC_SYNCHRONOUS))
-		KERN_INVALID_ARGUMENT;
+if (map == VM_MAP_NULL)
+	  return KERN_INVALID_ARGUMENT;
+	
+	if (sync_flags & (VM_SYNC_ASYNCHRONOUS | VM_SYNC_SYNCHRONOUS))
+	  return KERN_INVALID_ARGUMENT;
 
 	size =	round_page(address + size) - trunc_page(address);
 	address = trunc_page(address);
-- 
2.22.0

Re: Fix vm_map_msync

[guy fleury iteriteka]

Le ven. 30 août 2019 à 19:53, Samuel Thibault  a
écrit :

> Hello,
>
> guy fleury iteriteka, le ven. 30 août 2019 19:15:33 +0200, a ecrit:
> > See if this patch is good!
>
> I don't understand why it should be needed?
>
> > - if (map == VM_MAP_NULL)
> > - KERN_INVALID_ARGUMENT;
> > +if (map == VM_MAP_NULL)
> > +   return KERN_INVALID_ARGUMENT;
>
> Please be simpler in the change log, at first sight I didn't understand
> what you wanted to do.  Here, simply use "add missing return keyword".
>
> Change logs have two parts: the rational, then the changes. Don't
> confuse both, we really need them both for different reasons. Here the
> rationale is what you sid: fix returning KERN_INVALID_ARGUMENT when the
> map is NULL. And the changes is adding the return keyword.
>

Done!

>
> > - if (sync_flags & (VM_SYNC_ASYNCHRONOUS | VM_SYNC_SYNCHRONOUS) ==
> > -  (VM_SYNC_ASYNCHRONOUS | VM_SYNC_SYNCHRONOUS))
> > - KERN_INVALID_ARGUMENT;
> > +
> > + if (sync_flags & (VM_SYNC_ASYNCHRONOUS | VM_SYNC_SYNCHRONOUS))
> > +   return KERN_INVALID_ARGUMENT;
>
> This is not the same, and not what we want.  What we want is to exclude
> having both flags.
>
>
Samuel
>
>
From 470af6c03c41041cd820617392fc15b03606e6bd Mon Sep 17 00:00:00 2001
From: guy fleury iteriteka 
Date: Fri, 30 Aug 2019 20:36:14 +0200
Subject: [PATCH] fix return KERN_INVALID_ARGUMENT when the map is NULL.

* vm/vm_map.c(vm_map_msync): Add missing return keyword.
---
 vm/vm_map.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/vm/vm_map.c b/vm/vm_map.c
index aadaec1..98709df 100644
--- a/vm/vm_map.c
+++ b/vm/vm_map.c
@@ -4881,11 +4881,11 @@ kern_return_t vm_map_msync(
 	vm_sync_t	sync_flags)
 {
 	if (map == VM_MAP_NULL)
-		KERN_INVALID_ARGUMENT;
+	  return KERN_INVALID_ARGUMENT;
 
 	if (sync_flags & (VM_SYNC_ASYNCHRONOUS | VM_SYNC_SYNCHRONOUS) ==
 			 (VM_SYNC_ASYNCHRONOUS | VM_SYNC_SYNCHRONOUS))
-		KERN_INVALID_ARGUMENT;
+	  return KERN_INVALID_ARGUMENT;
 
 	size =	round_page(address + size) - trunc_page(address);
 	address = trunc_page(address);
-- 
2.22.0

patch

[guy fleury iteriteka]

hello,

see attached files!
From 37644d852d546aa8782b49471bf2295d3441c041 Mon Sep 17 00:00:00 2001
From: guy fleury iteriteka 
Date: Sat, 31 Aug 2019 14:42:06 +0200
Subject: [PATCH] Fix the pointer comparison of different type.

* vm/vm_map.c(vm_map_fork): use VM_MAP_NULL instead of PMAP_NULL when compare
  with new_map.
---
 vm/vm_map.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/vm/vm_map.c b/vm/vm_map.c
index 98709df..7982921 100644
--- a/vm/vm_map.c
+++ b/vm/vm_map.c
@@ -4247,7 +4247,7 @@ vm_map_t vm_map_fork(vm_map_t old_map)
 	new_map = vm_map_create(new_pmap,
 			old_map->min_offset,
 			old_map->max_offset);
-	if (new_map == PMAP_NULL) {
+	if (new_map == VM_MAP_NULL) {
 		pmap_destroy(new_pmap);
 		return VM_MAP_NULL;
 	}
-- 
2.22.0

From 85b57ba0f1d30048a044b43a7962c0b8fe381331 Mon Sep 17 00:00:00 2001
From: guy fleury iteriteka 
Date: Sat, 31 Aug 2019 16:04:53 +0200
Subject: [PATCH] satisfy 'werror=parantheses'.

* vm/vm_map.c(vm_map_msync): explit group of first condition.
---
 vm/vm_map.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/vm/vm_map.c b/vm/vm_map.c
index 7982921..a9b1429 100644
--- a/vm/vm_map.c
+++ b/vm/vm_map.c
@@ -4883,7 +4883,7 @@ kern_return_t vm_map_msync(
 	if (map == VM_MAP_NULL)
 	  return KERN_INVALID_ARGUMENT;
 
-	if (sync_flags & (VM_SYNC_ASYNCHRONOUS | VM_SYNC_SYNCHRONOUS) ==
+	if ((sync_flags & (VM_SYNC_ASYNCHRONOUS | VM_SYNC_SYNCHRONOUS)) ==
 			 (VM_SYNC_ASYNCHRONOUS | VM_SYNC_SYNCHRONOUS))
 	  return KERN_INVALID_ARGUMENT;
 
-- 
2.22.0

[bug #23213] moving a directory in a non-root-filesystem chroot returns EAGAIN

[guy fleury iteriteka]

Follow-up Comment #2, bug #23213 (project hurd):

hello,

on latest debian image 2020, it seems to be fixed.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #16075] pthread_setcancelstate() makes pthread_join() crash

[guy fleury iteriteka]

Follow-up Comment #3, bug #16075 (project hurd):

This was fixed!

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

Re: 64bit startup

[Guy-Fleury Iteriteka]

On August 14, 2023 10:48:57 PM GMT+02:00, Samuel Thibault 
 wrote:
>Samuel Thibault, le sam. 12 août 2023 17:37:06 +0200, a ecrit:
>> BTW, git is now available and seems to be working fine, I could clone
>> the upstream glibc repository for instance.
>
>I had a lot of troubles building glibc. We had a nasty bug in
>pmap_remove and pmap_protect which were bringing mayhem, now fixed,
>things now work *WAY* better :D
>
Thats great,thanks. On irc you mention building python too cause many problems. 
 Today i am going to search a good computer so that i learn programming in hurd
>Samuel
>

Hello,

Re: 64bit startup

[Guy-Fleury Iteriteka]

On August 15, 2023 4:11:08 PM GMT+02:00, jbra...@dismail.de wrote:
>August 15, 2023 12:36 AM, "Guy-Fleury Iteriteka"  wrote:
>
>> On August 14, 2023 10:48:57 PM GMT+02:00, Samuel Thibault 
>>  wrote:
>> 
>>> Samuel Thibault, le sam. 12 août 2023 17:37:06 +0200, a ecrit:
>> 
>> Thats great,thanks. On irc you mention building python too cause many 
>> problems. Today i am going to
>> search a good computer so that i learn programming in hurd
>>> Samuel
>> 
>
>I've got the Hurd running pretty well on a T43.   But that is only a 32-bit 
>single core machine.
>
>It also runs really well in qemu.  Many Hurd developers run the Hurd in qemu.  
>:)

I know that Yes. My current compter have an issue where some key are not 
working so it's not pratical for programming. 
>

Re: Rust support on its way!

[Guy-Fleury Iteriteka]

On August 30, 2023 1:42:30 AM GMT+02:00, Samuel Thibault 
 wrote:
>Hello,
>
>Thanks to Vedant's GSoC work, we have patches submited to upstream Rust
>to support Rust on GNU/Hurd!
>
Can tou plz share the link of the pull request . I can't find on rust github 
repo

>The building process is relatively tricky, I have put some notes at the
>end of:
>
>https://darnassus.sceen.net/~hurd-web/community/gsoc/project_ideas/rust/
>
>The availability of Debian packages will be for later: they are for now
>still at an older rust version, we'll probably want to just wait for
>that to catch up with upstream rather than re-work on the porting.
>
>Samuel
>

Hello,

Congrats all for your hard work.

Re: stuck building hurd

[Guy-Fleury Iteriteka]

On September 5, 2023 12:00:00 PM GMT+02:00, Samuel Thibault 
 wrote:
>gfle...@disroot.org, le mar. 05 sept. 2023 11:00:15 +0200, a ecrit:
>> make[1]: ***  Aucune règle pour fabriquer la cible « thread_state.h »,
>> nécessaire pour « mgt.o ». Arrêt
>
>That's probably due to glibc's 9736920963258a90c69e60fb8896ce3e70d18d3e.
>I have probably fixed it in 4be913652ca115160bae1daf560170ef8b112ccb.
Thanks, it is fixed
>
>Samuel
>

Re: [PATCH] Updated the emacs open issues page.

[Guy-Fleury Iteriteka]

On September 4, 2023 9:50:34 AM GMT+02:00, Samuel Thibault 
 wrote:
>Po Lu, le lun. 04 sept. 2023 08:53:21 +0800, a ecrit:
>> Incidentally, where are the Debian hurd-amd64 images that are always in
>> earshot but never in sight?
>
>?
>
>«
>If people want to play with it, I have updated the image on
>
>https://people.debian.org/~sthibault/hurd-i386/initrd-amd64.img.gz
>»
And how you launch this one. I get: no bootable module 

>
>Samuel
>

Re: Hurd Christmas Party

[Guy-Fleury Iteriteka]

On December 18, 2023 6:49:56 PM GMT+02:00, Sergey Bugaev  
wrote:
>Hello,
>
>On Mon, Dec 18, 2023, 00:56  wrote:
>> Hello you lovely people!
>>
>> Wanna have a Hurd Christmas party this year?
>
>Yes please! This is a great idea!
>
>> I am an FSF member, and I have a jitsi account with them. Ravin knows how 
>> well jitsi works! We could talk about the cool things that the Hurd has 
>> done, bcachefs, Sergey's ServerbootV2 (working name), Damien's SMP work, 
>> Flavio's MIG improvements, the 64-bit port, etc.
>
>... and it will be the perfect venue for me to announce a certain
>something, another Hurd-related project that I have been hacking on
>for the last few weeks :)

That's great.

I  won't be there bcp my english is not that good especially talk. So I you 
guys record and post somewhere  I'll be nice

>
>(And that one, I do need a name for, so I was hoping you'd help me
>with that. So get your imagination ready :)
>
>> I am thinking we should do it on a Saturday.
>
>Saturday being Dec 23rd?
>
>> Maybe 9AM EST or 11AM EST, which would let our European friends join in.
>
>Yes, that should work for me.
>
>Sergey
>

Hello,

Re: aarch64-gnu (and Happy New Year!)

[Guy-Fleury Iteriteka]

On December 31, 2023 9:53:26 PM GMT+02:00, Sergey Bugaev  
wrote:
>Hello, and happy holidays!
>
>Every now and then, I hear someone mention potential ports of gnumach
>to new architectures. I think I have heard RISC-V and (64-bit?) ARM
>mentioned somewhere recently as potential new port targets. Being
>involved in the x86_64 port last spring was a really fun and
>interesting experience, and I learned a lot; so I, for one, have
>always thought doing more ports would be a great idea, and that I
>would be glad to be a part of such an effort again.
>
>Among the architectures, AArch64 and RISC-V indeed seem most
>attractive (not that I know much about either). Among those two,
>RISC-V is certainly newer and more exciting, but Aarch64 is certainly
>more widespread and established. (Wouldn't it be super cool if we
>could run GNU/Hurd everywhere from tiny ARM boards, to Raspberry Pi's,
>to common smartphones, to, now, ARM-based laptops desktops?) Also I
>have had some experience with ARM in the past, so I knew a tiny bit of
>ARM assembly.
>
>So I thought, what would it take to port the Hurd to AArch64, a
>completely non-x86 architecture, one that I knew very little about?
>There is no AArch64 gnumach (that I know of) yet, but I could try to
>hack on glibc even without one, I'd only need some headers, right?
>There's also no compiler toolchain, but those patches to add the
>x86_64-gnu target looked pretty understandable, so — how hard could it
>be?
>
>Well, I did more than think about it :)
>
>I read up on AArch64 registers / assembly / architecture / calling
>convention, added the aarch64-gnu target to binutils and GCC, added
>basic versions of mach/aarch64/ headers to gnumach (but no actual
>code), and made a mostly complete port of glibc. I haven't spent much
>effort on Hurd proper, but I have tried running the build, and the
>core Hurd servers (ext2fs, proc, exec, auth) do get built.
>
>I will be posting the patches soon. For now, here's just a little teaser:
>
>glibc/build $ file libc.so elf/ld.so
>libc.so: ELF 64-bit LSB shared object, ARM aarch64, version 1
>(GNU/Linux), dynamically linked, interpreter /lib/ld-aarch64.so.1, for
>GNU/Hurd 0.0.0, with debug_info, not stripped
>elf/ld.so: ELF 64-bit LSB shared object, ARM aarch64, version 1
>(SYSV), dynamically linked, with debug_info, not stripped
>
>hurd/build $ file ext2fs/ext2fs.static proc/proc
>ext2fs/ext2fs.static: ELF 64-bit LSB executable, ARM aarch64, version
>1 (GNU/Linux), statically linked, for GNU/Hurd 0.0.0, with debug_info,
>not stripped
>proc/proc: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV),
>dynamically linked, interpreter /lib/ld-aarch64.so.1, for GNU/Hurd
>0.0.0, with debug_info, not stripped
>
>glibc/build $ aarch64-gnu-objdump --disassemble=__mig_get_reply_port libc.so
>libc.so: file format elf64-littleaarch64
>Disassembly of section .plt:
>Disassembly of section .text:
>0002b8e0 <__mig_get_reply_port>:
>   2b8e0: a9be7bfd stp x29, x30, [sp, #-32]!
>   2b8e4: 910003fd mov x29, sp
>   2b8e8: f9000bf3 str x19, [sp, #16]
>   2b8ec: d53bd053 mrs x19, tpidr_el0
>   2b8f0: b85f8260 ldur w0, [x19, #-8]
>   2b8f4: 3480 cbz w0, 2b904 <__mig_get_reply_port+0x24>
>   2b8f8: f9400bf3 ldr x19, [sp, #16]
>   2b8fc: a8c27bfd ldp x29, x30, [sp], #32
>   2b900: d65f03c0 ret
>   2b904: 97fffbef bl 2a8c0 <__mach_reply_port>
>   2b908: b81f8260 stur w0, [x19, #-8]
>   2b90c: f9400bf3 ldr x19, [sp, #16]
>   2b910: a8c27bfd ldp x29, x30, [sp], #32
>   2b914: d65f03c0 ret
>
>So it compiles and links, but does it work? — well, we can't know
>that, not until someone ports gnumach, right?
>
>Well actually we can :) I've done the same thing as last time, when
>working on the x86_64 port: run a statically linked hello world
>executable on Linux, under GDB, carefully skipping over and emulating
>syscalls and RPCs. This did uncover a number of bugs, both in my port
>of glibc and in how the toolchain was set up (the first issue was that
>static-init.S was not even getting linked in, the second issue was
>that static-init.S was crashing even prior to the _hurd_stack_setup
>call, and so on). But, I fixed all of those, and got the test
>executable working! — as in, successfully running all the glibc
>initialization (no small feat; this includes TLS setup, hwcaps /
>cpu-features, and ifuncs), reaching main (), successfully doing puts
>(), and shutting down. So it totally works, and is only missing an
>AArch64 gnumach to run on.
>
>The really unexpected part is how easy this actually was: it took me
>like 3 days from "ok, guess I'm doing this, let's add a new target to
>binutils and gcc" to glibc building successfully, and a couple more
>days to get hello world to work (single-stepping under GDB is just
>that time-consuming). Either I'm getting good at this..., or (perhaps
>more realistically) maybe it was just easy all along, and it was my
>inexperience with glibc internals that slowed me down the last time.
>Also, we have worked out a lot of 6

Re: 64bit support news

[Guy-Fleury Iteriteka]

On August 25, 2024 6:02:02 PM GMT+02:00, Samuel Thibault 
 wrote:
>Samuel Thibault, le dim. 25 août 2024 17:50:51 +0200, a ecrit:
>> An amd64 installer cd image is available on
>> 
>> https://people.debian.org/~sthibault/hurd-amd64/installer/cdimage/daily/
>
>I have also put it on
>http://cdimage.debian.org/cdimage/ports/latest/hurd-amd64/current/
>
>where it won't be overwritten by newer daily images.
>
>Samuel
>

Hello, thanks your hard work. I will give a try soon

Re: static tar-1.34 hanging on warning/error [WAS: SOLVED [cross] building gdb for the 64bit Hurd?]

[Guy-Fleury Iteriteka]

On November 16, 2024 10:13:22 PM GMT+02:00, Samuel Thibault 
 wrote:
>jann...@gnu.org, le sam. 16 nov. 2024 20:47:40 +0100, a ecrit:
>> Samuel Thibault writes:
>> 
>> > jann...@gnu.org, le sam. 16 nov. 2024 17:33:08 +0100, a ecrit:
>> 
>> >> Okay, so Guix hasn't been using
>> >> 
>> >> 
>> >> 
>> >> which didn't seem to be a problem before / with 32bit.
>> >
>> > I'm surprised it wouldn't be a problem on 32bit too.
>> 
>> Hmm...while our bootstrap-glibc was updated 20200326, the static
>> binaries are from 20200326.  We were using glibc-2.31 at that time.
>
>Ok, so the ptf issue wasn't there.
>
>> > We can probably prioritize moving the __pthread_setcancelstate function
>> > from htl to glibc, so this patch gets not needed any more.
>> 
>> That would be nice.
>
>Guy, could you make it a priority in your symbol list?

No problem. I will do that.
>
>> >> Meanwhile, I found another hang in bash when it calls WAITPID.
>> >
>> > That doesn't ring a bell either. Where does it hang exactly?
>> 
>> Found it: in bash's redir.c.  During [cross-]compilitation,
>> builtins/pipesise.h:
>> 
>> --8<---cut here---start->8---
>> /*
>>  * pipesize.h
>>  *
>>  * This file is automatically generated by psize.sh
>>  * Do not edit!
>>  */
>> 
>> #define PIPESIZE 65536
>> --8<---cut here---end--->8---
>
>Ah, you are cross-building. I did encounter this one while bootstrapping
>debian hurd-amd64 indeed, but got very different symptoms.
>
>> Using a hack during cross-build to use 16384 fixes the problem.  I'm
>> wondering why this never came up on the 32bit Hurd, does that match the
>> Linux pipe size (65536)?
>
>No, not either.
>
>> If so should this issue still be reported to bash upstream,
>
>The problem is that it's not really solvable: this can only be detected
>at run time. We could however ask to downgrade it to 16384 (or even 4096
>to be safe).
>
>> or will the 64bit Hurd also match Linux pipe size in the
>> future?
>
>We could increase it but sooner or later Linux would increase it and
>bash possibly follow. Better just make bash take a safe default.
>
>Samuel
>

Hello,

Re: Confirm some entries in TODO list

[Guy-Fleury Iteriteka]

Le 19 décembre 2024 04:32:11 GMT+02:00, Zhaoming Luo  a 
écrit :
>Hi,
>
>I would like to try to do some contributions so I search in the TODO list on 
>the website. I would like to try the followings, but before think I should 
>confirm if any of them is completed or someone is working on:
>
>- Fix the git testsuite (just a few tests failing, used to pass).
>- Fix the subversion testsuite (just a few tests failing).
>- Port dhcpcd, see call for help
With this one you can ask Joan Lledó, he has done some work about it.
>- Fix the vim testsuite (just a few tests failing, used to pass).
>- Fix building mesa.
>
>It seems the one about vim has been completed as vim has been built 
>successfully on debian auto builder[1].
>
>I'm also quite interested in this one:
>- Extensively test (e.g. running testsuites of glibc, perl, curl, rust-mio) 
Perl has been fixed but you Can always check
and fix the lwip-based TCP/IP stack, to be sure we don't get regressions by 
switching to it.
>But I need a bit more detail about how to set up the test environment for 
>testing lwip.
>
>If you are doing or have completed any of them please leave a message so I can 
>get some up-to-date information:).
>
>[0]: https://darnassus.sceen.net/~hurd-web/contributing/
>[1]: https://buildd.debian.org/status/package.php?p=vim&suite=sid
>
>Best,

Hi