Merge branch 'master' of flubber:~hurd-web/hurd-web

7 files changed, 295 insertions, 22 deletions

diff --git a/hurd/faq/which_microkernel.mdwn b/hurd/faq/which_microkernel.mdwn
index 10fd31b1..c5026afa 100644
--- a/hurd/faq/which_microkernel.mdwn
+++ b/hurd/faq/which_microkernel.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2009, 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
@@ -8,7 +8,7 @@ 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="What happened to the L4/Coyotos/viengoos micro-kernels?"]]
+[[!meta title="What happened to the L4 / Coyotos / Viengoos microkernels?"]]
 
 L4 was promising but happened to not be suitable for implementing a general-purpose operating system on top of it. See [[history/port_to_l4]] for the historical details.
 
@@ -17,3 +17,65 @@ Coyotos is abandoned upstream
 Neal Walfield started working on a newly designed kernel called [[viengoos|microkernel/viengoos]]. Unfortunately, he currently lacks time and the projects it paused.
 
 In the meanwhile, people are thus continuing with [[microkernel/mach]].
+
+---
+
+IRC, #hurd, 2011-01-12.
+
+[[!taglink open_issue_documentation]]
+
+    <Pete-J> Hello i am just curious of the development of Hurd - what's the
+      current mission on the microkernel i see projects like l4 and viengoos,
+      will one of these projects replace Mach? or will you stick with Mach
+    <Pete-J> as i understand is that Mach is a first generation microkernel
+      that's very old in design and causes alot of issues
+    <Pete-J> that's where l4 and viengoos comes in - they are trying to be the
+      next generation Mach - am i correct?
+    <neal> l4 is not a drop in replacement for Mach
+    <neal> it doesn't actually do much resource management
+    <neal> for instance, you still have to implement a memory manager
+    <neal> this is where several issues are with Mach
+    <neal> l4 doesn't address those issues; it punts to the operating system
+    <Pete-J> and what about viengoos?
+    <neal> it's unfinished
+    <neal> and it implemented some untested ideas
+    <neal> i.e., parts of viengoos were research
+    <neal> there has not been a sufficient evaluation of those ideas to
+      determine whether they are a good approach
+    <Pete-J> meaning that viengoos is a research kernel that could aid Mach?
+    <neal> I'm not sure I understand your question
+    <Pete-J> Well is viengoos trying to be a replacement for Mach, or will
+      viengoos be an experiment of new ideas that could be implemented in Mach?
+    <Pete-J> i am sorry for my limited english
+    <neal> viengoos was designed with a Hurd-like user-land in mind
+    <neal> in that sense it was a Mach replacement
+    <neal> (unlike L4)
+    <neal> viengoos consisted of a few experiments
+    <neal> one could implement them in mach
+    <neal> but it would require exposing new interfaces
+    <neal> in which case, I'm not sure you could call the result Mach
+    <Pete-J> Well as i understand you develop two microkernels side by side,
+      wouldnt it be more effective to investigate viengoos more and maybe move
+      the focus to viengoos?
+    <antrik> no
+    <antrik> having something working all the time is crucial
+    <antrik> it's very hard to motivate people to work on a project that might
+      be useful, in a couple of years, perhaps...
+    <Pete-J> Well Mach is meant to be replaced one day - i see no reason to
+      keep on developing it just because it works at this moment
+    <Pete-J> *if Mach is meant to be replaced
+    <antrik> it's not at all clear that it will be replaced by something
+      completely different. I for my part believe that modifying the existing
+      Mach is a more promising approach
+    <Pete-J> as i understand man power is something you need - and by spreading
+      out the developers just makes the progress more slow
+    <antrik> but even if it *were* to be replaced one day, it doesn't change
+      the fact that we need it *now*
+    <antrik> all software will be obsolete one day. doesn't mean it's not worth
+      working on
+    <antrik> the vast majority of work is not on the microkernel anyways, but
+      on the system running on top of it
+    <Pete-J> ahh i see
+    <antrik> manpower is not something that comes from nowhere. again, having
+      something working is crucial in a volunteer project like this
+    <antrik> there are no fixed plans
diff --git a/mailing_lists.mdwn b/mailing_lists.mdwn
index e4bd1368..f89a6e72 100644
--- a/mailing_lists.mdwn
+++ b/mailing_lists.mdwn
@@ -1,13 +1,14 @@
-[[!meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008
-Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008,
+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]]."]]"""]]
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
 
 # On Posting
 
