From 22eb837b97541725ae9650e074c09bb6d7f8dd10 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 17 Nov 2011 14:00:50 +0100 Subject: hurd/translator/hello: New. --- hurd/io_path.mdwn | 6 +++--- hurd/translator.mdwn | 1 + hurd/translator/hello.mdwn | 14 ++++++++++++++ 3 files changed, 18 insertions(+), 3 deletions(-) create mode 100644 hurd/translator/hello.mdwn (limited to 'hurd') diff --git a/hurd/io_path.mdwn b/hurd/io_path.mdwn index 492edffe..c47b5dca 100644 --- a/hurd/io_path.mdwn +++ b/hurd/io_path.mdwn @@ -46,9 +46,9 @@ Back in `_Xio_read`. If the 2048 byte buffer is not decided to be used (out-of-line case or bigger than 2048 bytes case; server decides to instead provide a new memory region), -the [[`dealloc`|microkernel/mach/mig/dealloc]] flag is being set, which causes -Mach to unmap that memory region from the server's address space, i.e., doing a -memory *move* from the server to the client. +the [[`dealloc`|microkernel/mach/mig/documentation/dealloc]] flag is being set, +which causes Mach to unmap that memory region from the server's address space, +i.e., doing a memory *move* from the server to the client. Leave server-side RPC stub `_Xio_read`. diff --git a/hurd/translator.mdwn b/hurd/translator.mdwn index bf7af3ce..3527267f 100644 --- a/hurd/translator.mdwn +++ b/hurd/translator.mdwn @@ -80,6 +80,7 @@ The [[concept|concepts]] of translators creates its own problems, too: # Existing Translators +* [[hello]] * [[auth]] * [[exec]] * [[pfinet]] diff --git a/hurd/translator/hello.mdwn b/hurd/translator/hello.mdwn new file mode 100644 index 00000000..bd56cd76 --- /dev/null +++ b/hurd/translator/hello.mdwn @@ -0,0 +1,14 @@ +[[!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]]."]]"""]] + +The *hello* translator is an example of a simple [[libtrivfs]]-based one-node +[[translator]]. It is shipped as part of the [[Hurd source code +repository|source_repositories]], and exists in a single-threaded and a +multi-threaded variant. -- cgit v1.2.3 From 7ee8fdbd4c4e73f075b73a4567734ea4faf8a6e0 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 17 Nov 2011 14:56:39 +0100 Subject: news/2011-q3: Make a pass over it and finalize. --- community/meetings.mdwn | 3 +- community/meetings/froscon_2011.mdwn | 15 +++ community/meetings/ghm2011.mdwn | 14 ++ contributing/web_pages/news/moth_next.mdwn | 62 +++++---- contributing/web_pages/news/skeleton.mdwn | 33 ++--- hurd/dde/guide.mdwn | 2 +- media_appearances.mdwn | 5 + microkernel/mach/gnumach.mdwn | 5 +- news/2011-q3.mdwn | 200 ++++++++++++++--------------- 9 files changed, 181 insertions(+), 158 deletions(-) create mode 100644 community/meetings/froscon_2011.mdwn (limited to 'hurd') diff --git a/community/meetings.mdwn b/community/meetings.mdwn index 6c15d144..1c1a2cfc 100644 --- a/community/meetings.mdwn +++ b/community/meetings.mdwn @@ -13,7 +13,6 @@ License|/fdl]]."]]"""]] # Upcoming - * [[GNU Hackers Meeting, 2011, Paris|ghm2011]] ## In the Future @@ -22,6 +21,8 @@ License|/fdl]]."]]"""]] # Past + * [[FrOSCon_2011]] + * [[GNU Hackers Meeting, 2011, Paris|ghm2011]] * [[FOSDEM_2011]] * [[DebConf10]] * [[GNU Hackers Meeting, 2010, Den Haag|ghm2010]] diff --git a/community/meetings/froscon_2011.mdwn b/community/meetings/froscon_2011.mdwn new file mode 100644 index 00000000..b15140d6 --- /dev/null +++ b/community/meetings/froscon_2011.mdwn @@ -0,0 +1,15 @@ +[[!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 title="FrOSCon, 2011, Sankt Augustin, Germany"]] + + + + * [Arch Hurd booth](http://www.froscon.de/en/exhibitors/projekte.html#c1413) diff --git a/community/meetings/ghm2011.mdwn b/community/meetings/ghm2011.mdwn index 7a2df8a0..8e77d500 100644 --- a/community/meetings/ghm2011.mdwn +++ b/community/meetings/ghm2011.mdwn @@ -11,3 +11,17 @@ License|/fdl]]."]]"""]] [[!meta title="GNU Hackers Meeting, 2011, Paris"]] + + * {{$thibault_hurd}} + + +[[!ymlfront data=""" + +thibault_hurd: + + "presentation by Samuel Thibault: [*GNU/Hurd, aka. Extensibility from the + Ground*](http://www.gnu.org/ghm/2011/paris/#outline-container-2-5) + ([slides](http://www.gnu.org/ghm/2011/paris/slides/samuel-thibault-hurd.pdf), + [video](http://audio-video.gnu.org/video/ghm2011/Samuel_Thibault-GNU_Hurd.ogv))" + +"""]] diff --git a/contributing/web_pages/news/moth_next.mdwn b/contributing/web_pages/news/moth_next.mdwn index 899e3958..029c6769 100644 --- a/contributing/web_pages/news/moth_next.mdwn +++ b/contributing/web_pages/news/moth_next.mdwn @@ -27,31 +27,26 @@ else=" This month [hurd hacker] [item] -**http://lists.gnu.org/archive/html/bug-hurd/2011-11/msg00079.html** + -- Bouju +Alain submitted a patch to suport cpuinfo in the /proc interface -Bouju Alain submitted a patch to suport cpuinfo in the /proc interface +rbraun committed the last patch to mplanetas branch of the slab allocator +work, for integration. -**IRC 2011-11-14** - -rbraun committed the last patch to mplanetas branch of the slab allocator work, for integration. +IRC, freenode, #hurd, 2011-11-14: Features: -(22:30:39) braunr: there shouldn't be any noticeable difference with the master branch - -(22:30:46) braunr: a bit less fragmentation - -(22:30:55) braunr: more memory can be reclaimed by the VM system - -(22:31:02) braunr: there are debugging features - -(22:31:06) braunr: it's SMP ready - -(22:31:15) braunr: and overall cleaner than the zone allocator - -(22:31:31) braunr: although a bit slower on the free path (because of what's performed to reduce fragmentation) - -(22:32:42) braunr: but even "slower" here is completely negligible + (22:30:39) braunr: there shouldn't be any noticeable difference with the + master branch + (22:30:46) braunr: a bit less fragmentation + (22:30:55) braunr: more memory can be reclaimed by the VM system + (22:31:02) braunr: there are debugging features + (22:31:06) braunr: it's SMP ready + (22:31:15) braunr: and overall cleaner than the zone allocator + (22:31:31) braunr: although a bit slower on the free path (because of + what's performed to reduce fragmentation) + (22:32:42) braunr: but even "slower" here is completely negligible **New porter box: exodar*** @@ -67,22 +62,23 @@ Additionally … And … -So if you want to [reason for contibuting to the Hurd] please [[get_in_contact|contact_us]] - and maybe grab [[our_source_repos|source_repositories]]. +So if you want to [reason for contibuting to the Hurd], +please [[get in contact|contact_us]] -- and maybe already grab the [[source +code|source_repositories]]. ------- +--- -The **GNU Hurd** is the GNU project's replacement for the Unix kernel. -It is a collection of servers that run on the Mach microkernel to -implement file systems, network protocols, file access control, and -other features that are implemented by the Unix kernel or similar -kernels (such as Linux). -[[More_detailed|hurd/documentation]]. +The **GNU Hurd** is the GNU project's replacement for the Unix kernel. It is a +collection of servers that run on the Mach microkernel to implement file +systems, network protocols, file access control, and other features that are +implemented by the Unix kernel or similar kernels (such as Linux). [[More +detailed|hurd/documentation]]. -**GNU Mach** is the microkernel upon which GNU Hurd is based. It -offers Inter Process Communication (IPC) which the Hurd uses to define -interfaces for implementing the services an operating system needs -from a full-featured kernel. -[[Read_more|microkernel/mach/gnumach]] +**GNU Mach** is the microkernel upon which a GNU Hurd system is based. It +provides an Inter Process Communication (IPC) mechanism that the Hurd uses to +define interfaces for implementing in a distributed multi-server fashion the +services a traditional operating system kernel provides. [[More +detailed|microkernel/mach/gnumach]]. diff --git a/contributing/web_pages/news/skeleton.mdwn b/contributing/web_pages/news/skeleton.mdwn index 78db041d..d78d1b5a 100644 --- a/contributing/web_pages/news/skeleton.mdwn +++ b/contributing/web_pages/news/skeleton.mdwn @@ -37,22 +37,23 @@ Additionally … And … -So if you want to [reason for contibuting to the Hurd] please [[get_in_contact|contact_us]] - and maybe grab [[our_source_repos|source_repositories]]. - ------- - -The **GNU Hurd** is the GNU project's replacement for the Unix kernel. -It is a collection of servers that run on the Mach microkernel to -implement file systems, network protocols, file access control, and -other features that are implemented by the Unix kernel or similar -kernels (such as Linux). -[[More_detailed|hurd/documentation]]. - -**GNU Mach** is the microkernel upon which GNU Hurd is based. It -offers Inter Process Communication (IPC) which the Hurd uses to define -interfaces for implementing the services an operating system needs -from a full-featured kernel. -[[Read_more|microkernel/mach/gnumach]] +So if you want to [reason for contibuting to the Hurd], +please [[get in contact|contact_us]] -- and maybe already grab the [[source +code|source_repositories]]. + +--- + +The **GNU Hurd** is the GNU project's replacement for the Unix kernel. It is a +collection of servers that run on the Mach microkernel to implement file +systems, network protocols, file access control, and other features that are +implemented by the Unix kernel or similar kernels (such as Linux). [[More +detailed|hurd/documentation]]. + +**GNU Mach** is the microkernel upon which a GNU Hurd system is based. It +provides an Inter Process Communication (IPC) mechanism that the Hurd uses to +define interfaces for implementing in a distributed multi-server fashion the +services a traditional operating system kernel provides. [[More +detailed|microkernel/mach/gnumach]]. diff --git a/hurd/dde/guide.mdwn b/hurd/dde/guide.mdwn index a3c08754..6a83519c 100644 --- a/hurd/dde/guide.mdwn +++ b/hurd/dde/guide.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010,2011 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 diff --git a/media_appearances.mdwn b/media_appearances.mdwn index b52b80bf..c005c381 100644 --- a/media_appearances.mdwn +++ b/media_appearances.mdwn @@ -18,6 +18,11 @@ A lot of stuff is missing here. # 2011 +## August + + * GNU Hackers Meeting in Paris: {{$community/meetings/ghm2011#thibault_hurd}} + + ## July diff --git a/microkernel/mach/gnumach.mdwn b/microkernel/mach/gnumach.mdwn index d9ff6535..edd0cfdb 100644 --- a/microkernel/mach/gnumach.mdwn +++ b/microkernel/mach/gnumach.mdwn @@ -9,7 +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]]."]]"""]] -GNU Mach is the microkernel that the GNU/Hurd system is based on. +GNU Mach is the microkernel upon which a GNU Hurd system is based. It provides +an Inter Process Communication (IPC) mechanism that the Hurd uses to define +interfaces for implementing in a distributed multi-server fashion the services +a traditional operating system kernel provides. It is maintained by the Hurd developers for the GNU project and remains compatible with [[Mach]] 3.0. diff --git a/news/2011-q3.mdwn b/news/2011-q3.mdwn index de7b869b..c1a78319 100644 --- a/news/2011-q3.mdwn +++ b/news/2011-q3.mdwn @@ -8,14 +8,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 date="2011-11-17 14:15 UTC"]] - - -A quarter of the Hurd: *Arch with DDE*, *Debian boxes*, *GHM talk*, *GNU Mach fixes* and *GSoC: Java*. +A quarter of the Hurd: *Arch Hurd with DDE*, *Debian boxes*, *GHM talk* and +*GSoC: Java*. [[!if test="included()" then="""[[!toggle id=full_news text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" else=" @@ -23,106 +19,98 @@ else=" [[!cut id="full_news" text=""" - - -In the third quarter of 2011, the Arch Hurd Hackers [packaged DDE](http://www.archhurd.org/news/22/), -so a subset of Linux 2.6 drivers can now be compiled on Arch Hurd to -run in userspace. At the time of writing it supports network cards, -while other driver-types still need their interfaces ported. Also they -had -[a booth at FrOSCon](http://www.froscon.de/en/exhibitors/projekte.html) -and -[released a new Arch Hurd LiveCD](http://www.archhurd.org/news/24/), -so new users can easily test the current state of the Arch flavor of -the Hurd. - -Also Richard Braun contributed new Debian and KVM-based -[[buildd,_porterbox_and_public_box|public_hurd_boxen]], making it -easier to test the Hurd without much setup as well as improving debian -packaging. - -Samuel Thibault wrote a new -[Bits from the Debian GNU/Hurd porters](http://lists.debian.org/debian-devel-announce/2011/07/msg00002.html) -to keep the Debian Folks up to date with the results of our work. And -these are quite good: Thanks to the relentless work of our porters, -you can now use -[70% of debian packages with the Hurd](https://buildd.debian.org/stats/graph-big.png), -so we’re coming closer towards -[getting Hurd into Debian as a release arch](http://wiki.debian.org/Debian_GNU/Hurd). If -you can port debian packages and want to help the Hurd, this is the -perfect time to get in contact and -[port your favorite missing package](http://www.debian.org/ports/hurd/hurd-devel-debian) -to the Hurd. - -A different type of status update was delivered by Samuel Thibault on -the GNU Hacker Meeting (GHM). Since the videos and slides from the GNU -Hacker Meeting 2011 in Paris are -[online](http://www.gnu.org/ghm/2011/paris/), now, we hope you enjoy -his talk on -[GNU/Hurd, aka. Extensibility from the Ground (video)](http://audio-video.gnu.org/video/ghm2011/Samuel_Thibault-GNU_Hurd.ogv) -([slides](http://www.gnu.org/ghm/2011/paris/slides/samuel-thibault-hurd.pdf)). He -explains nicely how the simple concept of translators gives power to -non-priviledged and casual users (once we get some of these :) ) -without security implications, and how Sub-Hurds and Neighbor-Hurds -compare to Linux containers. - - “It’s all about freedom #0” - -On the technical side, Thomas Schwinge improved the technical -documentation of the [[hurd/io_path]] in translators to make it easier -for new developers to start hacking and Guillem Jover, Fridolin -Pokorny and Jonathan Neuschäfer +In the third quarter of 2011, the Arch Hurd hackers [packaged DDE (Device +Driver Environment)](http://www.archhurd.org/news/22/), so a subset of the +Linux 2.6 device drivers can now easily be run as user-space processes on Arch +Hurd, replacing GNU Mach's in-kernel device drivers. (This has been possible +before, too, but involved several [[manual steps|hurd/dde/guide]].) At the +time of writing, our DDE port supports several network cards, while for other +driver types we will need to add further generic infrastructure. Also, Arch +Hurd had [a booth at +FrOSCon](http://www.froscon.de/en/exhibitors/projekte.html#c1413) and [released +a new Arch Hurd LiveCD](http://www.archhurd.org/news/24/), so new users can +easily test the current state of the Arch flavor of the Hurd. + +Richard Braun contributed additional GNU Hurd instances: [[a *Debian buildd*, a +*Debian porterbox*, and a *public Hurd box*|public_hurd_boxen]]. Especially +the last one is important for *you*: after requesting an account, you can use +it to test the Hurd without any own setup. + +Samuel Thibault sent a new [Bits from the Debian GNU/Hurd +porters](http://lists.debian.org/debian-devel-announce/2011/07/msg00002.html) +to keep the Debian folks up to date with our progres. And it is quite good: +thanks to the relentless work of our porters, you can now use [70 % of all +Debian packages with the Hurd](https://buildd.debian.org/stats/graph-big.png), +so we're getting closer to [the goal of finishing a Release Canditate in time +for Debian Wheezy](http://wiki.debian.org/Debian_GNU/Hurd). If you can, for +example, port Debian packages and want to help the Hurd, this is the perfect +time to get in contact and [port your favorite missing +package](http://www.debian.org/ports/hurd/hurd-devel-debian) to the Hurd. + +A different kind of status update was delivered by Samuel Thibault on the [[GNU +Hacker Meeting (GHM) in Paris|community/meetings/ghm2011]]. We hope you enjoy +watching the video of the {{$community/meetings/ghm2011#thibault_hurd}}. He +nicely explains how the simple yet powerful concept of a [[hurd/translator]] +gives power to a system's less-priviledged users (that is, without `root` +access), without any security implications, and how [[hurd/subhurd]]s and +[[hurd/neighborhurd]]s compare to Linux containers. *It's all about [freedom +0](http://www.gnu.org/philosophy/free-sw.html)*. + +On the technical side, Thomas Schwinge improved the technical documentation of +the [[I/O path|hurd/io_path]] when translators are involved, to make it easier +for new developers to understand how all the different system components +interact. Amongst others, Guillem Jover, Fridolín Pokorný and Jonathan +Neuschäfer [sent](http://lists.gnu.org/archive/html/bug-hurd/2011-08/msg00184.html) [many](http://lists.gnu.org/archive/html/bug-hurd/2011-08/msg00093.html) -[patches](http://lists.gnu.org/archive/html/bug-hurd/2011-08/msg00030.html) -for GNU Mach, improving stability, fixing memory leaks and cleaning up -code. - -Additionally Maksym Planeta replaced GNU Mach’s old zone memory -allocator with the new slab allocator from Richard Braun -([integration commit](http://git.savannah.gnu.org/cgit/hurd/gnumach.git/commit/?id=50d073c5ef0feb1676606d0068abf626e8297cd7)), -which should waste less memory than the zone allocator. Also it has a -cpu cache level, so it should work faster on SMP systems, once we get -up do date SMP CPU drivers for GNU Mach. It is now being integrated. - -And last but definitely not least, Jeremie Koenig finished his Google -Summer of Code project to -[Improve Java on Hurd](http://www.gnu.org/software/hurd/user/jkoenig/java.html). He -[improved the Hurd signalling](http://lists.gnu.org/archive/html/bug-hurd/2011-06/msg00073.html), -ported OpenJDK and created a -[Java Hurd-Library](https://github.com/jeremie-koenig/hurd-java) which -already allows writing a -[Hello World translator in Java](https://github.com/jeremie-koenig/hurd-java/blob/master/HelloMach.java). It -is still pretty low-level, but it paves the way for extending the core -of the Hurd with Java, which gets the count of supported languages to -3: -[C(++)](http://www.gnu.org/software/hurd/hacking-guide/hhg.html#An-Example-using-trivfs), -[[common_lisp|user/flaviocruz]] and Java. - -So if you want to help get the Hurd into Debian as a full release arch, -so the power to the Hurd gives to casual users can actually get into -the Hands of these, or dig dig deep into DDE to have more Linux -drivers running in Userspace, please [[get_in_contact|contact_us]] - -and maybe grab [[our_source_repos|source_repositories]]. - ------- - -The **GNU Hurd** is the GNU project's replacement for the Unix kernel. -It is a collection of servers that run on the Mach microkernel to -implement file systems, network protocols, file access control, and -other features that are implemented by the Unix kernel or similar -kernels (such as Linux). -[[More_detailed|hurd/documentation]]. - -**GNU Mach** is the microkernel upon which GNU Hurd is based. It -offers Inter Process Communication (IPC) which the Hurd uses to define -interfaces for implementing the services an operating system needs -from a full-featured kernel. -[[Read_more|microkernel/mach/gnumach]] - - - - - +[patches](http://lists.gnu.org/archive/html/bug-hurd/2011-08/msg00030.html) for +GNU Mach, improving stability, fixing memory leaks and generally cleaning up +the code. + +Maksym Planeta finished a project he has been doing as a university task: +replace GNU Mach's old zone memory allocator with a new [[!wikipedia +slab_allocation desc="slab allocator"]] written by Richard Braun, who also +mentored Maksym during the project. [This +allocator](http://git.savannah.gnu.org/cgit/hurd/gnumach.git/commit/?h=mplaneta/libbraunr/master&id=59c9da87375ad3c8401890ecd4f7f101093f2463), +apart from being overally cleaner than the zone allocator, is meant to waste +less memory than the zone allocator (less fragmentation and more memory can be +reclaimed by the VM system), there are debugging/inspection features, and it's +SPM-ready, thus readily usable once we get up-do-date SMP support in GNU Mach. +It is now being tested and integrated. + +And last but definitely not least, Jérémie Koenig finished his Google Summer of +Code project to [[improve Java support on GNU Hurd|user/jkoenig/java]]. All in +all, he also [improved the Hurd signalling +code](http://lists.gnu.org/archive/html/bug-hurd/2011-06/msg00073.html), ported +OpenJDK and began designing and creating a [library for Java bindings for Mach +and Hurd](https://github.com/jeremie-koenig/hurd-java) which already allows +writing a [Hello World translator in +Java](https://github.com/jeremie-koenig/hurd-java/blob/master/HelloMach.java). +It is still pretty low-level, but it paves the way for extending the core of +the Hurd with Java, which is one of the benefits of the Hurd's distributed +multi-server architecture: different components of the operating system can be +written in different programming languages; not just +[C](http://www.gnu.org/software/hurd/hacking-guide/hhg.html#An-Example-using-trivfs), +but also C++, [[Common Lisp|user/flaviocruz]], and now Java -- and more to +come. + +So if you want to help getting the Debian GNU/Hurd Release Candidate done, or +want to dig deep into DDE to have more device drivers running as user-space +processes, please [[get in contact|contact_us]] -- and maybe already grab the +[[source code|source_repositories]]. + +--- + +The **GNU Hurd** is the GNU project's replacement for the Unix kernel. It is a +collection of servers that run on the Mach microkernel to implement file +systems, network protocols, file access control, and other features that are +implemented by the Unix kernel or similar kernels (such as Linux). [[More +detailed|hurd/documentation]]. + +**GNU Mach** is the microkernel upon which a GNU Hurd system is based. It +provides an Inter Process Communication (IPC) mechanism that the Hurd uses to +define interfaces for implementing in a distributed multi-server fashion the +services a traditional operating system kernel provides. [[More +detailed|microkernel/mach/gnumach]]. """]] -- cgit v1.2.3 From 4fa5c2b40a6b91ea3956a807ba09adba28ef18cb Mon Sep 17 00:00:00 2001 From: Diego Nieto Cid Date: Sun, 30 Oct 2011 18:00:45 -0300 Subject: id:"20111030210045.GA4983@myhost". --- hurd.mdwn | 2 +- hurd/console.mdwn | 85 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ hurd/libports.mdwn | 12 +++++++- 3 files changed, 97 insertions(+), 2 deletions(-) (limited to 'hurd') diff --git a/hurd.mdwn b/hurd.mdwn index 255cd3d7..55a72e1e 100644 --- a/hurd.mdwn +++ b/hurd.mdwn @@ -65,7 +65,6 @@ in the *unstable* branch of the Debian archive. ## Common Problems -* [[Console]] * [[Xfree86]] -- [[DebianX]] -- [[DebianXorg]] * [[GNUstep]] * [[XattrHurd]]: Setting translators under GNU/Linux @@ -100,3 +99,4 @@ in the *unstable* branch of the Debian archive. * [[Debugging]] * [Hurd Sourcecode Reference](http://www.htu.tugraz.at/~past/hurd/global/): Searchable and browsable index of the code. * [[Networking]] +* [[Console]] diff --git a/hurd/console.mdwn b/hurd/console.mdwn index 4f976efd..e9daa96e 100644 --- a/hurd/console.mdwn +++ b/hurd/console.mdwn @@ -1,3 +1,88 @@ +[[!meta copyright="Copyright © 2002, 2003, 2004, 2005, 2006, 2007, 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 +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]]."]]"""]] + +The Hurd console's implementation is broken into two pieces each running on +it's own process, the console client and server. + +The console server is also splitted into modules (input driver, display driver, +speaker, ...) but they all run in the same process. + +The console server puts itself as a translator on top of `/dev/vcs` folder +presenting the following hierarchy: + + + /dev/vcs + \ + +- 1 + \ + +- console + +- input + +- display + +- .. + +- n + +where the numbered nodes represent virtual consoles and their contents are all +alike. + +As the following graph shows, the console, input and display nodes are the +interfaces used by the terminal server, input driver and display drivers +respectively. + + +------------------+ +-----------------+ + | Input driver | | Terminal Server | + | | | | + | pc-kbd | | | + +------------------+ +-----------------+ + | _cons_vcons_input | + | writes to reads | + | vcs/i/input vcs/i/console | + | +-----------------+ | + | | Console Server | | + | | /hurd/console | | + | input_enqueue | --------------- | input_dequeue | + +--------------->| Input Queue |>---------------+ + | --------------- | + +--------------->| Output Buffer |>---------------+ + | +-----------------+ | + | | + | writes reads | + | vcs/i/console vcs/i/display | + | | + +----------------+ +-----------------+ + | Teminal Server | | Display driver | + | | | | + | /hurd/term | | vga | + +----------------+ +-----------------+ + +The input driver takes scancodes from the in-kernel kbd queue, translates them +into characters and writes them to the input node. Then the terminal server +reads the console node taking the characters out of the console server. + +Each of theese actions is actually an RPC handled by the translator on +`/dev/vcs`. Writes to input nodes are handled by calling `input_enqueue` to +put the character into a queue. And reads from console nodes are handled by +calling `input_dequeue` which takes out charecters from the queue and gives +them to the reader. + +It's important to note here that both `input_enqueue` and `input_dequeue` are +blocking operations and a blocked `input_dequeue` necessarily needs an +`input_enqueue` call to continue. + +[[RPC]]s are handled by the console server with the help of [[hurd/libports]]' +`ports_manage_multithreaded` API. + + +--- + +/!\ old content; [[!taglink open_issue_documentation]]: cleanup needed. + The below is a reworked version of Marcus Brinkmann's [letter to the debian-hurd list](http://lists.debian.org/debian-hurd/2002/debian-hurd-200209/msg00054.html). It describes how to setup the new console server for the Hurd. I am testing this right now, so this document is a work in progress. -- [[Main/JoachimNilsson]] - 21 Jan 2003 diff --git a/hurd/libports.mdwn b/hurd/libports.mdwn index 28274338..0ec0596c 100644 --- a/hurd/libports.mdwn +++ b/hurd/libports.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 @@ -18,3 +18,13 @@ provide an interface independently of the underlying [[microkernel]]. *libports* does not itself depend on *[[libthreads]]*, but the appropriate threading hooks are used if present, that is if *[[libthreads]]* is used by another component. + + +# Message Processing + +## `ports_manage_multithreaded` + +When a message is recieved, the thread acting as receiver checks if any other +thread is also waiting for requests. If there is none, a new thread is +spawned. Thus, the current thread continues processing the message while the +newly created thread starts listening for new ones. -- cgit v1.2.3 From 7868681998128e95cc797fc3cca934714fa948a0 Mon Sep 17 00:00:00 2001 From: "Thomas Bushnell, BSG" Date: Mon, 20 Aug 2001 23:43:29 -0700 Subject: id:"87hev152we.fsf@becket.becket.net". --- hurd.mdwn | 1 + hurd/libthreads.mdwn | 28 ++++++++++++++++++++++++++++ 2 files changed, 29 insertions(+) create mode 100644 hurd/libthreads.mdwn (limited to 'hurd') diff --git a/hurd.mdwn b/hurd.mdwn index 55a72e1e..11995c87 100644 --- a/hurd.mdwn +++ b/hurd.mdwn @@ -93,6 +93,7 @@ in the *unstable* branch of the Debian archive. * [[libnetfs]] -- short introductory material * [[libdiskfs]] * [[libihash]] + * [[libthreads]] * [[libpthread]] * [[IO_Path]] * [[Porting]] diff --git a/hurd/libthreads.mdwn b/hurd/libthreads.mdwn new file mode 100644 index 00000000..8b1a97e6 --- /dev/null +++ b/hurd/libthreads.mdwn @@ -0,0 +1,28 @@ +[[!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]]."]]"""]] + +`libthreads` a.k.a. C threads. + + +# Internals + + +## Threads' Death + +C threads 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. -- cgit v1.2.3 From 26d86a6a7e67e81ae5d02bfdb0d4363f2e741baa Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 24 Nov 2011 09:24:02 +0100 Subject: Link some things. --- hurd/libports.mdwn | 9 ++++++++- open_issues/multithreading.mdwn | 2 +- shortcuts.mdwn | 7 +++++++ 3 files changed, 16 insertions(+), 2 deletions(-) (limited to 'hurd') diff --git a/hurd/libports.mdwn b/hurd/libports.mdwn index 0ec0596c..6f2cd46d 100644 --- a/hurd/libports.mdwn +++ b/hurd/libports.mdwn @@ -27,4 +27,11 @@ another component. When a message is recieved, the thread acting as receiver checks if any other thread is also waiting for requests. If there is none, a new thread is spawned. Thus, the current thread continues processing the message while the -newly created thread starts listening for new ones. +newly created thread starts listening for new ones. ([[!taglink +open_issue_hurd]]: [[open_issues/multithreading]].) + +Also, there are configurable timeouts for [[translator]]s who want to go away +when they are not used. ([[!taglink open_issue_hurd]]: there used to be bugs +in this area, [[!message-id "87hev152we.fsf@becket.becket.net"]], but it may be +fixed as of [[!message-id "20111030210045.GA4983@myhost"]], +[[!GNU_Savannah_Git_hurd_hurd 9b5429e834cde56f73b8ff605e36afc7d9bb6e1b]].) diff --git a/open_issues/multithreading.mdwn b/open_issues/multithreading.mdwn index 1fc2c318..0f6b9f19 100644 --- a/open_issues/multithreading.mdwn +++ b/open_issues/multithreading.mdwn @@ -24,7 +24,7 @@ Hurd servers / VFS libraries are multithreaded. # Design -Roughly using one thread per +See [[hurd/libports]]: roughly using one thread per incoming request. This is not the best approach: it doesn't really make sense to scale the number of worker threads with the number of incoming requests, but instead they should be scaled according to the backends' characteristics. diff --git a/shortcuts.mdwn b/shortcuts.mdwn index b62b2981..fd4d4dee 100644 --- a/shortcuts.mdwn +++ b/shortcuts.mdwn @@ -87,6 +87,13 @@ ikiwiki will include your shortcut in the standard underlay. * [[!shortcut name=FF_project url="http://www.fossfactory.org/project/p%s" desc="FOSS Factory bounty (p%s)"]] +## Savannah + + * [[!shortcut name=GNU_Savannah_Git_hurd_hurd + url="http://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?id=%s" + desc="hurd/hurd.git commit %s"]] + + ## Notmuch'n'Gmane. * [[!shortcut name=message-id url="http://thread.gmane.org/%s" desc="""`id:"%s"`"""]] -- cgit v1.2.3 From 293627cef09ed1ec6af273c7bac4403fdb95b2ef Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawlegphoLJxjHXB6RKfIjNO2v_EzeaR11zI" Date: Sat, 26 Nov 2011 22:08:00 +0100 Subject: The clients holds the different drivers. Not the server. --- hurd/console.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'hurd') diff --git a/hurd/console.mdwn b/hurd/console.mdwn index e9daa96e..f7230011 100644 --- a/hurd/console.mdwn +++ b/hurd/console.mdwn @@ -12,7 +12,7 @@ License|/fdl]]."]]"""]] The Hurd console's implementation is broken into two pieces each running on it's own process, the console client and server. -The console server is also splitted into modules (input driver, display driver, +The console client is also split into modules (input driver, display driver, speaker, ...) but they all run in the same process. The console server puts itself as a translator on top of `/dev/vcs` folder -- cgit v1.2.3 From 2b27a58b6bd49c086cf5d208a82315c167867fff Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 27 Nov 2011 12:26:23 +0100 Subject: hurd/libpager: LWN, Jonathan Corbet, No-I/O dirty throttling, 2011-08-31. --- hurd/libpager.mdwn | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) (limited to 'hurd') diff --git a/hurd/libpager.mdwn b/hurd/libpager.mdwn index 99f28f2a..d844743d 100644 --- a/hurd/libpager.mdwn +++ b/hurd/libpager.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2007, 2008, 2010 Free Software Foundation, +[[!meta copyright="Copyright © 2007, 2008, 2010, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -6,8 +6,8 @@ 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]]."]]"""]] Mach's [[microkernel/mach/external_pager_mechanism]]. @@ -16,6 +16,16 @@ Mach [[microkernel/mach/IPC]]'s [[microkernel/mach/ipc/sequence_numbering]]. [GNU Hurd Reference Manual: 4.2 Pager Library](http://www.gnu.org/software/hurd/doc/hurd_5.html#SEC32). + +# Writeback: Writing Out Dirty Pages + + +## Related + + * LWN, Jonathan Corbet, [*No-I/O dirty + throttling*](http://lwn.net/Articles/456904/), 2011-08-31. + + # Open Issues * [[open_issues/linux_vmsig]] -- cgit v1.2.3 From be4193108513f02439a211a92fd80e0651f6721b Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 30 Nov 2011 21:21:45 +0100 Subject: IRC. --- hurd/debugging/rpctrace.mdwn | 37 ++++ hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn | 37 ++++ hurd/virtual_file_system/discussion.mdwn | 39 ++++ microkernel/mach/gnumach/memory_management.mdwn | 22 +++ open_issues/anatomy_of_a_hurd_system.mdwn | 28 ++- open_issues/ext2fs_page_cache_swapping_leak.mdwn | 88 ++++++++- open_issues/gnumach_memory_management.mdwn | 202 +++++++++++++++++++++ open_issues/libmachuser_libhurduser_rpc_stubs.mdwn | 50 +++++ open_issues/mig_portable_rpc_declarations.mdwn | 58 ++++++ open_issues/mission_statement.mdwn | 12 +- open_issues/page_cache.mdwn | 73 ++++++++ open_issues/perl.mdwn | 50 +++++ open_issues/robustness.mdwn | 64 +++++++ open_issues/syslog.mdwn | 27 +++ open_issues/translator_stdout_stderr.mdwn | 32 ++++ 15 files changed, 815 insertions(+), 4 deletions(-) create mode 100644 hurd/virtual_file_system/discussion.mdwn create mode 100644 open_issues/mig_portable_rpc_declarations.mdwn create mode 100644 open_issues/page_cache.mdwn create mode 100644 open_issues/robustness.mdwn (limited to 'hurd') diff --git a/hurd/debugging/rpctrace.mdwn b/hurd/debugging/rpctrace.mdwn index f7136056..fd24f081 100644 --- a/hurd/debugging/rpctrace.mdwn +++ b/hurd/debugging/rpctrace.mdwn @@ -52,6 +52,43 @@ See `rpctrace --help` about how to use it. note that there is a number of known bugs in rpctrace, for which zhengda has sent patches... though I haven't reviewed all of them I think there are some nasty Mach operations that are really hard to proxy -- but I don't think the auth mechanism needs any of these... +* IRC, freenode, #hurd, 2011-11-04 + + [[!taglink open_issue_documentation]] + + hello. Are there any documentation about understanding output + of rpctrace? + no + you should read the source code, best doc available + if you have too many numbers and almost no symbolc names, + you're lacking rpc definition lists + check that the gnumach-common package is installed, as it + provides the gnumach definitions + (the glibc ones are almost always available) + with those two, you should be fine for the beginning + gnumach-common is installed. And what is the name for glibc + package for gnumach definitions. + Also I'm using libraries specified by LD_LIBRARY_PATH. Does it + make influence on absence of symbolic names? + no + rpctrace --help + see the --rpc-list=FILE option + the default lists are in /usr/share/msgids/, with the .msgids + extension + $ dpkg -S msgids + gnumach-common: /usr/share/msgids/gnumach.msgids + hurd: /usr/share/msgids/hurd.msgids + ok, glibc has none, it's the hurd + for more details about the output, read the source code + it shouldn't be that hard to grasp + -I /usr/share/msgids helped + thank you + it shouldn't have, it's the default path + but symbolic names appeared + well, that's weird :) + braunr: the output of rpctrace --help should tell the + default dir for msgids + # See Also diff --git a/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn b/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn index a9317c21..5228515f 100644 --- a/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn +++ b/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn @@ -233,3 +233,40 @@ See also: [[open_issues/resource_management_problems/pagers]]. I have never looked at it. [[open_issues/mach-defpager_vs_defpager]]. + + +# IRC, freenode, #hurd, 2011-11-08 + + who else uses defpager besides tmpfs and kernel? + normally, nothing directly + than why tmpfs should use defpager? + it's its backend + backign store rather + the backing store of most file systems are partitions + tmpfs has none, it uses the swap space + if we allocate memory for tmpfs using vm_allocate, will it be able + to use swap partition? + it should + vm_allocate just maps anonymous memory + anonymous memory uses swap space as its backing store too + but be aware that this part of the vm system is known to have + deficiencies + which is why all mach based implementations have rewritten their + default pager + what kind of deficiencies? + bugs + and design issues, making anonymous memory fragmentation horrible + mcsim: vm_allocate doesn't return a memory object; so it can't be + passed to clients for mmap() + antrik: I use vm_allocate in pager_read_page + mcsim: well, that means that you have to actually implement a + pager yourself + also, when the kernel asks the pager to write back some pages, it + expects the memory to become free. if you are "paging" to ordinary + anonymous memory, this doesn't happen; so I expect it to have a very bad + effect on system performance + both can be avoided by just passing a real anonymous memory + object, i.e. one provided by the defpager + only problem is that the current defpager implementation can't + really handle that... + at least that's my understanding of the situation diff --git a/hurd/virtual_file_system/discussion.mdwn b/hurd/virtual_file_system/discussion.mdwn new file mode 100644 index 00000000..9e12d01e --- /dev/null +++ b/hurd/virtual_file_system/discussion.mdwn @@ -0,0 +1,39 @@ +[[!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]]."]]"""]] + +[[!tag open_issue_documentation]] + +IRC, freenode, #hurd, 2011-11-12: + + So hurd implements a 'transparent translator' somewhere which + just passes all IO calls to the posix IO I'm used to? (i.e. read, write, + open, close, etc.?) + it's the normal way of operation + glibc's read() doesn't do a system call, it always does an RPC to + the underlying translator + be it ext2fs for /, or your foobarfs for your node + Ok that makes sense. How does one program know which translator + it should refer to though? + the read() call magically knows which process to invoke? + the / translator is always known + and then you ask /'s translator about /home, then /home/you, then + /home/you/foobar + it tells you which other translator tyou have to contact + that's on open + It's a tree! Ok. + the notion of fd is then simply knowing the translator + Right. 'file descriptor' is now 'translator address descriptor' + maybe. + it's glibc which knows about FDs, nothing else knows + yes + actually an RPC port, simply + I want to try out the new RPC mechanism that mach implements + err, which "new" RPC ? + mach's RPCs are very old actually :) diff --git a/microkernel/mach/gnumach/memory_management.mdwn b/microkernel/mach/gnumach/memory_management.mdwn index 43b99d83..ca2f42c4 100644 --- a/microkernel/mach/gnumach/memory_management.mdwn +++ b/microkernel/mach/gnumach/memory_management.mdwn @@ -80,3 +80,25 @@ IRC, freenode, #hurd, 2011-06-09 wow i remember the linux support for 4G/4G split when there was enough RAM to fill the kernel space with struct page entries + + +IRC, freenode, #hurd, 2011-11-12 + + well, the Hurd doesn't "artificially" limits itself to 1.5GiB + memory + i386 has only 4GiB addressing space + we currently chose 2GiB for the kernel and 2GiB for the userspace + since kernel needs some mappings, that leaves only 1.5GiB usable + physical memory + Hm? 2GiB for kernel, 2GiB for userspace, 500MiB are used for + what? + for mappings + such as device iomap + contiguous buffer allocation + and such things + Ah, ok. You map things in kernel space into user space then. + linux does the same without the "bigmem" support + no, just in kernel space + kernel space is what determines how much physical memory you can + address + unless using the linux-said-awful "bigmem" support diff --git a/open_issues/anatomy_of_a_hurd_system.mdwn b/open_issues/anatomy_of_a_hurd_system.mdwn index 46526641..13599e19 100644 --- a/open_issues/anatomy_of_a_hurd_system.mdwn +++ b/open_issues/anatomy_of_a_hurd_system.mdwn @@ -87,7 +87,7 @@ RPC stubs. More stuff like [[hurd/IO_path]]. --- +--- IRC, freenode, #hurd, 2011-10-18: @@ -96,3 +96,29 @@ IRC, freenode, #hurd, 2011-10-18: short version: grub loads mach, ext2, and ld.so/exec; mach starts ext2; ext2 starts exec; ext2 execs a few other servers; ext2 execs init. from there on, it's just standard UNIX stuff + +--- + +IRC, OFTC, #debian-hurd, 2011-11-02: + + is __dir_lookup a RPC ?? + where can i find the source of __dir_lookup ?? + grepping most gives out rvalue assignments + -assignments + but in hurs/fs.h it is used as a function ?? + it should be the mig-generated function for that rpc + how do i know how its implemented ?? + is there any way to delve deeprer into mig-generated functions + sekon_: The MIG-generated stuff will either be found in the + package's build directory (if it's building it for themselves), or in the + glibc build directory (libhurduser, libmachuser; which are all the + available user RPC stubs). + sekon_: The implementation can be found in the various Hurd + servers/libraries. + sekon_: For example, [hurd]/libdiskfs/dir-lookup.c. + sekon_: What MIG does is provide a function call interface for + these ``functions'', and the Mach microkernel then dispatches the + invocation to the corresponding server, for example a /hurd/ext2fs file + system (via libdiskfs). + sekon_: This may help a bit: + http://www.gnu.org/software/hurd/hurd/hurd_hacking_guide.html diff --git a/open_issues/ext2fs_page_cache_swapping_leak.mdwn b/open_issues/ext2fs_page_cache_swapping_leak.mdwn index c0d0867b..075533e7 100644 --- a/open_issues/ext2fs_page_cache_swapping_leak.mdwn +++ b/open_issues/ext2fs_page_cache_swapping_leak.mdwn @@ -12,7 +12,10 @@ License|/fdl]]."]]"""]] There is a [[!FF_project 272]][[!tag bounty]] on this task. -IRC, OFTC, #debian-hurd, 2011-03-24 +[[!toc]] + + +# IRC, OFTC, #debian-hurd, 2011-03-24 I still believe we have an ext2fs page cache swapping leak, however as the 1.8GiB swap was full, yet the ld process was only 1.5GiB big @@ -24,7 +27,7 @@ IRC, OFTC, #debian-hurd, 2011-03-24 yes the disk content, basicallyt :) -IRC, freenode, #hurd, 2011-04-18 +# IRC, freenode, #hurd, 2011-04-18 damn, a cp -a simply gobbles down swap space... really ? @@ -173,3 +176,84 @@ IRC, freenode, #hurd, 2011-04-18 backing store of memory objects created from its pager so you can view swap as the file system for everything that isn't an external memory object + + +# IRC, freenode, #hurd, 2011-11-15 + + hm, now my system got unstable + swap is increasing, without any apparent reason + you mean without any load? + with load, yes + :) + well, with load is "normal"... + at least for some loads + i can't create memory pressure to stress reclaiming without any + load + what load are you using? + ftp mirrorring + hm... never tried that; but I guess it's similar to apt-get + so yes, that's "normal". I talked about it several times, and also + wrote to the ML + antrik: ok + if you find out how to fix this, you are my hero ;-) + arg :) + I suspect it's the infamous double swapping problem; but that's + just a guess + looks like this + BTW, if you give me the exact command, I could check if I see it + too + i use lftp (mirror -Re) from a linux git repository + through sftp + (lots of small files, big content) + can't you just give me the exact command? I don't feel like + figuring it out myself + antrik: cd linux-stable; lftp sftp://hurd_addr/ + inside lftp: mkdir linux-stable; cd linux-stable; mirror -Re + hm, half of physical memory just got freed + our page cache is really weird :/ + (i didn't delete any file when that happened) + hurd_addr? + ssh server ip address + or name + of your hurd :) + I'm confused. you are mirroring *from* the Hurd box? + no, to it + ah, so you login via sftp and then push to it? + yes + fragmentation looks very fine + even for the huge pv_entry cache and its 60k+ entries + (and i'm running a kernel with the cpu layer enabled) + git reset/status/diff/log/grep all work correctly + anyway, mcsim's branch looks quite stable to me + braunr: I can't reproduce the swap leak with ftp. free memory + idles around 6.5 k (seems to be the threshold where paging starts), and + swap use is constant + might be because everything swappable is already present in swap + from previous load I guess... + err... scratch that. was connected to the wrong host, silly me + indeed swap gets eaten away, as expected + but only if free memory actually falls below the + threshold. otherwise it just oscillates around a constant value, and + never touches swap + so this seems to confirm the double swapping theory + antrik: is that "double swap" theory written somewhere? + (no, a quick google didn't tell me) + + +## IRC, freenode, #hurd, 2011-11-16 + + youpi: + http://lists.gnu.org/archive/html/l4-hurd/2002-06/msg00001.html talks + about "double paging". probably it's also the term others used for it; + however, the term is generally used in a completely different meaning, so + I guess it's not really suitable for googling either ;-) + IIRC slpz (or perhaps someone else?) proposed a solution to this, + but I don't remember any details + ok so it's the same thing I was thinking about with swap getting + filled + my question was: is there something to release the double swap, + once the ext2fs pager managed to recover? + apparently not + the only way to free the memory seems to be terminating the FS + server + uh :/ diff --git a/open_issues/gnumach_memory_management.mdwn b/open_issues/gnumach_memory_management.mdwn index 9a4418c1..c9c3e64f 100644 --- a/open_issues/gnumach_memory_management.mdwn +++ b/open_issues/gnumach_memory_management.mdwn @@ -1810,3 +1810,205 @@ There is a [[!FF_project 266]][[!tag bounty]] on this task. etenil: but mcsim's work is, for one, useful because the allocator code is much clearer, adds some debugging support, and is smp-ready + + +# IRC, freenode, #hurd, 2011-11-14 + + i've just realized that replacing the zone allocator removes most + (if not all) static limit on allocated objects + as we have nothing similar to rlimits, this means kernel resources + are actually exhaustible + and i'm not sure every allocation is cleanly handled in case of + memory shortage + youpi: antrik: tschwinge: is this acceptable anyway ? + (although IMO, it's also a good thing to get rid of those limits + that made the kernel panic for no valid reason) + there are actually not many static limits on allocated objects + only a few have one + those defined in kern/mach_param.h + most of them are not actually enforced + ah ? + they are used at zinit() time + i thought they were + yes, but most zones are actually fine with overcoming the max + ok + see zone->max_size += (zone->max_size >> 1); + you need both !EXHAUSTIBLE and FIXED + ok + making having rlimits enforced would be nice... + s/making// + pinotree: the kernel wouldn't handle many standard rlimits anyway + + i've just committed my final patch on mcsim's branch, which will + serve as the starting point for integration + which means code in this branch won't change (or only last minute + changes) + you're invited to test it + there shouldn't be any noticeable difference with the master + branch + a bit less fragmentation + more memory can be reclaimed by the VM system + there are debugging features + it's SMP ready + and overall cleaner than the zone allocator + although a bit slower on the free path (because of what's + performed to reduce fragmentation) + but even "slower" here is completely negligible + + +# IRC, freenode, #hurd, 2011-11-15 + + I enabled cpu_pool layer and kentry cache exhausted at "apt-get + source gnumach && (cd gnumach-* && dpkg-buildpackage)" + I mean kernel with your last commit + braunr: I'll make patch how I've done it in a few minutes, ok? It + will be more specific. + mcsim: did you just remove the #if NCPUS > 1 directives ? + no. I replaced macro NCPUS > 1 with SLAB_LAYER, which equals NCPUS + > 1, than I redefined macro SLAB_LAYER + ah, you want to make the layer optional, even on UP machines + mcsim: can you give me the commands you used to trigger the + problem ? + apt-get source gnumach && (cd gnumach-* && dpkg-buildpackage) + mcsim: how much ram & swap ? + let's see if it can handle a quite large aptitude upgrade + how can I check swap size? + free + cat /proc/meminfo + top + whatever + total used free shared buffers + cached + Mem: 786368 332296 454072 0 0 + 0 + -/+ buffers/cache: 332296 454072 + Swap: 1533948 0 1533948 + ok, i got the problem too + braunr: do you run hurd in qemu? + yes + i guess the cpu layer increases fragmentation a bit + which means more map entries are needed + hm, something's not right + there are only 26 kernel map entries when i get the panic + i wonder why the cache gets that stressed + hm, reproducing the kentry exhaustion problem takes quite some + time + braunr: what do you mean? + sometimes, dpkg-buildpackage finishes without triggering the + problem + the problem is in apt-get source gnumach + i guess the problem happens because of drains/fills, which + allocate/free much more object than actually preallocated at boot time + ah ? + ok + i've never had it at that point, only later + i'm unable to trigger it currently, eh + do you use *-dbg kernel? + yes + well, i use the compiled kernel, with the slab allocator, built + with the in kernel debugger + when you run apt-get source gnumach, you run it in clean directory? + Or there are already present downloaded archives? + completely empty + ah just got it + ok the limit is reached, as expected + i'll just bump it + the cpu layer drains/fills allocate several objects at once (64 if + the size is small enough) + the limit of 256 (actually 252 since the slab descriptor is + embedded in its slab) is then easily reached + mcsim: most direct way to check swap usage is vmstat + damn, i can't live without slabtop and the amount of + active/inactive cache memory any more + hm, weird, we have active/inactive memory in procfs, but not + buffers/cached memory + we could set buffers to 0 and everything as cached memory, since + we're currently unable to communicate the purpose of cached memory + (whether it's used by disk servers or file system servers) + mcsim: looks like there are about 240 kernel map entries (i forgot + about the ones used in kernel submaps) + so yes, addin the cpu layer is what makes the kernel reach the + limit more easily + braunr: so just increasing limit will solve the problem? + mcsim: yes + slab reclaiming looks very stable + and unfrequent + (which is surprising) + braunr: "unfrequent"? + pinotree: there isn't much memory pressure + slab_collect() gets called once a minute on my hurd + or is it infrequent ? + :) + i have no idea :) + infrequent, yes + + +# IRC, freenode, #hurd, 2011-11-16 + + for those who want to play with the slab branch of gnumach, the + slabinfo tool is available at http://git.sceen.net/rbraun/slabinfo.git/ + for those merely interested in numbers, here is the output of + slabinfo, for a hurd running in kvm with 512 MiB of RAM, an unused swap, + and a short usage history (gnumach debian packages built, aptitude + upgrade for a dozen of packages, a few git commands) + http://www.sceen.net/~rbraun/slabinfo.out + braunr: numbers for a long usage history would be much more + interesting :-) + + +## IRC, freenode, #hurd, 2011-11-17 + + antrik: they'll come :) + is something going on on darnassus? it's mighty slow + yes + i've rebooted it to run a modified kernel (with the slab + allocator) and i'm building stuff on it to stress it + (i don't have any other available machine with that amount of + available physical memory) + ok + braunr: probably would be actually more interesting to test under + memory pressure... + guess that doesn't make much of a difference for the kernel object + allocator though + antrik: if ram is larger, there can be more objects stored in + kernel space, then, by building something large such as eglibc, memory + pressure is created, causing caches to be reaped + our page cache is useless because of vm_object_cached_max + it's a stupid arbitrary limit masking the inability of the vm to + handle pressure correctly + if removing it, the kernel freezes soon after ram is filled + antrik: it may help trigger the "double swap" issue you mentioned + what may help trigger it? + not checking this limit + hm... indeed I wonder whether the freezes I see might have the + same cause + + +## IRC, freenode, #hurd, 2011-11-19 + + http://www.sceen.net/~rbraun/slabinfo.out <= state of the slab + allocator after building the debian libc packages and removing all files + once done + it's mostly the same as on any other machine, because of the + various arbitrary limits in mach (most importantly, the max number of + objects in the page cache) + fragmentation is still quite low + braunr: actually fragmentation seems to be lower than on the other + run... + antrik: what makes you think that ? + the numbers of currently unused objects seem to be in a similar + range IIRC, but more of them are reclaimable I think + maybe I'm misremembering the other numbers + there had been more reclaims on the other run + + +# IRC, freenode, #hurd, 2011-11-25 + + mcsim: i've just updated the slab branch, please review my last + commit when you have time + braunr: Do you mean compilation/tests? + no, just a quick glance at the code, see if it matches what you + intended with your original patch + braunr: everything is ok + good + i think the branch is ready for integration diff --git a/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn b/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn index 93055b77..80fc9fcd 100644 --- a/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn +++ b/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn @@ -54,3 +54,53 @@ License|/fdl]]."]]"""]] compatibility with eventual 3rd party users is not broken but those using them, other than hurd itself, won't compile anymore, so you fix them progressively + + +# IRC, freenode, #hurd, 2011-11-16 + + is the mach_debug interface packaged in debian ? + what mach_debug interface? + include/include/mach_debug/mach_debug.defs in gnumach + include/mach_debug/mach_debug.defs in gnumach + what exactly is supposed to be packaged there? + i'm talking about the host_*_info client code + braunr: you mean MIG-generated stubs? + antrik: yes + i wrote a tiny slabinfo tool, and rpctrace doesn't show the + host_slab_info call + do you happen to know why ? + braunr: doesn't show it at all, or just doesn't translate? + antrik: doesn't at all, the msgids file contains what's needed to + translate + btw, i was able to build the libc0.3 packages with a kernel using + the slab allocator today, while monitoring it with the aforementioned + slabinfo tool, everything went smoothly + great :-) + i'll probably add a /proc/slabinfo entry some day + and considering the current state of our beloved kernel, i'm + wondering why host_*_info rpcs are considered debugging calls + imo, they should always be included by default + and part of the standard mach interface + (if the rpc is missing, an error is simply returned) + I guess that's been inherited from original Mach + so you think the stubs should be provided by libmachuser? + i'm not sure + actually, it's a bit arguable. if interfaces are not needed by + libc itself, it isn't really necessary to build them as part of the libc + build... + i don't know the complete list of potential places for such calls + OTOH, as any updates will happen in sync with other Mach updates, + it makes sense to keep them in one place, to reduce transition pain + and i didn't want to imply they should be part of libc + on the contrary, libmachuser seems right + libmachuser is part of libc + ah + :) + why so ? + well, for one, libc needs the Mach (and Hurd) stubs itself + also, it's traditionally the role of libc to provide the call + wrappers for syscalls... so it makes some sense + sure, but why doesn't it depend on an external libmachuser instead + of embedding it ? + right + now that's a good question... no idea TBH :-) diff --git a/open_issues/mig_portable_rpc_declarations.mdwn b/open_issues/mig_portable_rpc_declarations.mdwn new file mode 100644 index 00000000..084d7454 --- /dev/null +++ b/open_issues/mig_portable_rpc_declarations.mdwn @@ -0,0 +1,58 @@ +[[!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]]."]]"""]] + +[[!tag open_issue_mig]] + + +# IRC, freenode, #hurd, 2011-11-14 + + also, what's the best way to deal with types such as + type cache_info_t = struct[23] of integer_t; + whereas cache_info_t contains longs, which are obviously not + integer-wide on 64-bits processors + ? + you mean, to port mach to 64bit? + no, to make the RPC declaration portable + just in case :) + refine integer_t into something more precise + such as size_t, off_t, etc. + i can't use a single line then + struct cache_info contains ints, vm_size_t, longs + should i just use the maximum size it can get ? + or declare two sizes depending on the word size ? + well, I'd say three + youpi: three ? + the ints, the vm_size_ts, and the longs + youpi: i don't get it + youpi: how would i write it in mig language ? + I don't know the mig language + me neither :) + but I'd say don't lie + i just see struct[23] of smething + the original zone_info struct includes both integer_t and + vm_size_t, and declares it as + type zone_info_t = struct[9] of integer_t; + in its mig defs file + i don't have a good example to reuse + which is lying + yes + which is why i was wondering if mach architects themselves + actually solved that problem :) + "There is no way to specify the fields of a + C structure to MIG. The size and type-desc are just used to + give the size of + the structure. + " + well, this sucks :/ + well, i'll do what the rest of the code seems to do, and let it + rot until a viable solution is available + braunr: we discussed the problem of expressing structs with MIG in + the libburn thread + (which I still need to follow up on... [sigh]) diff --git a/open_issues/mission_statement.mdwn b/open_issues/mission_statement.mdwn index 212d65e7..d136e3a8 100644 --- a/open_issues/mission_statement.mdwn +++ b/open_issues/mission_statement.mdwn @@ -10,7 +10,10 @@ License|/fdl]]."]]"""]] [[!tag open_issue_documentation]] -IRC, freenode, #hurd, 2011-10-12: +[[!toc]] + + +# IRC, freenode, #hurd, 2011-10-12 we have a mission statement: http://hurd.gnu.org yes @@ -37,3 +40,10 @@ IRC, freenode, #hurd, 2011-10-12: ceases to amaze me I agree that the informational, factual, results oriented documentation is the primary objective of documenting + + +# IRC, freenode, #hurd, 2011-11-25 + + heh, nice: http://telepathy.freedesktop.org/wiki/Rationale + most of this could be read as a rationale for the Hurd just as + well ;-) diff --git a/open_issues/page_cache.mdwn b/open_issues/page_cache.mdwn new file mode 100644 index 00000000..062fb8d6 --- /dev/null +++ b/open_issues/page_cache.mdwn @@ -0,0 +1,73 @@ +[[!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]]."]]"""]] + +[[!tag open_issue_gnumach]] + +IRC, freenode, #hurd, 2011-11-28: + + youpi: would you find it reasonable to completely disable the page + cache in gnumach ? + i'm wondering if it wouldn't help make the system more stable + under memory pressure + assuming cache=writeback in gnumach? + because disabling the page cache will horribly hit performance + no, it doesn't have anything to do with the host + i'm not so sure + while observing the slab allocator, i noticed our page cache is + not used that often + eeh? + apart from the damn 4000 limitation, I've seen it used + (and I don't why it wouldn't be used) + (e.g. for all parts of libc) + ah, no, libc would be kept open by ext2fs + taht's precisely because of the 4k limit + but e.g. .o file emitted during make + well, no + well, see the summary I had posted some time ago, the 4k limit + makes it completely randomized + and thus you lose locality + yes + but dropping the limit would just fix it + that's my point + which I had tried to do, and there were issues, you mentioned why + and (as usual), I haven't had anyu time to have a look at the issue + again + i'm just trying to figure out the pros and cons for having teh + current page cache implementation + but are you saying you tried with a strict limit of 0 ? + non, I'm saying I tried with no limit + but then memory fills up + yes + so trying to garbage collect + i tried that too, the system became unstable very quickly + but refs don't falldown to 0, you said + did i ? + or maybe somebody else + see the list archives + that's possible + i'd imagine someone like sergio lopez + possibly + somebody that knows memory stuff way better than me in any case + youpi: i'm just wondering how much we'd loose by disabling the + page cache, and if we actually gain more stability (and ofc, if it's + worth it) + no idea, measures will tell + fixing the page cache shouldn't be too hard I believe, however + you just need to know what you are doing, which I don't + I do believe the cache is still at least a bit useful + even if dumb because of randomness + e.g. running make lib in the glibc tree gets faster on second time + because the cache wouldbe filled at least randomly with glibc tree + stuff + yes, i agree on that + braunr: btw, the current stability is fine for the buildds + restarting them every few days is ok + so I'd rather keep the performance :) + ok diff --git a/open_issues/perl.mdwn b/open_issues/perl.mdwn index 45680328..48343e3e 100644 --- a/open_issues/perl.mdwn +++ b/open_issues/perl.mdwn @@ -36,6 +36,56 @@ First, make the language functional, have its test suite pass without errors. [[!inline pages=community/gsoc/project_ideas/perl_python feeds=no]] + +## IRC, OFTC, #debian-hurd, 2011-11-08 + + pinotree: so, with your three fixes applied to 5.14.2, there are + still 9 tests failing. They don't seem to be regressions in perl, since + they also fail when I build 5.14.0 (even though the buildd managed it). + What do you suggest as the way forward? + (incidentally I'm trying on strauss's sid chroot to see how that + compares) + Dom: samuel makes buildds build perl with nocheck (otherwise + we'd have no perl at all) + which tests still fail? + ../cpan/Sys-Syslog/t/syslog.t ../cpan/Time-HiRes/t/HiRes.t + ../cpan/autodie/t/recv.t ../dist/IO/t/io_pipe.t ../dist/threads/t/libc.t + ../dist/threads/t/stack.t ../ext/Socket/t/socketpair.t io/pipe.t + op/sigdispatch.t + buildds> I see + ah ok, those that are failing for me even with my patches + I hadn't spotted that the builds were done with nocheck. + (but only sometimes...) + Explains a lot + syslog is kind of non-working on hurd, and syslog.t succeeds in + buildds (as opposted to crash the machine...) because there's no /var/log + in chroots + libc.t appears to succeed too in buildds + * Dom notices how little memory strauss has, and cancels the build, now + that he *knows* that running out of memory caused the crahses + iirc HiRes.t, io_pipe.t , pipe.t and sigdispatch.t fails because + of trobules we have with posix signals + socketpair.t is kind of curious, it seems to block on + socketpair()... + * Dom wonders if a wiki page tracking this would be worthwhile + stack.t fails because we cannot set a different size for pthread + stacks, yet (similar failing test cases are also in the python test + suite) + if there are problems which aren't going to get resolved any time + soon, it may be worth a few SKIPs conditional on architecture, depending + on how serious the issue is + then we'd get better visibility of other/new issues + (problems which aren't bugs in perl, that is) + understandable, yes + i think nobody digged much deeper in the failing ones yet, to + actually classify them as due to glibc/hurd/mach + (eg unlike the pipe behaviour in sysconf.t i reported) + +### 2011-11-26 + + cool, my recvfrom() fix also makes the perl test recv.t pass + + --- diff --git a/open_issues/robustness.mdwn b/open_issues/robustness.mdwn new file mode 100644 index 00000000..d32bd509 --- /dev/null +++ b/open_issues/robustness.mdwn @@ -0,0 +1,64 @@ +[[!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]]."]]"""]] + +[[!tag open_issue_documentation open_issue_hurd]] + + +# IRC, freenode, #hurd, 2011-11-18 + + I'm learning about GNU Hurd and was speculating with a friend + who is also a computer enthusiast. I would like to know if Hurds + microkernel can recover services should they crash? and if it can, does + that recovery code exist in multiple services or just one core kernel + service? + nocturnal: you should read about passive translators + basically, there is no dedicated service to restore crashed + servers + Hi everyone! + services can crash and be restarted, but persistence support is + limited, and rather per serivce + actually persistence is more a side effect than a designed thing + etenil: hello + braunr: translators can also be spawned on an ad-hoc basis, for + instance when accessing a particular file, no? + that's what being passive, for a translator, means + ah yeah I thought so :) + + +# IRC, freenode, #hurd, 2011-11-19 + + will hurd ever have the equivalent of a rs server?, is that + even possible with hurd? + chromaticwt: what is an rs server ? + a reincarnation server + ah, like minix. Well, the main ground issue is restoring existing + information, such as pids of processes, etc. + I don't know how minix manages it + chromaticwt: I have a vision of a session manager that could also + take care of reincarnation... but then, knowing myself, I'll probably + never imlement it + we do get proc crashes from times to times + it'd be cool to see the system heal itself :) + i need a better description of reincarnation + i didn't think it would make core servers like proc able to get + resurrected in a safe way + depends on how it is implemented + I don't know much about Minix, but I suspect they can recover most + core servers + essentially, the condition is to make all precious state be + constantly serialised, and held by some third party, so the reincarnated + server could restore it + should it work across reboots ? + I haven't thought about the details of implementing it for each + core server; but proc should be doable I guess... it's not necessary for + the system to operate, just for various UNIX mechanisms + well, I'm not aware of the Minix implementation working across + reboots. the one I have in mind based on a generic session management + infrastructure should though :-) diff --git a/open_issues/syslog.mdwn b/open_issues/syslog.mdwn index 5fec38b1..2e902698 100644 --- a/open_issues/syslog.mdwn +++ b/open_issues/syslog.mdwn @@ -43,3 +43,30 @@ IRC, freenode, #hurd, 2011-08-08 < youpi> shm should work with the latest libc < youpi> what won't is sysv sem < youpi> (i.e. semget) + + +IRC, OFTC, #debian-hurd, 2011-11-02: + + * pinotree sighs at #645790 :/ + pinotree: W.r.t. 645790 -- yeah, ``someone'' should finally + figure out what's going on with syslog. + http://lists.gnu.org/archive/html/bug-hurd/2008-07/msg00152.html + pinotree: And this... + http://lists.gnu.org/archive/html/bug-hurd/2007-02/msg00042.html + tschwinge: i did that 20 invocations tests recently, and + basically none of them has been logged + tschwinge: when i started playing with logger more, as result i + had some server that started taking all the cpu, followed by other + servers and in the end my ssh connection were dropped and i had nothing + to do (not even login from console) + pinotree: Sounds like ``fun''. Hopefully we can manage to + understand (and fix the underlying issue) why a simple syslog() + invocation can make the whole system instable. + tschwinge: to be honest, i got havoc in the system when i told + syslog to manually look for /dev/log (-u /dev/log), possibly alao when + telling to use a datagram socket (-d) + but even if a normal syslog() invocation does not cause havoc, + there's still the "lost messages" issue + Yep. What I've been doing ever since, is deinstall all + *syslog* packages. + This ``fixed'' all syslog() hangs. diff --git a/open_issues/translator_stdout_stderr.mdwn b/open_issues/translator_stdout_stderr.mdwn index 11793582..14ea1c6d 100644 --- a/open_issues/translator_stdout_stderr.mdwn +++ b/open_issues/translator_stdout_stderr.mdwn @@ -11,11 +11,43 @@ License|/fdl]]."]]"""]] [[!tag open_issue_hurd]] +There have been several discussions and proposals already, about adding a +suitable logging mechanism to translators, for example. + + Decide / implement / fix that (all?) running (passive?) translators' output should show up on the (Mach / Hurd) console / syslog. + [[!taglink open_issue_documentation]]: [[!message-id "87oepj1wql.fsf@becket.becket.net"]] + [[!taglink open_issue_documentation]]: Neal once had written an email on this topic. + + +IRC, freenode, #hurd, 2011-11-06 + + about CLI_DEBUG, you can use #define CLI_DEBUG(fmt, ...) { + fprintf(stderr, fmt, ## __VA_ARGS__); fflush(stderr); } + Isn't stderr in auto-flush mode by default? + man setbuf: The standard error stream stderr is always + unbuffered by default. + tschwinge: "by default" is the important thing here + in the case of translators iirc stderr is buffered + youpi: Oh! + That sounds wrong. + + +IRC, freenode, #hurd, 2011-11-23 + + we'd need a special logging task for hurd servers + if syslog would work, that could be used optionally + no, it relies on services provided by the hurd + i'm thinking of something using merely the mach interface + e.g. using mach_msg to send log messages to a special port used to + reference the logging service + which would then store the messages in a circular buffer in ram + maybe sending to syslog if the service is available + the hurd system buffer if you want -- cgit v1.2.3 From 5047f4849f52efbd11fcfe5d7ce1b37c4bec6134 Mon Sep 17 00:00:00 2001 From: RussJames Date: Tue, 6 Dec 2011 06:32:05 +0100 Subject: --- hurd/running/gnu/universal_package_manager.mdwn | 1 + 1 file changed, 1 insertion(+) (limited to 'hurd') diff --git a/hurd/running/gnu/universal_package_manager.mdwn b/hurd/running/gnu/universal_package_manager.mdwn index 58841b02..bf1b92e0 100644 --- a/hurd/running/gnu/universal_package_manager.mdwn +++ b/hurd/running/gnu/universal_package_manager.mdwn @@ -155,3 +155,4 @@ To join the project just list your name below. 8. Abhradip Mukherjee 9. Ermenegildo Fiorito 10. Oltion Doda + 11. Russell James -- cgit v1.2.3