From 4783879860edac5ecf458f305e4872a05f01ef58 Mon Sep 17 00:00:00 2001 From: Justus Winter Date: Wed, 12 Oct 2016 10:16:15 +0200 Subject: Update URLs to local git repositories --- community/gsoc/project_ideas/object_lookups.mdwn | 14 +++++++------- hurd/translator/mtab/discussion.mdwn | 6 +++--- open_issues/automatically_checking_port_deallocation.mdwn | 2 +- open_issues/robustness.mdwn | 4 ++-- open_issues/virtualization/fakeroot.mdwn | 2 +- 5 files changed, 14 insertions(+), 14 deletions(-) diff --git a/community/gsoc/project_ideas/object_lookups.mdwn b/community/gsoc/project_ideas/object_lookups.mdwn index d67dbe20..43bed087 100644 --- a/community/gsoc/project_ideas/object_lookups.mdwn +++ b/community/gsoc/project_ideas/object_lookups.mdwn @@ -265,7 +265,7 @@ In context of [[!message-id "20130918081345.GA13789@dalaran.sceen.net"]]. let me push it somewhere, so I can show you the patches ok braunr: - http://darnassus.sceen.net/gitweb/teythoon/gnumach.git/shortlog/refs/heads/feature-protected-payload-1 + http://darnassus.sceen.net/cgit/teythoon/gnumach.git/shortlog/refs/heads/feature-protected-payload-1 teythoon: where should i look at ? the last commit hm @@ -290,7 +290,7 @@ In context of [[!message-id "20130918081345.GA13789@dalaran.sceen.net"]]. right, I can see how that could work mach_reply_port(); mach_port_set_payload(); mach_msg(); braunr: - http://darnassus.sceen.net/gitweb/teythoon/gnumach.git/log/refs/heads/feature-protected-payload-2 + http://darnassus.sceen.net/cgit/teythoon/gnumach.git/log/refs/heads/feature-protected-payload-2 I think I found the right spot teythoon: looks better indeed :) braunr: yes, thanks for the hint :) @@ -378,11 +378,11 @@ In context of [[!message-id "20130918081345.GA13789@dalaran.sceen.net"]]. no, no deb ok braunr: - http://darnassus.sceen.net/gitweb/teythoon/gnumach.git/log/refs/heads/feature-protected-payload-3 + http://darnassus.sceen.net/cgit/teythoon/gnumach.git/log/refs/heads/feature-protected-payload-3 - http://darnassus.sceen.net/gitweb/teythoon/hurd.git/log/refs/heads/feature-protected-payload-1 + http://darnassus.sceen.net/cgit/teythoon/hurd.git/log/refs/heads/feature-protected-payload-1 braunr: in particular, - http://darnassus.sceen.net/gitweb/teythoon/hurd.git/blob/refs/heads/feature-protected-payload-1:/libports/manage-multithread.c#l161 + http://darnassus.sceen.net/cgit/teythoon/hurd.git/blob/refs/heads/feature-protected-payload-1:/libports/manage-multithread.c#l161 ## IRC, freenode, #hurd, 2013-11-27 @@ -396,13 +396,13 @@ In context of [[!message-id "20130918081345.GA13789@dalaran.sceen.net"]]. sure ok first, please look at this - http://darnassus.sceen.net/gitweb/teythoon/hurd.git/blob/refs/heads/feature-protected-payload-1:/libports/manage-multithread.c#l161 + http://darnassus.sceen.net/cgit/teythoon/hurd.git/blob/refs/heads/feature-protected-payload-1:/libports/manage-multithread.c#l161 in line 165, the msgh_local_port is restored b/c later some intrans function might use this for the object (re-)lookup yes ok - http://darnassus.sceen.net/gitweb/teythoon/mig.git/commitdiff/64b7d34f90a41d017a9e1e8179c0533a97012f6f + http://darnassus.sceen.net/cgit/teythoon/mig.git/commitdiff/64b7d34f90a41d017a9e1e8179c0533a97012f6f makes sense this makes mig payload aware we'd specify another intrans function that takes a label and diff --git a/hurd/translator/mtab/discussion.mdwn b/hurd/translator/mtab/discussion.mdwn index 715884ce..952c0825 100644 --- a/hurd/translator/mtab/discussion.mdwn +++ b/hurd/translator/mtab/discussion.mdwn @@ -1107,7 +1107,7 @@ In context of [[open_issues/mig_portable_rpc_declarations]]. ok only send-once rights have their own names btw, I'll push my work to darnassus from now on, - e.g. http://darnassus.sceen.net/gitweb/?p=teythoon/hurd.git;a=shortlog;h=refs/heads/feature-mtab-translator-v3-wip + e.g. http://darnassus.sceen.net/cgit/?p=teythoon/hurd.git;a=shortlog;h=refs/heads/feature-mtab-translator-v3-wip ### IRC, freenode, #hurd, 2013-11-20 @@ -2518,7 +2518,7 @@ Fixed in 2013-10-05 procfs commit c87688a05a8b49479ee10127470cc60acebead4a? push that work in a branch somewhere for review please right, thanks braunr: - http://darnassus.sceen.net/gitweb/teythoon/hurd.git/shortlog/refs/heads/feature-translatorslist-detect-passive-translators + http://darnassus.sceen.net/cgit/teythoon/hurd.git/shortlog/refs/heads/feature-translatorslist-detect-passive-translators ### IRC, freenode, #hurd, 2014-01-04 @@ -2539,7 +2539,7 @@ Fixed in 2013-10-05 procfs commit c87688a05a8b49479ee10127470cc60acebead4a? ! where are they again ? - http://darnassus.sceen.net/gitweb/teythoon/hurd.git/shortlog/refs/heads/feature-translatorslist-detect-passive-translators + http://darnassus.sceen.net/cgit/teythoon/hurd.git/shortlog/refs/heads/feature-translatorslist-detect-passive-translators ok they are reasonably straight-forward but cause this funny issue, after the first reboot with the diff --git a/open_issues/automatically_checking_port_deallocation.mdwn b/open_issues/automatically_checking_port_deallocation.mdwn index 6aeaf207..e8a4389e 100644 --- a/open_issues/automatically_checking_port_deallocation.mdwn +++ b/open_issues/automatically_checking_port_deallocation.mdwn @@ -29,4 +29,4 @@ a recompilation of the code that contains the port leak. Currently, it is a prototype. If you are looking for a port leak, I'd love you to try it though: -[[http://darnassus.sceen.net/gitweb/teythoon/portseal.git]] +[[http://darnassus.sceen.net/cgit/teythoon/portseal.git]] diff --git a/open_issues/robustness.mdwn b/open_issues/robustness.mdwn index 4b0cdc9b..3ba9bb3d 100644 --- a/open_issues/robustness.mdwn +++ b/open_issues/robustness.mdwn @@ -138,7 +138,7 @@ License|/fdl]]."]]"""]] < teythoon> I came across some paper about process reincarnation and created a little prototype a while back: - < teythoon> http://darnassus.sceen.net/gitweb/teythoon/reincarnation.git/ + < teythoon> http://darnassus.sceen.net/cgit/teythoon/reincarnation.git/ < teythoon> and I looked into restarting the exec server in case it dies. the exec server is an easy target since it has no state of its own < teythoon> the only problem is that there is no exec server around to @@ -166,7 +166,7 @@ License|/fdl]]."]]"""]] < teythoon> braunr: the server can store a checkpoint using the reincarnation_checkpoint procedure < teythoon> - http://darnassus.sceen.net/gitweb/teythoon/reincarnation.git/blame/HEAD:/reincarnation.defshttp://darnassus.sceen.net/gitweb/teythoon/reincarnation.git/blame/HEAD:/reincarnation.defs + http://darnassus.sceen.net/cgit/teythoon/reincarnation.git/blame/HEAD:/reincarnation.defshttp://darnassus.sceen.net/cgit/teythoon/reincarnation.git/blame/HEAD:/reincarnation.defs < teythoon> uh >,< sorry, pasted twice < braunr> oh ok diff --git a/open_issues/virtualization/fakeroot.mdwn b/open_issues/virtualization/fakeroot.mdwn index 441d5c13..b8604ff7 100644 --- a/open_issues/virtualization/fakeroot.mdwn +++ b/open_issues/virtualization/fakeroot.mdwn @@ -480,7 +480,7 @@ License|/fdl]]."]]"""]] that must be new then might be, yes - http://darnassus.sceen.net/gitweb/teythoon/packaging/hurd.git/blame/HEAD:/debian/patches/libports_stability.patch + http://darnassus.sceen.net/cgit/teythoon/packaging/hurd.git/blame/HEAD:/debian/patches/libports_stability.patch antrik: debian currently disables both the global and thread timeouts in libports my work on thread destruction consists in part in reenabling -- cgit v1.2.3 From 0ca46c502ac0f37d818d9b8c4748b8189c31a1c3 Mon Sep 17 00:00:00 2001 From: Justus Winter Date: Wed, 12 Oct 2016 11:44:57 +0200 Subject: Add link to recent discussion --- microkernel/mach/gnumach/projects/mach_5.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/microkernel/mach/gnumach/projects/mach_5.mdwn b/microkernel/mach/gnumach/projects/mach_5.mdwn index a4236ea5..b90f04d5 100644 --- a/microkernel/mach/gnumach/projects/mach_5.mdwn +++ b/microkernel/mach/gnumach/projects/mach_5.mdwn @@ -134,4 +134,4 @@ A prototype exists. ### Discussions * - +* -- cgit v1.2.3 From c97ee062c33ec8cbd90d6e98ee68c68e75697d69 Mon Sep 17 00:00:00 2001 From: Justus Winter Date: Wed, 12 Oct 2016 10:10:19 +0200 Subject: Add interface for user-space drivers --- microkernel/mach/gnumach/projects/mach_5.mdwn | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/microkernel/mach/gnumach/projects/mach_5.mdwn b/microkernel/mach/gnumach/projects/mach_5.mdwn index b90f04d5..7b59170b 100644 --- a/microkernel/mach/gnumach/projects/mach_5.mdwn +++ b/microkernel/mach/gnumach/projects/mach_5.mdwn @@ -19,6 +19,8 @@ it, we could straighten out some of these problems. This page is a place to keep track of such changes. +[[!toc startlevel=2 levels=1]] + ## Protected payloads Protected payloads are a way of optimizing the receiver object lookup @@ -135,3 +137,27 @@ A prototype exists. * * + +## Interface for userspace drivers + +We need to provide an interface suitable for implementing drivers in +userspace: + +* A way to handle interrupts +* and a way to allocate memory suitable for DMA buffers + +### Required ABI changes + +None. This is a new interface. Debian/Hurd uses a non-standard rpc +id, so we do not change an existing procedure there. + +### Status + +A DDE-based solution is used in Debian/Hurd to provide network +drivers. A rump kernel prototype is implemented. These use a kernel +interface written by Zheng Da available in the +"master-user_level_drivers" branch in the GNU Mach repository. + +### Discussions + +* -- cgit v1.2.3 From 3aecdf641b91ac9a805a998f2851f119b9237953 Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Sun, 9 Oct 2016 00:34:57 +0200 Subject: llvm gets stuck --- open_issues/problematic_packages.mdwn | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/open_issues/problematic_packages.mdwn b/open_issues/problematic_packages.mdwn index 0c71d3d1..444350f0 100644 --- a/open_issues/problematic_packages.mdwn +++ b/open_issues/problematic_packages.mdwn @@ -29,6 +29,10 @@ This page lists the few packages whose build makes the Debian buildd box crash a * icedove +* box gets stuck + + * llvm-toolchain-3.7 + * ext2fs gets stuck * emacs24 -- cgit v1.2.3 From 048d155b38321415cc19320f31c28ae4efaec589 Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Tue, 1 Nov 2016 15:57:30 +0100 Subject: Document bogus port issue at boot --- open_issues/increasing_bogus_port_at_boot.mdwn | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) create mode 100644 open_issues/increasing_bogus_port_at_boot.mdwn diff --git a/open_issues/increasing_bogus_port_at_boot.mdwn b/open_issues/increasing_bogus_port_at_boot.mdwn new file mode 100644 index 00000000..9851557c --- /dev/null +++ b/open_issues/increasing_bogus_port_at_boot.mdwn @@ -0,0 +1,26 @@ +[[!meta copyright="Copyright © 2016 Free Software +Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_porting]] + +When the ntpdate package is installed, one gets at boot something like: + + Debian GNU/Hurd stretch/sid debian console + task ext2fs increasing a bogus port 947 by 1, most probably a bug. + task ext2fs increasing a bogus port 947 by 1, most probably a bug. + task ext2fs deallocating a bogus port 947, most probably a bug. + task ext2fs deallocating a bogus port 947, most probably a bug. + login: + +This is coming from the execution of the shell script +/etc/network/if-up.d/ntpdate, whose stdout/stderr is on the Mach console, but +part of which gets executed after getty starts on it. It happens that getty uses +revoke() to revoke access to it from other programs, and thus the ntpdate shell scripts gets its stdout/stderr in a bogus state, which libc doesn't really cope with correctly. -- cgit v1.2.3 From 4cfda129ef88e09f6af76549d0474ad0c8b5a413 Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Tue, 1 Nov 2016 15:58:42 +0100 Subject: document workaround --- open_issues/increasing_bogus_port_at_boot.mdwn | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/open_issues/increasing_bogus_port_at_boot.mdwn b/open_issues/increasing_bogus_port_at_boot.mdwn index 9851557c..483b2844 100644 --- a/open_issues/increasing_bogus_port_at_boot.mdwn +++ b/open_issues/increasing_bogus_port_at_boot.mdwn @@ -23,4 +23,9 @@ When the ntpdate package is installed, one gets at boot something like: This is coming from the execution of the shell script /etc/network/if-up.d/ntpdate, whose stdout/stderr is on the Mach console, but part of which gets executed after getty starts on it. It happens that getty uses -revoke() to revoke access to it from other programs, and thus the ntpdate shell scripts gets its stdout/stderr in a bogus state, which libc doesn't really cope with correctly. +revoke() to revoke access to it from other programs, and thus the ntpdate shell +scripts gets its stdout/stderr in a bogus state, which libc doesn't really cope +with correctly. + +Commenting `c:23:respawn:/sbin/getty 38400 console` from `/etc/inittab` works +around the issue (but removes the getty from the Mach console) -- cgit v1.2.3 From f4cef8f2cd3c61e50c72bdc770c8d4f4a6c20563 Mon Sep 17 00:00:00 2001 From: Justus Winter Date: Mon, 7 Nov 2016 00:46:26 +0100 Subject: Update the subhurd howto. --- hurd/subhurd.mdwn | 68 ++++++++++++++++++++++++------------------------------- 1 file changed, 29 insertions(+), 39 deletions(-) diff --git a/hurd/subhurd.mdwn b/hurd/subhurd.mdwn index e50ea0d5..13756339 100644 --- a/hurd/subhurd.mdwn +++ b/hurd/subhurd.mdwn @@ -19,7 +19,8 @@ attach to them with gdb from the parent when the instance of gdb stops the server but requires its use. (Note: it is possible to use [[debugging/gdb/noninvasive_debugging]], but this is less flexible.) Vice versa, it is also possible to use a subhurd to debug the -*main* Hurd system, for example, the latter's root file system. +*main* Hurd system, for example, the latter's root file system, but that +requires a privileged subhurd. [[!toc levels=2]] @@ -60,53 +61,40 @@ run the `native-install` step from a chroot or already in a subhurd.) ## Booting -To boot the subhurd, you need a boot script. For historical reasons, usually -`/boot/servers.boot` is used. (Originally, this was also used to boot the main -Hurd, using "serverboot". Nowadays, this isn't used for the main boot anymore, -as GRUB can directly load all the necessary modules.) +If you are using a recent version of the Hurd (>= 0.9), then you can +simply boot the subhurd as an unprivileged user by issuing -However, the canonical `/boot/servers.boot` file is no longer distributed with -[[Debian_GNU/Hurd|running/debian]]. Here is a slightly adopted version: - - # Boot script file for booting GNU Hurd. Each line specifies a file to be - # loaded by the boot loader (the first word), and actions to be done with it. - - # First, the bootstrap filesystem. It needs several ports as arguments, - # as well as the user flags from the boot loader. - /hurd/ext2fs.static --bootflags=${boot-args} --host-priv-port=${host-port} --device-master-port=${device-port} --exec-server-task=${exec-task} -Tdevice ${root-device} $(task-create) $(task-resume) - - # Now the exec server; to load the dynamically-linked exec server program, - # we have the boot loader in fact load and run ld.so, which in turn - # loads and runs /hurd/exec. This task is created, and its task port saved - # in ${exec-task} to be passed to the fs above, but it is left suspended; - # the fs will resume the exec task once it is ready. - /lib/ld.so.1 /hurd/exec $(exec-task=task-create) - - ## default pager - #/dev/sd0b $(add-paging-file) - -/!\ It's very important not to introduce spurious line breaks, so be very -careful when copying! All the options following `ext2fs.static` have to be on -a single line. - -Now actually booting the subhurd is a simple matter of issuing (as root): - - boot servers.boot /dev/hd0s6 + boot /dev/hd0s6 (Replace `hd0s6` by the name of your partition for the subhurd.) /!\ The partition must be unmounted (or mounted read-only) before you boot from it! -(In theory it shouldn't be neccessary to run the subhurd as user `root`, but in -practice [that doesn't work at the -moment](http://savannah.gnu.org/bugs/?17341).) +## Networking You can provide the subhurd with a network card by passing a `-f` option to `boot`. For instance, if you have a second network card `/dev/eth1` in your host hurd, pass `-f eth0=/dev/eth1` to make it appear as device eth0 in the subhurd. +If you don't have a second network card, you can setup the eth-multiplexer +to share one network card. To do so, install the multiplexer + + settrans /dev/eth0m /hurd/eth-multiplexer --interface=/dev/eth0 + +Then configure your main Hurd system to use a virtual network +interface (e.g. `/dev/eth0m/0`) instead. On Debian/Hurd, this can be +accomplished using + + ifdown /dev/eth0 + sed -i -e s#/dev/eth0#/dev/eth0m/0# /etc/network/interfaces + ifup /dev/eth0m/0 + +You can now pass `-f eth0=/dev/eth0m/1` to `boot`. + +## Booting and shutting down + Now the subhurd should boot just like a normal Hurd started directly from GRUB, finally presenting a login prompt. The `boot` program serves as proxy for the subhurd, so you can control it from the terminal where you issued the boot @@ -114,9 +102,9 @@ command. To exit the subhurd, issue `halt` or `reboot`. This should exit it cleanly, but for some reason it doesn't always work; sometimes it will output various -errors and then hang. If that happens, you need to kill the subhurd processes -manually from a different terminal. - +errors and then hang. If that happens, you need to kill the `boot` process +manually from a different terminal. If the `boot` process dies, the +proc server will kill all tasks belonging to the Subhurd. ## Using @@ -132,7 +120,7 @@ If you want to access the subhurd processes from the outside, e.g. for [[debugging_purposes|debugging/subhurd]] (or to get rid of a subhurd that didn't exit cleanly...), you need to find out how main Hurd [[PID]]s correspond to subhurd processes: the subhurd processes appear in the main Hurd (e.g. if doing -`ps -e`) as unknown processes, and vice versa, but the [[PID]]s are different! To +`ps -e`) as unknown processes, but the [[PID]]s are different! To find out which process is which, you can simply compare the order -- while the numbers are different, the order should usually match. Often it also helps to look at the number of threads (e.g. using `ps -l`), as many servers have very @@ -510,6 +498,8 @@ Roland's tutorial about [[running_a_subhurd]]. ## Debugging the *Main* Hurd System +Note: This only works with privileged subhurds. + A subhurd can be used for debugging the *main* Hurd system. This works as long as the subhurd doesn't use any services provided by the main Hurd. For example, if you already have a subhurd running at the time it happens, you can -- cgit v1.2.3