@@ -30,21 +31,20 @@ Also see these general notes about [[community/communication]].
 
 # Main Lists
 
-The lists are [[unmoderated]] and most of them are hosted on
-<http://lists.gnu.org/>.  Try to post to the appropriate mailing list.
+Most of these lists are [[unmoderated]], and most of them are hosted on
+<http://lists.gnu.org/>.
 
 Some of the Hurd user groups listed on [[community]] also host additional
 mailing lists.
 
-<!-- TODO.  Need some real ikiwiki way of adding such anchors.  -->
-
 <a name="bug-hurd"></a>
 ## bug-hurd
 
 <bug-hurd@gnu.org>  
 <http://lists.gnu.org/mailman/listinfo/bug-hurd>
 
-Technical discussion and bug reports; main development list. If you want to **contribute**, please meet us here. 
+Technical discussion and bug reports; main development list. If you want to
+[[*contribute*|contributing]], please meet us here.
 
 <a name="hurd-devel"></a>
 ## hurd-devel
@@ -59,8 +59,8 @@ Subscribe to [[hurd-devel-readers]] instead.
 
 <http://lists.gnu.org/mailman/listinfo/hurd-devel-readers>
 
-This list is a read-only mirror of [[hurd-devel]].  In contrast to subscribing
-to the latter, everyone is free to subscribe to this read-only list.
+This list is a read-only mirror of [[hurd-devel]].  In contrast to the former,
+everyone is free to subscribe to this read-only list.
 
 <a name="help-hurd"></a>
 ## help-hurd
@@ -68,7 +68,8 @@ to the latter, everyone is free to subscribe to this read-only list.
 <help-hurd@gnu.org>  
 <http://lists.gnu.org/mailman/listinfo/help-hurd>
 
-Hurd-specific questions; for users of the Hurd. If you need help on **using the Hurd** please ask in this list. 
+Hurd-specific questions, for users of the Hurd.  If you need help with [[*using
+the Hurd*|hurd/running]], please ask on this list.
 
 <a name="web-hurd"></a>
 ## web-hurd
@@ -103,6 +104,16 @@ Discussion around and questions regarding the
 
 Discussion about the [[GNU_system|hurd/running/gnu]].
 
+<a name="libc-alpha"></a>
+## libc-alpha
+
+<libc-alpha@sourceware.org>  
+<http://sourceware.org/ml/libc-alpha/>
+
+Discussion about [[glibc]], where the Hurd's POSIX et al. interfaces are
+implemented, amongst a lot of other bits and pieces.  This list is *moderated*,
+but on-topic development topics will generally be accepted.
+
 
 # Spam
 
diff --git a/mailing_lists/libc-alpha.mdwn b/mailing_lists/libc-alpha.mdwn
new file mode 100644
index 00000000..2f997922
--- /dev/null
+++ b/mailing_lists/libc-alpha.mdwn
@@ -0,0 +1,11 @@
+[[!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]]."]]"""]]
+
+[[!meta redir=mailing_lists#libc-alpha]]
diff --git a/open_issues/binutils_gold.mdwn b/open_issues/binutils_gold.mdwn
index f9008154..aa6843a3 100644
--- a/open_issues/binutils_gold.mdwn
+++ b/open_issues/binutils_gold.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]]
+[[!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
@@ -11,3 +11,177 @@ License|/fdl]]."]]"""]]
 [[!tag open_issue_binutils]]
 
 Have a look at GOLD / port as needed.
