summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
Diffstat
-rw-r--r--hurd/faq/which_microkernel.mdwn66
-rw-r--r--mailing_lists.mdwn35
-rw-r--r--mailing_lists/libc-alpha.mdwn11
-rw-r--r--open_issues/binutils_gold.mdwn176
-rw-r--r--open_issues/secure_file_descriptor_handling.mdwn5
-rw-r--r--open_issues/unit_testing.mdwn4
-rw-r--r--user/El_Dream_Machine.mdwn20
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)
+
+
+
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-23 01:22:49 +0000