+
+
+# teythoon's try / `mremap` issue
+
+IRC, #hurd, 2011-01-12
+
+    <teythoon> I've been looking into building gold on hurd and it built fine
+      with one minor tweak
+    <teythoon> and it's working fine according to its test suite
+    <teythoon> the only problem is that the build system is failing to detect
+      the hurdish mremap which lives in libmemusage
+    <teythoon> on linux it is in the libc so the check succeeds
+    <teythoon> any hints on how to fix this properly?
+    <antrik> hm... it's strange that it's a different library on the Hurd
+    <antrik> are the implementations compatible?
+    <teythoon> antrik: it seems so, though the declarations differ slightly
+    <antrik> I guess the best thing is to ask on the appropriate list(s) why
+      they are different...
+    <teythoon> teythoon@ganymede:~/build/gold/binutils-2.21/gold$ grep -A1
+      mremap /usr/include/sys/mman.h 
+    <teythoon> extern void *mremap (void *__addr, size_t __old_len, size_t
+      __new_len, int __flags, ...) __THROW;
+    <teythoon> vs
+    <antrik> of course it would be possible to modify the configure script to
+      check for the Hurd variant too; but first we should establish whether
+      here is actually any reason for being different, or it's just some
+      historical artefact that should be fixed...
+    <teythoon> teythoon@ganymede:~/build/gold/binutils-2.21/gold$ fgrep 'extern
+      void *mremap' mremap.c 
+    <teythoon> extern void *mremap (void *, size_t, size_t, int, ...);
+    <teythoon> the problem is that the test fails to link due to the fact that
+      mremap isn't in the libc on hurd
+    <antrik> yeah, it would be possible for the configure script to check
+      whether it works when the hurdish extra library is added explicitely
+    <antrik> but again, I don't see any good reason for being different here in
+      the first place...
+    <teythoon> so should I create a patch to move mremap?
+    <antrik> if it's not too complicated, that would be nice... it's always
+      easier to discuss when you already have code :-)
+    <antrik> OTOH, asking first might spare you some useless work if it turns
+      out there *is* some reason for being different after all...
+    so where is the right place to discuss this?
+    <antrik> bug-hurd mailing list and/or glibc mailing list. not sure which
+      one is better -- I guess it doesn't hurt to crosspost...
+
+[[mailing_lists/libc-alpha]] is the correct list, and cross-posting to
+[[mailing_lists/bug-hurd]] would be fine, too.
+
+    <teythoon> antrik: some further digging revealed that mremap belongs to
+      /lib/libmemusage.so on both hurd and linux
+    <teythoon> the only difference is that on linux there is a weak reference
+      to that function in /lib/libc-2.11.2.so
+    <teythoon> $ objdump -T /lib/libc-2.11.2.so | fgrep mremap
+    <teythoon> 00000000000cf7e0  w   DF .text  0000000000000028  GLIBC_2.2.5
+      mremap
+    <antrik> ah, it's probably simply a bug that we don't have this weak
+      reference too
+    <antrik> IIRC we had similar bugs before
+    <antrik> teythoon: can you provide a patch for that?
+    <teythoon> antrik: unfortunately I have no idea how that weak ref ended up
+      there
+
+    <guillem> teythoon: also the libmemusage.s seems to be just a debugging
+      library to be used by LD_PRELOAD or similar
+    <guillem> which override those memory functions
+    <guillem> the libc should provide actual code for those functions, even if
+      the symbol is declared weak (so overridable)
+    <guillem> teythoon: are you sure that's the actual problem? can you paste
+      somewhere the build logs with the error?
+    <teythoon> guillem: sure
+    <teythoon> http://paste.debian.net/104437/
+    <teythoon> that's the part of config.log that shows the detection (or the
+      failure to detect it) of mremap
+    <teythoon> this results in HAVE_MREMAP not being defined
+    <teythoon> as a consequence it is declared in gold.h and this declaration
+      conflicts with the one from sys/mman.h http://paste.debian.net/104438/
+    <teythoon> on linux the test for mremap succeeds
+    <guillem> teythoon: hmm oh I guess it's just what that, mremap is linux
+      specific so it's not available on the hurd
+    <guillem> teythoon: I just checked glibc and seems to confirm that
+    <braunr> CONFORMING TO This call is Linux-specific, and should not be used
+      in programs intended to be portable.
+    <teythoon> ah okay
+    <teythoon> so I guess we shouldn't ship an header with that declaration...
+    <guillem> teythoon: yeah :/ good luck telling that to drepper :)
+    <guillem> teythoon: I guess he'll suggest that everyone else needs to get
+      our own copy of sys/mman.h
+    <guillem> s/our/their/
+    <teythoon> hm, so how should I proceed?
+    <braunr> what's your goal ?
+    <braunr> detecting mremap ?
+    <teythoon> making binutils/gold compile ootb on hurd
+    <teythoon> I picked it from the open issues page ;)
+    <braunr> well, if there is no mremap, you need a replacement
+    <teythoon> gold has a replacement
+    <braunr> ok
+    <braunr> so your problem is fixing the detection of mremap right ?
+    <teythoon> yes
+    <braunr> ok, that's a build system question then :/
+    <braunr> you need to ask an autotools guy
+    <teythoon> well, actually the build system correctly detects the absence of
+      mremap
+    <braunr> (gold does use the autotools right ?)
+    <teythoon> yes
+    <braunr> oh, i'm lost now (i admit i didn't read the whole issue :/)
+    <teythoon> it is just that the declaration in sys/mman.h conflicts with
+      their own declaration
+    <braunr> ah
+    <braunr> so in the absence of mremap, they use their own builtin function
+    <teythoon> yes
+    <teythoon> and according to the test suite it is working perfectly
+    <teythoon> gold that is
+    <teythoon> the declaration in mman.h has an extra __THROW
+    <guillem> a workaround would be to rename gold's mremap to something else,
+      gold_mremap for example
+    <braunr> that's really the kind of annoying issue
+    <braunr> you either have to change glibc, or gold
+    <guillem> yeah
+    <braunr> you'll face difficulty changing glibc, as guillem told you
+    <guillem> the correct solution though IMO is to fix glibc
+    <braunr> but this may be true for gold too
+    <braunr> guillem: i agree
+    <antrik> maybe it would be easiest actually to implement mremap()?...
+    <braunr> but as this is something quite linux specific, it makes sense to
+      use another internal name, and wrap that to the linux mremap if it's
+      detected
+    <braunr> antrik: i'm nto sure
+    <antrik> braunr: I don't think using such workarounds is a good
+      idea. clearly there would be no issue if the header file wouldn't be
+      incorrect on Hurd
+    <braunr> antrik: that's why i said i agree with guillem when he says "the
+      correct solution though IMO is to fix glibc"
+    <teythoon> what exactly is the problem with getting a patch into glibc?
+    <braunr> the people involved
+    <guillem> teythoon: and touching a generic header file
+    <braunr> but feel free to try, you could be lucky
+    <teythoon> but glibc is not an linux specific piece of software, right?
+    <braunr> teythoon: no, it's not
+    <guillem> erm...
+    <braunr> teythoon: but in practice, it is
+    <guillem> supposedly not :)
+    <antrik> braunr: BTW, by "easiest" I don't mean coding alone, but
+      coding+pushing upstream :-)
+    <guillem> so the problem is, misc/sys/mman.h should be a generic header and
+      as such not include linux specific parts, which are not present on hurd,
+      kfreebsd, etc etc
+    <braunr> antrik: yes, that's why guillem and i suggested the workaround
+      thing in gold
+    <antrik> that also requires pushing upstream. and quite frankly, if I were
+      the gold maintainer, I wouldn't accept it.
+    <guillem> but the easiest (and wrong) solution in glibc to avoid maintainer
+      conflict will probably be copying that file under hurd's glibc tree and
+      install that instead
+    <braunr> antrik: implementing mremap could be relatively easy to do
+      actually
+    <braunr> antrik: IIRC, vm_map() supports overlapping
+    <antrik> well, actually the easiest solution would be to create a patch
+      that never goes upstream but is included in Debian, like many
+      others... but that's obviously not a good long-term plan
+    <antrik> braunr: yes, I think so too
+    <antrik> braunr: haven't checked, but I have a vague recollection that the
+      fundamentals are pretty much there
+    <antrik> teythoon: so, apart from an ugly workaround in gold, there are
+      essentially three options: 1. implement mremap; 2. make parts of mman.h
+      conditional; 3. use our own copy of mman.h
+    <antrik> 1. would be ideal, but might be non-trivial; 2. would might be
+      tricky to get right, and even more tricky to get upstream; 3. would be
+      simple, but a maintenance burden in the long term
+    <teythoon> looking at golds replacement code (mmap & memcpy) 1 sounds like
+      the best option performance wise
+
+[[!taglink open_issue_glibc]]: check if it is possible to implement `mremap`.
+[[I|tschwinge]] remember some discussion about this, but have not yet worked on
+locating it.  [[Talk to me|tschwinge]] if you'd like to have a look at this.
diff --git a/open_issues/secure_file_descriptor_handling.mdwn b/open_issues/secure_file_descriptor_handling.mdwn
index 1a514e69..45e983a7 100644
--- a/open_issues/secure_file_descriptor_handling.mdwn
+++ b/open_issues/secure_file_descriptor_handling.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]]
+[[!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
@@ -12,7 +12,8 @@ License|/fdl]]."]]"""]]
 
 `O_CLOEXEC`, `dup3` et al.; see
 <http://udrepper.livejournal.com/20407.html>.  [[tschwinge]] once worked
-on this, posted patches to libc-alpha.  This works needs to be resumed
+on this, posted patches to [[mailing_lists/libc-alpha]].  This works needs to
+be resumed
 and finished.
 
 ---
diff --git a/open_issues/unit_testing.mdwn b/open_issues/unit_testing.mdwn
index 1cf7cfb8..d7821fd3 100644
--- a/open_issues/unit_testing.mdwn
+++ b/open_issues/unit_testing.mdwn
@@ -66,3 +66,7 @@ abandoned).
     testing, too?
 
   * <http://ltp.sourceforge.net/>
+
+  * [LaBrea](https://github.com/dustin/labrea/wiki), or similar tools can be
+    used for modelling certain aspects of system behavior (long response times,
+    for example).
diff --git a/user/El_Dream_Machine.mdwn b/user/El_Dream_Machine.mdwn
index f86d4bfd..ac3a0cfc 100644
--- a/user/El_Dream_Machine.mdwn
+++ b/user/El_Dream_Machine.mdwn
@@ -8,19 +8,29 @@ 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]]."]]"""]]
 
+**January 13, 2011** - My story comics on the Hurd continues. I think I can introduce you to page 2 in a month.
 
-I just try to become an end user of The Hurd. In 2004, I was able to install K9 on an old computer.
+**January 11, 2011** - The goal was to install the Hurd in VirtualBox...
+It happened on january,7 2011, a very nice day... Thanks to [http://www.paranoiaque.fr](http://www.paranoiaque.fr) for [the *Hurd.vdi* machine.](http://www.paranoiaque.fr/Hurd.vdi.tar.lzma)
+
+[A testimony](http://www.sites.google.com/site/hurdexperiences/en-hurd-vdi-tar-lzma) of this install and a video capture [Hurd operating.](http://www.dailymotion.com/video/xgl3nr_hurd-screenscat-ffmpeg-01_webcam)
+
+**October 14, 2010** - Here's the [french version.](http://art9libre.tuxfamily.org/gaetan/TheCallOfTheHurd-01-fr-png.jpg)
+
+**October 13, 2010** - Page 1 out ! The beginning of the [the comics is here :](http://eldreammachine.free.fr/gaetan/TheCallOfTheHurd-01.jpg)
+Hope it will pleased for you.
+
+**October 3, 2010** - I just try to become an end user of The Hurd. In 2004, I was able to install K9 on an old computer.
 These times, my goal is to install it on my laptop (maybe with crosshurd or with a lzma image for virtualbox, or any other way...)
 
 Also, I'm currently working on a comics'The Call Of The Hurd'. It's free licensed cc-by-sa/Copyleft Art Libre.
 1st page will be done before the end of the year I think (I look for good quality).
 
-And it's nice to be here :)
 
-Page 1 out ! The beginning of the [the comics is here :](http://eldreammachine.free.fr/gaetan/TheCallOfTheHurd-01.jpg)
-Hope it will pleased for you.
 
-Here's the [french version.](http://art9libre.tuxfamily.org/gaetan/TheCallOfTheHurd-01-fr-png.jpg)
+
+
+