diff options
169 files changed, 3039 insertions, 3463 deletions
diff --git a/Hurd/HurdDevelopers.mdwn b/Hurd/HurdDevelopers.mdwn index 908ebb04..02b48ab4 100644 --- a/Hurd/HurdDevelopers.mdwn +++ b/Hurd/HurdDevelopers.mdwn @@ -9,27 +9,32 @@ License|/fdl]]."]]"""]] [[!meta title="Hurd Developers"]] The Hurd has very few people working on it. This is a list of people who are large contributors to the project. -<!-- Who the heck is the current maintainer, anyway? Schwinge? Thibault? --> -* Thomas Schwinge - Maintainer -* Samuel Thibault - Developer -* Joshual Branson - Developer -* Justus Winter - Developer +* Samuel Thibault - Maintainer +* Joshua Branson - Documentation +* Sergey Bugaev - 64 bit port and security fixes +* Flávio Cruz - Mach IPC improvements +* Luca Dariz - 64 bit port +* Almudena Garcia - SMP work and hardware tester * Joan Lledó - PCI arbiter and lwip port -* Damien Zammit - ACPI arbiter -* Svante Signell - pfinet/fakeroot fixes -* Flávio Cruz - fixes -* Manolis Ragkousis - Hurd support for Guix +* Svante Signell - file record locking, ada/gnat/go port, owner of mahler buildd +* Damien Zammit - ACPI arbiter, SMP, and rumpkernel Here is a list of people who were large contributors: -* Zheng Da - netdde -* Jeremie Koenig - Debian installer -* Marcus Brinkman - Co-author of the Critique -* Neal H. Walfield - Co-author of the Critique -* Richard Braun - Owner of darnassus.sceen.net * Miles Bader - Original developer +* Richard Braun - MM hacker, owner of darnassus, ironforge buildd, exodar +* Marcus Brinkman - Co-author of the Critique * Thomas Bushnell - Original maintainer +* Zheng Da - netdde +* Jeremie Koenig - Debian installer * Roland McGrath - Original maintainer +* Manolis Ragkousis - Hurd support for Guix +* Marin Ramesa - Cleanups +* Guillem Jover - 64 bit port +* Thomas Schwinge - Previous Maintainer +* Pino Toscano - Portability fixes +* Neal H. Walfield - Co-author of the Critique, libpthread +* Justus Winter - Developer [See the full list at Savannah](https://savannah.gnu.org/project/memberlist.php?group=hurd) diff --git a/community/gsoc/2012/virt/discussion.mdwn b/community/gsoc/2012/virt/discussion.mdwn index e0085322..11c33e52 100644 --- a/community/gsoc/2012/virt/discussion.mdwn +++ b/community/gsoc/2012/virt/discussion.mdwn @@ -176,7 +176,7 @@ License|/fdl]]."]]"""]] <tschwinge> Exactly that is the abstraction level you need, yes. <nowhereman> I'm looking at http://savannah.gnu.org/git/?group=hurd <tschwinge> Yeah, that's a known shortcoming -- look here instead: - http://git.savannah.gnu.org/cgit/hurd + https://git.savannah.gnu.org/cgit/hurd <tschwinge> Here is some more up-to-date stuff on subhurds: http://www.gnu.org/software/hurd/hurd/subhurd.html <tschwinge> nowhereman: You know how to tell git to add a new remote to diff --git a/community/gsoc/2013/hacklu.mdwn b/community/gsoc/2013/hacklu.mdwn index 4da3dde9..e5ef2920 100644 --- a/community/gsoc/2013/hacklu.mdwn +++ b/community/gsoc/2013/hacklu.mdwn @@ -1028,7 +1028,7 @@ In context of [[open_issues/libpthread/t/fix_have_kernel_resources]]: <hacklu> is libpthread a part of glibc or hurd? <pinotree> glibc <NlightNFotis> hacklu: it is a different repository available here - http://git.savannah.gnu.org/cgit/hurd/libpthread.git/ + https://git.savannah.gnu.org/cgit/hurd/libpthread.git/ <hacklu> tschwinge: thanks for that, but I don't think I need help about the comiler error now, it just say missing some C file. I will look into the Makefile to verify. @@ -1044,7 +1044,7 @@ In context of [[open_issues/libpthread/t/fix_have_kernel_resources]]: <hacklu> tschwinge:BTW, I have found that, to continue the inferior from a breakpoint, doesn't need to call msg_sig_post_untraced. just call thread_abort and thread_resume is already ok. - <hacklu> I get the glibc from http://git.savannah.gnu.org/cgit/hurd. + <hacklu> I get the glibc from https://git.savannah.gnu.org/cgit/hurd. <tschwinge> hacklu: That sounds about right, because you want the inferior to continue normally, instead of explicitly sending a (Unix) signal to it. diff --git a/community/gsoc/organization_application.mdwn b/community/gsoc/organization_application.mdwn index 8e672af1..756570d2 100644 --- a/community/gsoc/organization_application.mdwn +++ b/community/gsoc/organization_application.mdwn @@ -129,7 +129,7 @@ bug-hurd@gnu.org ( http://lists.gnu.org/mailman/listinfo/bug-hurd ) * What is the main IRC channel for your organization? -\#hurd on freenode.net +\#hurd on libera.chat * Does your organization have an application template you would like to see students use? If so, please provide it now. Please note that it is a very good idea to ask students to provide you with their contact information as part of your template. Their contact details will not be shared with you automatically via the GSoC 2010 site. diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn index 0eab01c1..c68cfd66 100644 --- a/community/gsoc/project_ideas.mdwn +++ b/community/gsoc/project_ideas.mdwn @@ -98,7 +98,8 @@ All project ideas inlined: project_ideas: - "community/gsoc/project_ideas/virtualization + "community/gsoc/project_ideas/rust + community/gsoc/project_ideas/virtualization community/gsoc/project_ideas/secure_chroot community/gsoc/project_ideas/package_manager community/gsoc/project_ideas/driver_glue_code diff --git a/community/gsoc/project_ideas/download_backends.mdwn b/community/gsoc/project_ideas/download_backends.mdwn index c0bdc5b2..236f1751 100644 --- a/community/gsoc/project_ideas/download_backends.mdwn +++ b/community/gsoc/project_ideas/download_backends.mdwn @@ -29,11 +29,11 @@ redirects etc.) A new interface providing all this additional information (either as an extension to the existing translators, or as distinct translators) is required -to make such translators usable as backends for programs like apt-get for +to make such translators usable as backends for programs like apt for example. The goal of this project is to design a suitable interface, implement it for at -least one download protocol, and adapt apt-get (or some other program) to use +least one download protocol, and adapt apt (or some other program) to use this as a backend. This task requires some design skills and some knowledge of internet protocols, diff --git a/community/gsoc/project_ideas/driver_glue_code.mdwn b/community/gsoc/project_ideas/driver_glue_code.mdwn index db1816c9..3d0a9192 100644 --- a/community/gsoc/project_ideas/driver_glue_code.mdwn +++ b/community/gsoc/project_ideas/driver_glue_code.mdwn @@ -27,7 +27,7 @@ This is [[!GNU_Savannah_task 5488]]. [[open issues/user-space device drivers]]. [[open issues/device drivers and io systems]]. -The most promising approach for getting newer drivers seems to be the [[Rump_kernel]]: +The most promising approach for getting newer drivers seems to be the [[rump kernel|hurd/rump]]: it already does the hard work of providing an environment where the foreign drivers can run, and offers the additional benefit of being externally maintained. diff --git a/community/gsoc/project_ideas/file_locking.mdwn b/community/gsoc/project_ideas/file_locking.mdwn index a368a7a8..602c643e 100644 --- a/community/gsoc/project_ideas/file_locking.mdwn +++ b/community/gsoc/project_ideas/file_locking.mdwn @@ -15,7 +15,7 @@ License|/fdl]]."]]"""]] --- -This is no longer valid as a Google Summer of Code project."""]] +Svante Signell revived the patch and fixed it, it is now committed"""]] Over the years, [[UNIX]] has acquired a host of different file locking mechanisms. diff --git a/community/gsoc/project_ideas/gdb.mdwn b/community/gsoc/project_ideas/gdb.mdwn index e5c279b7..1cac960c 100644 --- a/community/gsoc/project_ideas/gdb.mdwn +++ b/community/gsoc/project_ideas/gdb.mdwn @@ -23,7 +23,7 @@ to be integrated first."""]] [[/GDB]] is available and working on GNU Hurd. However, there are some bugs and there is missing functionality compared to a port targeting the Linux kernel ([[tag/Open_Issue_GDB]], [diff of -testresults](http://git.savannah.gnu.org/cgit/hurd/web.git/tree/gdb/test.diff?h=toolchain/logs/master)). +testresults](https://git.savannah.gnu.org/cgit/hurd/web.git/tree/gdb/test.diff?h=toolchain/logs/master)). For example, there is no port of [[open_issues/gdb/gdbserver]] available yet. Identifying (together with the mentors), and then addressing one or a few of these items is the goal of this project. diff --git a/community/gsoc/project_ideas/libcap/details.mdwn b/community/gsoc/project_ideas/libcap/details.mdwn index 85695978..cfbec632 100644 --- a/community/gsoc/project_ideas/libcap/details.mdwn +++ b/community/gsoc/project_ideas/libcap/details.mdwn @@ -586,11 +586,11 @@ The replacing work could then be made a more gradual process. Steps: iouser as mentioned in the details. * fsys_getroot. Implement fsys_getroot_caps in libdiskfs, trans, - libtreefs, libtrivs, libnetfs. Fix users of function in libdiskfs, - libfshelp, settrans, libtreefs, clookup. + libtrivs, libnetfs. Fix users of function in libdiskfs, + libfshelp, settrans, clookup. * io_restrict_auth. Implement io_restrict_auth_caps in libdiskfs, - libtreefs, libtrivfs, libnetfs, boot. Fix users in utils(symlink, + libtrivfs, libnetfs, boot. Fix users in utils(symlink, firmlink), libtrivs, term, clookup Among the problems might be that there are a lot of arguments that diff --git a/community/gsoc/project_ideas/rust.mdwn b/community/gsoc/project_ideas/rust.mdwn new file mode 100644 index 00000000..f6be8132 --- /dev/null +++ b/community/gsoc/project_ideas/rust.mdwn @@ -0,0 +1,214 @@ +[[!meta copyright="Copyright © 2023 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="Porting Rust"]] + +[[!template id=highlight text="""/!\ Obsolete /!\ + +--- + +Vedant Tewari has been working on this as a Google Summer of Code 2023 project."""]] + +The goal of this project is to make the [Rust +language](https://www.rust-lang.org/) available on GNU/Hurd. + +Presumably less work will be needed on the language's frontend itself, but +rather on the supporting libraries. + + +The Rust language is being used more and more widely, and notably in +rather fundamental libraries such as librsvg or python-cryptography. It +is thus more and more pressing for GNU/Hurd to have a compiler for Rust. + +The Rust compiler itself is quite portable, but its runtime library, libstd, +needs to be ported to the GNU/Hurd system. This essentially consists in telling +Rust how the standard C library functions can be called, i.e. the C ABI. + +There as an [initial attempt against rustc 1.30](https://people.debian.org/~sthibault/hurd-i386/rustc-1.30-patch) that was enough to get rustc +to crossbuild, but it was missing most of what libstd needs. It is most probably +very outdated nowadays, but that gives an idea. + +An example of the main part of the libstd port can be seen for the [VxWorks +port](https://github.com/rust-lang/libc/blob/master/src/vxworks/mod.rs) + +The bulk of such a file can be mostly generated from the libc C +headers thanks to the bindgen tool, it then needs to be cleaned up and +integrated into the Rust build infrastructure, some preliminary work had +already been investigated in that part. + +A good level of C programming will be welcome to understand the +questions of ABI and the libc C functions being bound. + +Knowing the Rust language is not required: it can be learnt along the +way, this can be a good occasion. + +Possible mentors: [[Samuel Thibault (youpi)|samuelthibault]] samuel.thibault@gnu.org + +For somebody who has already a very good level of C programming and good Rust +programming skills, this can probably be a 175-hour project. Otherwise it will +be a good occasion to learn, and can then be a 350-hour project. + +It is expected to be of medium difficulty: a fair part of the port is about +mimicing other ports. Deciding how to mimic can be discussed with the community +anyway. The other part is about expressing the C ABI. This requires to properly +understand what that means, but once that is understood, it should be relatively +straightforward to implement. + +You can contact the bug-hurd@gnu.org mailing list to discuss about this project. + +Bonding exercise: Building the Debian rustc package on Debian GNU/Linux. +Building some Debian package (not rustc) on Debian GNU/Hurd. +Have a look at the [initial attempt against rustc 1.30](https://people.debian.org/~sthibault/hurd-i386/rustc-1.30-patch) to get an idea how it looks like, how the ABI gets expressed in Rust. +Then one builds the cross-compiler with + + DEB_BUILD_OPTIONS=parallel=8 dpkg-buildpackage -B -ahurd-i386 -Ppkg.rustc.dlstage0,nocheck -nc + +[Rust language](https://www.rust-lang.org/) + +[How to build and run Rust](https://rustc-dev-guide.rust-lang.org/building/how-to-build-and-run.html) + + +--- + +One can check out the result with: + + git clone https://github.com/sthibaul/getrandom.git + git clone https://github.com/sthibaul/nix.git -b r0.26-hack + git clone https://github.com/sthibaul/rust_libloading.git -b v0.7-hack + git clone https://github.com/sthibaul/rust_libloading.git -b hack rust_libloading-0.8.0 + git clone https://github.com/sthibaul/socket2.git -b v0.4.x + git clone https://github.com/Vtewari2311/libc.git -b libc-hurd-latest-hack + git clone https://github.com/Vtewari2311/rust.git -b mod-hurd-latest-hack + +(yes, rust imposes checking out libloading several times...) + +--- + +To build from GNU/Hurd, you will need existing `rustc`/`cargo`/`rustfmt`, you +can e.g. fetch the tarball +[from Samuel](https://people.debian.org/~sthibault/hurd-i386/rust-hurd.tar.xz). +Then you can add the following to `rust/config.toml` + + [build] + rustc = "/path/to/your/rust-hurd/usr/local/bin/rustc" + rustfmt = "/path/to/your/rust-hurd/usr/local/bin/rustfmt" + cargo = "/path/to/your/rust-hurd/usr/local/bin/cargo" + +And then run from `rust/` + + ./x build + DESTDIR=/where/you/want ./x install + DESTDIR=/where/you/want ./x install cargo rustfmt + +Expect about 20GB disk usage and several hours duration. You also need quite +some ram, 4GB may be needed. + +One can run the basic testsuites with + + ./x test tests/ui + ./x test library/core + ./x test library/std + +One [can run tests remotely](https://rustc-dev-guide.rust-lang.org/tests/running.html#running-tests-on-a-remote-machine), +to test with crossbuilding: + + ./x build src/tools/remote-test-server --target i686-unknown-hurd-gnu + +One can run it on the target: + + ./remote-test-server -v --bind 0.0.0.0:12345 + +and run the testsuite with + + export TEST_DEVICE_ADDR="1.2.3.4:12345" + ./x test tests/ui --target i686-unknown-hurd-gnu + +Currently these tests are known to fail: + +tests/ui: + + [ui] tests/ui/abi/homogenous-floats-target-feature-mixup.rs + [ui] tests/ui/associated-consts/issue-93775.rs + [ui] tests/ui/env-funky-keys.rs + [ui] tests/ui/issues/issue-74564-if-expr-stack-overflow.rs + [ui] tests/ui/macros/macros-nonfatal-errors.rs + [ui] tests/ui/modules/path-no-file-name.rs + [ui] tests/ui/parser/mod_file_with_path_attr.rs + [ui] tests/ui/process/no-stdio.rs#mir + [ui] tests/ui/process/no-stdio.rs#thir + [ui] tests/ui/process/println-with-broken-pipe.rs + [ui] tests/ui/sse2.rs + [ui] tests/ui/traits/object/print_vtable_sizes.rs + +notably because we have not enabled SSE2 by default, and we have errno values that are different from Linux etc., + +library/std: + + net::tcp::tests::double_bind + net::tcp::tests::test_read_timeout + net::tcp::tests::test_read_with_timeout + net::tcp::tests::timeouts + net::udp::tests::test_read_timeout + net::udp::tests::test_read_with_timeout + net::udp::tests::timeouts + os::unix::net::tests::basic + os::unix::net::tests::test_read_timeout + os::unix::net::tests::test_read_with_timeout + os::unix::net::tests::test_unix_datagram_connect_to_recv_addr + +because pfinet currently lets double-bind on IPv6 addresses, doesn't currently support `SO_SNDTIMEO` / `SO_RCVTIMEO`, and pflocal doesn't support getpeername. + +--- + +To cross-build (e.g. from Linux), you need to set up a cross build toolchain +; a simple way is to use the `build-many-glibcs.py` script as described on +[[hurd/glibc]]. Note that to produce something that can be run even on current +latest Debian, you should be using the `2.37/master` branch. You also need to +comment the `#define ED` from `sysdeps/mach/hurd/bits/errno.h`. + +You also need to unpack a Hurd build of openssl ; a simple way is to take the +debian packages from debian-ports: +[libssl3](http://deb.debian.org/debian-ports/pool-hurd-i386/main/o/openssl/libssl3_3.0.10-1_hurd-i386.deb) +and +[libssl-dev](http://deb.debian.org/debian-ports/pool-hurd-i386/main/o/openssl/libssl-dev_3.0.10-1_hurd-i386.deb) +and unpack them with: + + dpkg-deb -x libssl3_3.0.10-1_hurd-i386.deb /where/you/want + dpkg-deb -x libssl-dev_3.0.10-1_hurd-i386.deb /where/you/want + mv /where/you/want/usr/include/i386-gnu/openssl/* /where/you/want/usr/include/openssl/ + mv /where/you/want/usr/lib/i386-gnu/* /where/you/want/usr/lib/ + +Then you can add the following to `rust/config.toml` + + [llvm] + download-ci-llvm = false + + [target.i686-unknown-hurd-gnu] + cc = "/path/to/your/build-glibc/install/compilers/i686-gnu/bin/i686-glibc-gnu-gcc" + cxx = "/path/to/your/build-glibc/install/compilers/i686-gnu/bin/i686-glibc-gnu-g++" + linker = "/path/to/your/build-glibc/install/compilers/i686-gnu/bin/i686-glibc-gnu-gcc" + +And then run from `rust/` + + export I686_UNKNOWN_HURD_GNU_OPENSSL_DIR=/where/you/want/usr + ./x build --stage 0 compiler library + ./x build --host i686-unknown-hurd-gnu --target i686-unknown-hurd-gnu compiler library cargo rustfmt + DESTDIR=/where/you/want ./x install --host i686-unknown-hurd-gnu --target i686-unknown-hurd-gnu + DESTDIR=/where/you/want ./x install --host i686-unknown-hurd-gnu --target i686-unknown-hurd-gnu cargo rustfmt + +Expect about 25GB disk usage and several hours duration. You also need quite +some ram, 4GB may be needed. Take care if you have many cores and threads, the +parallel build of llvm can be quite demanding, you may want to reduce the number +of available processors (e.g. disabling SMT by prefixing your commands with +`hwloc-bind --no-smt all -- `), so you have more memory per core. + +Note that you will have a usable cross-compiler in +`rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc` and a native Hurd compiler in +`rust/build/i686-unknown-hurd-gnu/stage2/bin/rustc` diff --git a/community/meetings/fosdem_2016.mdwn b/community/meetings/fosdem_2016.mdwn index 353bf15d..62348bea 100644 --- a/community/meetings/fosdem_2016.mdwn +++ b/community/meetings/fosdem_2016.mdwn @@ -51,6 +51,6 @@ ragkousis_guix_hurd: thibault_hurd: - "presentation by Samuel Thibault: [*Hurd, Rump kernel, sound, and USB*](https://fosdem.org/2016/schedule/event/microkernels_hurd_rump_sound_usb/) ([slides](https://fosdem.org/2016/schedule/event/microkernels_hurd_rump_sound_usb/attachments/slides/951/export/events/attachments/microkernels_hurd_rump_sound_usb/slides/951/2016_01_30_fosdem.pdf))" + "presentation (including video) by Samuel Thibault: [*Hurd, Rump kernel, sound, and USB*](https://fosdem.org/2016/schedule/event/microkernels_hurd_rump_sound_usb/) ([slides](https://fosdem.org/2016/schedule/event/microkernels_hurd_rump_sound_usb/attachments/slides/951/export/events/attachments/microkernels_hurd_rump_sound_usb/slides/951/2016_01_30_fosdem.pdf))" """]] diff --git a/community/meetings/fosdem_2017.mdwn b/community/meetings/fosdem_2017.mdwn index d3a48760..d281e279 100644 --- a/community/meetings/fosdem_2017.mdwn +++ b/community/meetings/fosdem_2017.mdwn @@ -36,10 +36,10 @@ Bruxelles. ragkousis_guix_hurd: - "presentation by Manolis Ragkousis: [*Adding GNU/Hurd support to GNU Guix and GuixSD*](https://archive.fosdem.org/2017/schedule/event/guixhurd/) ([slides](https://archive.fosdem.org/2017/schedule/event/guixhurd/attachments/slides/1850/export/events/attachments/guixhurd/slides/1850/guix_to_hurd_fosdem_2017.pdf))" + "presentation (including video) by Manolis Ragkousis: [*Adding GNU/Hurd support to GNU Guix and GuixSD*](https://archive.fosdem.org/2017/schedule/event/guixhurd/) ([slides](https://archive.fosdem.org/2017/schedule/event/guixhurd/attachments/slides/1850/export/events/attachments/guixhurd/slides/1850/guix_to_hurd_fosdem_2017.pdf))" winter_hurd: - "presentation by Justus Winter: [*Virtualization on the Hurd*](https://archive.fosdem.org/2017/schedule/event/microkernel_virtualization_on_hurd/) ([slides](https://archive.fosdem.org/2017/schedule/event/microkernel_virtualization_on_hurd/attachments/slides/1593/export/events/attachments/microkernel_virtualization_on_hurd/slides/1593/virtualization_on_the_hurd.pdf))" + "presentation (including video) by Justus Winter: [*Virtualization on the Hurd*](https://archive.fosdem.org/2017/schedule/event/microkernel_virtualization_on_hurd/) ([slides](https://archive.fosdem.org/2017/schedule/event/microkernel_virtualization_on_hurd/attachments/slides/1593/export/events/attachments/microkernel_virtualization_on_hurd/slides/1593/virtualization_on_the_hurd.pdf))" """]] diff --git a/community/meetings/fosdem_2018.mdwn b/community/meetings/fosdem_2018.mdwn index b065c5d9..eaac07bb 100644 --- a/community/meetings/fosdem_2018.mdwn +++ b/community/meetings/fosdem_2018.mdwn @@ -30,6 +30,6 @@ Bruxelles. thibault_hurd: - "presentation by Samuel Thibault: [*Hurd's PCI arbiter*](https://archive.fosdem.org/2018/schedule/event/microkernel_hurd_pci_arbiter/) ([slides](https://archive.fosdem.org/2018/schedule/event/microkernel_hurd_pci_arbiter/attachments/slides/2323/export/events/attachments/microkernel_hurd_pci_arbiter/slides/2323/2018_02_03_fosdem_pci.pdf))" + "presentation (including video) by Samuel Thibault: [*Hurd's PCI arbiter*](https://archive.fosdem.org/2018/schedule/event/microkernel_hurd_pci_arbiter/) ([slides](https://archive.fosdem.org/2018/schedule/event/microkernel_hurd_pci_arbiter/attachments/slides/2323/export/events/attachments/microkernel_hurd_pci_arbiter/slides/2323/2018_02_03_fosdem_pci.pdf))" """]] diff --git a/community/meetings/fosdem_2019.mdwn b/community/meetings/fosdem_2019.mdwn index 05e93bb7..257bc00c 100644 --- a/community/meetings/fosdem_2019.mdwn +++ b/community/meetings/fosdem_2019.mdwn @@ -30,6 +30,6 @@ Bruxelles. thibault_hurd: - "presentation by Samuel Thibault: [*A roadmap for the Hurd?*](https://fosdem.org/2019/schedule/event/roadmap_for_the_hurd/) ([slides](https://fosdem.org/2019/schedule/event/roadmap_for_the_hurd/attachments/slides/3270/export/events/attachments/roadmap_for_the_hurd/slides/3270/2019_02_01_fosdem_roadmap.pdf))" + "presentation (including video) by Samuel Thibault: [*A roadmap for the Hurd?*](https://fosdem.org/2019/schedule/event/roadmap_for_the_hurd/) ([slides](https://fosdem.org/2019/schedule/event/roadmap_for_the_hurd/attachments/slides/3270/export/events/attachments/roadmap_for_the_hurd/slides/3270/2019_02_01_fosdem_roadmap.pdf))" """]] diff --git a/community/meetings/fosdem_2022.mdwn b/community/meetings/fosdem_2022.mdwn new file mode 100644 index 00000000..221ef612 --- /dev/null +++ b/community/meetings/fosdem_2022.mdwn @@ -0,0 +1,34 @@ +[[!meta copyright="Copyright © 2012, 2013, 2014, 2015, 2016, 2018, 2019, 2022 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="FOSDEM 2022"]] + +<http://fosdem.org/2022> + +FOSDEM has taken place on February 5th/6th online + + + + +# Microkernels devroom + +<https://fosdem.org/2022/schedule/room/dmicrokernel/> + + * {{$zammit_hurd}} + + +[[!ymlfront data=""" + +zammit_hurd: + + "presentation (including video) by Damien Zammit: [*A practical solution for GNU/Hurd's lack of drivers: NetBSD's rumpkernel framework*](https://fosdem.org/2022/schedule/event/dzammit/) ([slides](https://fosdem.org/2022/schedule/event/dzammit/attachments/slides/4850/export/events/attachments/dzammit/slides/4850/rump_hurd_talk.pdf))" + +"""]] diff --git a/community/weblogs/ArneBab/2008-08-02-gnu_hurd_and_x.mdwn b/community/weblogs/ArneBab/2008-08-02-gnu_hurd_and_x.mdwn index d72f4cef..844481be 100644 --- a/community/weblogs/ArneBab/2008-08-02-gnu_hurd_and_x.mdwn +++ b/community/weblogs/ArneBab/2008-08-02-gnu_hurd_and_x.mdwn @@ -18,7 +18,7 @@ I worked as root. First I installed xorg, x-window-system-code, rxvt and twm: - apt-get install xserver-xorg x-window-system-core rxvt twm + apt install xserver-xorg x-window-system-core rxvt twm Then I set the LD_LIBRARY_PATH and DISPLAY diff --git a/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn b/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn index b0e57bfb..5ead2362 100644 --- a/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn +++ b/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn @@ -57,7 +57,7 @@ For this years GSoC I want to turn the currently rudimentary Python Bindings of * *August 8.* More translators and integrating into the build system. * *August 15.* - Suggested Pencils down. The translator API is easy to use, there are many example translators and there is a full featured settrans command in Python using the easier controlling API which shows how to control the Hurd directly from Python. The code is pushed to <https://github.com/ArneBab/PyHurd> and a git repo at <http://git.savannah.gnu.org/cgit/hurd> and integrated into the build system with a switch to enable building PyHurd. + Suggested Pencils down. The translator API is easy to use, there are many example translators and there is a full featured settrans command in Python using the easier controlling API which shows how to control the Hurd directly from Python. The code is pushed to <https://github.com/ArneBab/PyHurd> and a git repo at <https://git.savannah.gnu.org/cgit/hurd> and integrated into the build system with a switch to enable building PyHurd. * *August 22.* Firm pencils down. diff --git a/community/weblogs/ArneBab/Hurd-showcase-qemu-image.mdwn b/community/weblogs/ArneBab/Hurd-showcase-qemu-image.mdwn index 00d09094..af7cbab6 100644 --- a/community/weblogs/ArneBab/Hurd-showcase-qemu-image.mdwn +++ b/community/weblogs/ArneBab/Hurd-showcase-qemu-image.mdwn @@ -6,19 +6,18 @@ For that I want to use: * An up to date debian image (no longer online, but I have a copy here). * My [Hurd Intro](http://bitbucket.org/ArneBab/hurd_intro), -* Translators from [hurd-extras](http://www.nongnu.org/hurdextras/) and the [incubator](http://git.savannah.gnu.org/cgit/hurd/incubator.git/), and naturally -* a lot of apt-get update; apt-get upgrade and apt-get dist-upgrade :) (all worked flawlessly). +* Translators from [hurd-extras](http://www.nongnu.org/hurdextras/) and the [incubator](https://git.savannah.gnu.org/cgit/hurd/incubator.git/), and naturally +* a lot of apt update; apt upgrade and apt dist-upgrade :) (all worked flawlessly). ## Working ### Generally # ssh with public key - apt-get install random-egd ssh-keygen # build tools - apt-get install build-essential + apt install build-essential ### StoreIO @@ -42,7 +41,7 @@ For that I want to use: # pkg-config is needed to avoid “PKG_CHECK_MODULES syntax error near unexpected token `HTTPFS,'” # pkg-config must be installed before you run autoreconf. - apt-get install autoconf autoconf-archive libxml2-dev pkg-config + apt install autoconf autoconf-archive libxml2-dev pkg-config autoreconf -i -f ./configure make @@ -55,7 +54,7 @@ For that I want to use: ### Tarfs - apt-get install zip libz-dev libbz2-dev + apt install zip libz-dev libbz2-dev git clone git://git.sv.gnu.org/hurd/incubator.git tarfs cd tarfs/ git checkout tarfs/master @@ -80,7 +79,7 @@ For that I want to use: cd nsmux/ git checkout -b nsmux origin/nsmux - apt-get install autoconf autoconf-archive + apt install autoconf autoconf-archive autoreconf -i -f ./configure make @@ -101,7 +100,7 @@ For that I want to use: cd clisp/ git checkout -b clisp origin/clisp - apt-get install texi2html + apt install texi2html make make install diff --git a/community/weblogs/ArneBab/porting-simple-packages.mdwn b/community/weblogs/ArneBab/porting-simple-packages.mdwn index becea251..4fc5d67f 100644 --- a/community/weblogs/ArneBab/porting-simple-packages.mdwn +++ b/community/weblogs/ArneBab/porting-simple-packages.mdwn @@ -36,13 +36,13 @@ Other simple tasks can be found on [[hurd/porting/guidelines]]. ## Downloading the package source and installing dependencies - apt-get source PACKAGE - apt-get build-dep PACKAGE + apt source PACKAGE + apt build-dep PACKAGE For example - apt-get source lilypond - apt-get build-dep lilypond + apt source lilypond + apt build-dep lilypond ## Fix the package diff --git a/community/weblogs/ArneBab/what_we_need.mdwn b/community/weblogs/ArneBab/what_we_need.mdwn index 4773d5c0..f6008d53 100644 --- a/community/weblogs/ArneBab/what_we_need.mdwn +++ b/community/weblogs/ArneBab/what_we_need.mdwn @@ -32,8 +32,8 @@ why not become a Hurd hacker and add your touch? :) You can reach us in the [[mailing_lists]] and in [[irc]]. -The sourcecode is in our [[source_repositories]] (git). When you want to check sources relevant for you, [DDE](http://git.savannah.gnu.org/cgit/hurd/incubator.git/tree/?h=dde) might be a good place to start for wireless and sound. USB on the other hand might need work in [gnumach](http://git.savannah.gnu.org/cgit/hurd/gnumach.git/) ([[hacking_info|microkernel/mach/gnumach]]). +The sourcecode is in our [[source_repositories]] (git). When you want to check sources relevant for you, [DDE](https://git.savannah.gnu.org/cgit/hurd/incubator.git/tree/?h=dde) might be a good place to start for wireless and sound. USB on the other hand might need work in [gnumach](https://git.savannah.gnu.org/cgit/hurd/gnumach.git/) ([[hacking_info|microkernel/mach/gnumach]]). -Besides: “The great next stuff” is in the [incubator git repo](http://git.savannah.gnu.org/cgit/hurd/incubator.git/), including (among others) [clisp](http://git.savannah.gnu.org/cgit/hurd/incubator.git/tree/?h=clisp) (translators in lisp) and [nsmux](http://git.savannah.gnu.org/cgit/hurd/incubator.git/tree/?h=nsmux) (dynamically setting translators on files for one command by accessing `file,,translator`). +Besides: “The great next stuff” is in the [incubator git repo](https://git.savannah.gnu.org/cgit/hurd/incubator.git/), including (among others) [clisp](https://git.savannah.gnu.org/cgit/hurd/incubator.git/tree/?h=clisp) (translators in lisp) and [nsmux](https://git.savannah.gnu.org/cgit/hurd/incubator.git/tree/?h=nsmux) (dynamically setting translators on files for one command by accessing `file,,translator`). Happy hacking! diff --git a/community/weblogs/ArneBab/xkb-woes-trying-to-get-a-german-keyboard-layout.mdwn b/community/weblogs/ArneBab/xkb-woes-trying-to-get-a-german-keyboard-layout.mdwn index eb90f663..638b530e 100644 --- a/community/weblogs/ArneBab/xkb-woes-trying-to-get-a-german-keyboard-layout.mdwn +++ b/community/weblogs/ArneBab/xkb-woes-trying-to-get-a-german-keyboard-layout.mdwn @@ -31,7 +31,7 @@ First I got the needed apt-sources: Then I installed the xkb console: -- `apt-get install console-driver-xkb` +- `apt install console-driver-xkb` And set it in the file /etc/default/hurd-console diff --git a/contributing.mdwn b/contributing.mdwn index 3c91b509..f4663dda 100644 --- a/contributing.mdwn +++ b/contributing.mdwn @@ -87,10 +87,12 @@ documents. Here is a list of small hacks, which can serve as entries into the Hurd code for people who would like to dive into the code but just lack a "somewhere to begin -with". +with". Make sure to check out the most up-to-date version on +<https://darnassus.sceen.net/~hurd-web/contributing> * Teach rsync to use `*getxattr` and friends on GNU/Hurd too, to enable the -X option, so as to preserve translator entries. -* Add a `name` field to `thread` structure in Mach, and `thread_set_name` (like `task_set_name`), and use it to add `pthread_setname_np` to glibc. +* Use `thread_set_name` to add `pthread_setname_np` to glibc. +* Avoid GCC trampolines: as discussed in <https://gcc.gnu.org/onlinedocs/gccint/Trampolines.html> these happen when we pass the address of a nested function to another function. This can be seen by running `readelf -S file.o | grep GNU-stack | grep X`, for instance that happens in libdiskfs/file-exec.c, libdiskfs/io-revoke.c. We can't really use -fno-trampoline, we should instead add `void *data` parameters to iterators such as `ports_class_iterate` or `fshelp_exec_reauth`, so that the nested functions can be made mere static functions that get their information from the `void *data` parameter. * Implement `pthread_setschedparam` and `sched_setscheduler` in glibc by calling mach's `thread_policy` and `thread_priority`. * Strengthen httpfs: it should append '/' to URL automatically, it should not fallback index.html itself, etc. probably a lot more small easy issues. * Create a Wiki page with all presentations about the Hurd. Many are referenced here in the Wiki, but they are not easy to find. @@ -100,7 +102,9 @@ with". * Extend `device_read`/`device_write` into supporting > 2TiB disk sizes. * Make `host_get_time` much more precise by using the TSC. * Make the Hurd [[hurd/console]]'s configuration use [[xkb layout/variant instead of keymap|hurd/console/discussion]]. -* Add NX protection support to GNU Mach. +* Add NX / SMEP / SMAP protection support to GNU Mach. +* Add use of PCID in GNU Mach. +* Fix 64bit instruction set disassembling in GNU Mach's `/i386/i386/db_disasm.c` `db_disasm` function and tables. * Write a partfs translator, to which one gives a disk image, and which exposes the partitions of the disk image, using parted, and the parted-based storeio (`settrans -c foos1 /hurd/storeio -T typed @@ -110,11 +114,15 @@ part:1:file:/home/samy/tmp/foo`). This would be libnetfs-based. `utils/{,u}mount.c` into [[glibc]]. * Add a tool to trace system calls, by using gnumach's Syscall-Emulation, see <http://www.gnu.org/software/hurd/gnumach-doc/Syscall-Emulation.html> * Improve our [[FUSE library|hurd/libfuse]]. -* Add a relatime or lazytime option to ext2fs. * Fix our [[open_issues/symlink_translator]]. -* Fix `O_NOATIME`, see <https://buildd.debian.org/status/fetch.php?pkg=borgbackup&arch=hurd-i386&ver=1.0.2-1&stamp=1460838100> * Add a /dev/rtc device * Add gnumach support for EFI memory areas report through GetMemoryMap instead of the BIOS E820. +* Implement `SA_NOCLDWAIT`. It means adding an RPC to proc to implement it, and then making glibc detect when setting `SIG_IGN` on `SIGCLD`, or setting the `SA_NOCLDWAIT` flag, and in that case call into `proc`, similarly to the `S_proc_mod_stopchild` RPC. proc's `S_proc_wait` shall then wait for all children and return `ECHILD`. +* Implement `lsof`. One can get inspiration from `libshouldbeinlibc/portinfo.c` for the details. +* Add `VSTATUS` support to `term`. Essentially in `term/munge.c`, `input_character`, just like the `VINTR`, `VQUIT`, `VSUSP`, collect a few stats from the system, and put them into the output queue. +* Make mig use the `access` function attribute to properly express accesses in arrays, e.g. for `device_read/write_inband`. +* Add a limitation in the number of a process that a given uid can run. That would be in the `proc` translator. That will allow to avoid crashes when an application goes crazy with forking. Setting a hardcoded limitation would thus already be useful. +* Complete BPF program validation in `libbpf`. For instance, for now if `BPF_MOD` or `BPF_XOR` are used in a filter, it is accepted, but the matching always fails. We should pre-refuse any unknown instruction (and of course then implement `BPF_MOD` and `BPF_XOR`) <a name="porting"></a> ## Porting Packages @@ -151,6 +159,39 @@ Or, you can pick one from the [list of failing packages](http://people.debian.org/~sthibault/failed_packages.txt). +## TODO List + +This is the list of tasks that we *want* to address soon, starting with the most pressing: + +* Add amd64 support to gdb. +* Fix shell output pipe replacement issue on amd64, see +[discussion](https://lists.gnu.org/archive/html/bug-hurd/2023-10/msg00062.html). +* On amd64, fix memcpy (> 16 bytes) from `/dev/mem` (makes hurd-console crash) +* Settle CI for mig+gnumach+hurd+glibc. +* Port `dhcpcd`, see [call for help](https://lists.debian.org/debian-hurd/2023/11/msg00030.html) +* Extensively test (e.g. running testsuites of glibc, perl, curl) and fix the lwip-based TCP/IP stack, to be sure we don't get regressions by switching to it. +* Prevent duplicate instances of `rumpdisk` from competing for the disk PCI cards (e.g. when a second one gets started from a chroot). +* Fix the memory consumption of `rumpdisk`. +* Integrate `rumpusbdisk` with the rest of the disk translators etc. +* Fix `tmpfs` losing files, see [discussion](https://lists.gnu.org/archive/html/bug-hurd/2015-02/msg00091.html). +* Port `libasan`/`lsan`/`ubsan`/`libtasn` so we can use these sanitizers (youpi did some of it, pending clean/submit). +* Finish moving `pthread_` symbols from `libpthread` to `libc`, see for instance [some moves](https://sourceware.org/pipermail/libc-alpha/2023-March/146425.html), synchronize with Guy-Fleury Iteriteka. +* Rewrite `pthread_cond_*`, `pthread_rwlock_*`, `pthread_barrier_*` to use `gsync`, like `pthread_mutex_*` do (also see the nptl implementations, possibly just share with them). +* Improve rumpdisk's asynchronism, see end of `hurd/rumpdisk/block-rump.c`. +* Check performance of `rumpdisk` against the in-`gnumach` drivers. +* Make `ext2fs` use xattr by default to store translators (see `use_xattr_translator_records`) after making sure the upgrade path works fine. +* Finish glib's file monitoring (see [merge request draft](https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3626) and [Debian bug](https://bugs.debian.org/1008208)) +* Extend `ext2fs` to support 64bit time. +* Fix the `git` testsuite (just a few tests failing, used to pass). +* Fix the `subversion` testsuite (just a few tests failing). +* Fix the `vim` testsuite (just a few tests failing, used to pass). +* Fix building `mesa`. +* Fix building `wayland`. +* Port `python-procps`. +* Implement a `rumpnet`. +* Implement a `rumpfs`. +* Fix `SMP` support. + ## Open Issues There is a list of [[open_issues]]. This list includes everything from bug @@ -181,14 +222,14 @@ First run the hurd in [[qemu|hurd/running/qemu#index1h2]] After you have a Hurd vm set up and running: -* `apt-get update` -* `apt-get install -y git mercurial emacs vim` -* `apt-get build-dep -y hurd gnumach` +* `apt update` +* `apt install -y git mercurial emacs vim` +* `apt build-dep -y hurd gnumach` * `git clone git://git.sv.gnu.org/hurd/hurd.git` * `git clone git://git.sv.gnu.org/hurd/gnumach.git` * `git clone git://git.sv.gnu.org/hurd/incubator.git` * You can connect through ssh with `ssh root@localhost -p 2222` -* Get more from the [repo list](http://git.savannah.gnu.org/cgit/hurd/). +* Get more from the [repo list](https://git.savannah.gnu.org/cgit/hurd/). * Read the docs on these pages. * Start hacking. * For shutting down, use `reboot`, then press `c` in grub and issue halt (to avoid filesystem corruption). Adding `--no-reboot` to the qemu line should help, too. diff --git a/contributing/web_pages.mdwn b/contributing/web_pages.mdwn index 903ded7b..e156f6a3 100644 --- a/contributing/web_pages.mdwn +++ b/contributing/web_pages.mdwn @@ -101,7 +101,7 @@ editing. ### Debian Wheezy - $ apt-get install ikiwiki libyaml-syck-perl markdown libsearch-xapian-perl texinfo + $ apt install ikiwiki libyaml-syck-perl markdown libsearch-xapian-perl texinfo ## Identifying Yourself @@ -143,9 +143,9 @@ Or, you can check out the Savannah repository: ..., or: - $ git clone http://git.savannah.gnu.org/cgit/hurd/web.git [dest] + $ git clone https://git.savannah.gnu.org/cgit/hurd/web.git [dest] -See <http://git.savannah.gnu.org/cgit/hurd/web.git>. If you're using the `ssh` +See <https://git.savannah.gnu.org/cgit/hurd/web.git>. If you're using the `ssh` protocol, and you're a member of the Hurd's [[rules/Savannah_group]], you can also push to this repository. The disadvantage of pushing to the Savannah repository is that there is no [[ikiwiki]] installation where the pushed diff --git a/documentation.mdwn b/documentation.mdwn index 85bb74b2..ebbde844 100644 --- a/documentation.mdwn +++ b/documentation.mdwn @@ -62,6 +62,8 @@ from userlandish interfaces (Hurd) or from the microkernel itself (Mach). --- # Presentations +* **2022** + * FOSDEM: {{$community/meetings/fosdem_2022#zammit_hurd}} * **2019** * FOSDEM: {{$community/meetings/fosdem_2019#thibault_hurd}} * **2018** @@ -18,6 +18,8 @@ feeds=no actions=yes rootpage="faq" postformtext="Add a new item titled:"]] +Note: the most up-to-date version version of this FAQ is available on <http://darnassus.sceen.net/~hurd-web/faq/> + This page [[with all items inlined|faq_inlined]]. diff --git a/faq/2_gib_partition_limit.mdwn b/faq/2_gib_partition_limit.mdwn index 68325cff..fa5105bd 100644 --- a/faq/2_gib_partition_limit.mdwn +++ b/faq/2_gib_partition_limit.mdwn @@ -13,10 +13,10 @@ License|/fdl]]."]]"""]] [[!meta title="Is there still a 2 GiB ext2fs disk partition limit?"]] -The 2 GiB limit has been removed. +The 2 GiB ext2fs limit has been removed. IDE disk drivers however currently do not support more than 2^28 sectors, i.e. 128GiB. -The AHCI disk driver supports up to 2^32 sectors, i.e. 2TiB. +The gnumach AHCI disk driver supports up to 2^48 sectors, i.e. 128PiB, but the device interface supports only 2^32 sectors, i.e. 2TiB. You can have a bigger disk, you just should not put disk partitions beyond these limits for the drivers to be able to read from them. diff --git a/faq/64-bit.mdwn b/faq/64-bit.mdwn index 1da375ba..972aafbe 100644 --- a/faq/64-bit.mdwn +++ b/faq/64-bit.mdwn @@ -13,11 +13,21 @@ License|/fdl]]."]]"""]] [[!meta title="Is there a 64-bit version?"]] -There are currently no plan for 64-bit userland, but there are plans for 64-bit -kernelland with 32-bit userland, which will notably permit to efficiently make -use of more than 2 GiB memory and provide 4 GiB userland addressing space. -[[Work on this|open_issues/64-bit_port]] is currently in the master-x86_64 and -port-amd64 branches for GNU Mach. +There are plans for 64-bit kernelland with 32-bit userland, which will notably +permit to efficiently make use of more than 2 GiB memory and provide 4 GiB +userland addressing space. + +A 64-bit GNU/Hurd is also coming soon, +progress is tracked on [[open_issues/64-bit_port]]! +Hurd developers ported GNUMach to +64-bit some time ago. Then they started making significant progress +on the x86_64 userland port in Feb 2023. As of May 2023, the 64-bit +port works well enough to start all the essential Hurd servers, run +/bin/sh, establish TCP/IP connections, and compile C. We are currently building +64-bit packages. We plan on supporting both a 32-bit and 64-bit Debian +GNU/Hurd, only not both at the same time. However, there is no plan to fix the +year 2038 concern on a 32-bit system. That being said, you can always run a 32-bit version on a 64-bit machine, it just works, processes are just limited to a couple GiB available memory. + diff --git a/faq/context_switch.mdwn b/faq/context_switch.mdwn new file mode 100644 index 00000000..2d090c4c --- /dev/null +++ b/faq/context_switch.mdwn @@ -0,0 +1,78 @@ +[[!meta copyright="Copyright © 2013, 2016, 2017, 2018 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 faq/support]] + +[[!meta title="I heard that context-switch on Mach is really slow?"]] + +It is not, there is no real reason why it would be particularly slow, it is just +about switching virtual addresses and registers, which all OS have to perform +anyway. + +A quick-and-dirty benchmark: + + #include <fcntl.h> + #include <semaphore.h> + #include <stdio.h> + #include <time.h> + #include <unistd.h> + #include <sys/mman.h> + + sem_t *sem1, *sem2; + + void worker1(void) { + time_t last; + int n = 0; + last = time(NULL); + while(1) { + time_t new = time(NULL); + if (new != last) { + printf("%d\n", n); + n = 0; + last = new; + } + n++; + sem_wait(sem1); + sem_post(sem2); + } + } + + void worker2(void) { + while(1) { + sem_post(sem1); + sem_wait(sem2); + } + } + + int fd; + void get_sems(void) { + void *ptr = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0); + sem1 = ptr; + sem2 = sem1+1; + } + + int main(void) { + fd = open("/tmp/foo", O_CREAT|O_TRUNC|O_RDWR, 0666); + ftruncate(fd, 4096); + + get_sems(); + sem_init(sem1, 1, 0); + sem_init(sem2, 1, 0); + + if (fork()) + worker1(); + else { + get_sems(); + worker2(); + } + } + +run on my current Linux system (a Core i5-10210U), gets about 300k switches per second on Linux. Running it on Hurd-in-kvm (which would supposedly be slower) gets about 400k switches per second. diff --git a/open_issues/nice_changes_priority_of_parent_shell.mdwn b/faq/dev-rebuild.mdwn index a8a08f90..5a4678d1 100644 --- a/open_issues/nice_changes_priority_of_parent_shell.mdwn +++ b/faq/dev-rebuild.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2021 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -8,8 +9,12 @@ 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 open_issue_glibc]] +[[!tag faq/running]] - * [[!debbug 44039]] +[[!meta title="Some ntries in /dev are bogus"]] - * Also see [[nice_vs_mach_thread_priorities]]. +Possibly something broke translators there. You can run + + dpkg-reconfigure hurd + +to rebuild entries there. diff --git a/faq/drivers.mdwn b/faq/drivers.mdwn index 50bd4542..50ba171d 100644 --- a/faq/drivers.mdwn +++ b/faq/drivers.mdwn @@ -16,7 +16,9 @@ License|/fdl]]."]]"""]] Currently, for disks Mach integrates old drivers from Linux through some [[community/gsoc/project_ideas/driver_glue_code]], which provide IDE disk support, and we have an AHCI driver which provides [[SATA -support|faq/sata_disk_drives]]. For network boards, we use the [[DDE]] toolkit +support|faq/sata_disk_drives]]. + +For network boards, we use the [[DDE]] toolkit to run linux 2.6.32 drivers in userland processes, which provides both long-term support for new hardware and safety against driver bugs. Note however that we have of course not tested all drivers, we obviously don't even have all kinds of @@ -24,5 +26,8 @@ hardware. So we can not promise that they will all work. What probably works for sure is what we usually use: the rtl8139 and e1000 drivers for instance. Firmware loading is not implemented yet. +For graphical mode, Xorg is supported, e.g. with the vesa driver. DRM is not +supported yet. + [[microkernel/mach/gnumach/ports/Xen]] is also supported, both blkfront and netfront. diff --git a/faq/fsck.mdwn b/faq/fsck.mdwn index e7496646..5658a799 100644 --- a/faq/fsck.mdwn +++ b/faq/fsck.mdwn @@ -15,6 +15,18 @@ License|/fdl]]."]]"""]] Quite a few of them are actually benign: /dev/hd0s1: Deleted inode 95849 has zero dtime. FIXED. + [...] + Block bitmap differences: -(988160--988163) -(989627--989634) [...] + [...] + Free blocks count wrong for group #30 (16477, counted=16741). + [...] + Free blocks count wrong (2170675, counted=2170956). + [...] + Inode bitmap differences: -244986 -245011 -(245107--245108) [...] + [...] + Free inodes count wrong for group #30 (4632, counted=4649). + [...] + Free inodes count wrong (880891, counted=880909). see [[open_issues/ext2fs_dtime]] diff --git a/faq/how_to_switch_microkernels.mdwn b/faq/how_to_switch_microkernels.mdwn index a0e57174..21b276ae 100644 --- a/faq/how_to_switch_microkernels.mdwn +++ b/faq/how_to_switch_microkernels.mdwn @@ -13,6 +13,14 @@ License|/fdl]]."]]"""]] [[!meta title="How difficult would it be to switch to another microkernel?"]] -One would have to reimplement the `mach/` and `sysdeps/mach/` parts of -[[glibc]] and [[libpthread]]. Quite a few other Hurd tools also assume a -[[microkernel/Mach]] kernel and would have to be adapted or rewritten. +The microkernel has to provide memory management and user-level-managed page +faulting, thread scheduling, and IPC. + +One would have to reimplement the `mach/` and `sysdeps/mach/` parts of [[glibc]] +and [[libpthread]]. One would have to rewrite mig to generate the new IPCs. One +would have to rewrite libpager to handle paging. + +All `mach_` calls in glibc and hurd would need to be updated. + +Quite a few other Hurd tools also assume a [[microkernel/Mach]] kernel and +would have to be adapted or rewritten. diff --git a/faq/other_repositories.mdwn b/faq/other_repositories.mdwn index f8ece75f..a55ac1e3 100644 --- a/faq/other_repositories.mdwn +++ b/faq/other_repositories.mdwn @@ -11,7 +11,7 @@ License|/fdl]]."]]"""]] [[!tag faq/debian]] -If you want to use the `apt-get source` facility, make sure that +If you want to use the `apt source` facility, make sure that `/etc/apt/sources.list` contains a line like deb-src http://ftp.de.debian.org/debian unstable main diff --git a/faq/random_seed_file.mdwn b/faq/random_seed_file.mdwn new file mode 100644 index 00000000..7afe007e --- /dev/null +++ b/faq/random_seed_file.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2021 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 faq/support]] + +[[!meta title="During installation I get Failed to read random seed file"]] + +More precisely, during the Debian installation, around the extraction of the netdde package one gets: + + /hurd/random: Warning: Failed to read random seed file /var/lib/random-seed: (system kern) error with unknown subsystem + +This is a harmless glitch. diff --git a/faq/smp.mdwn b/faq/smp.mdwn index c0133b80..ee0bf53f 100644 --- a/faq/smp.mdwn +++ b/faq/smp.mdwn @@ -13,21 +13,34 @@ License|/fdl]]."]]"""]] [[!meta title="Does GNU/Hurd support SMP/Multicore?"]] -The Hurd servers themselves are multithreaded, so they should be able to take benefit of the parallelism brought by SMP/Multicore boxes. This has however never been tested yet because of the following. +The Hurd servers themselves are multithreaded, so they should be able to +benefit of the parallelism brought by SMP/Multicore boxes. +This needs testing as SMP support has recently been added to Mach. [[microkernel/Mach]] used to be running on SMP boxes like the [[!wikipedia Intel_iPSC/860]], so principally has the required infrastructure. It has -however not yet been enhanced to support nowadays' SMP standards like ACPI, -etc. Also, [[GNU Mach|microkernel/mach/gnumach]]'s Linux device driver glue -code likely isn't SMP-safe. As this glue code layer is not used in the -[[microkernel/mach/gnumach/ports/Xen]] port of GNU Mach, the plan is to try it -in this enviroment first. +recently been enhanced to support nowadays' SMP standards like ACPI. -[[!tag open_issue_gnumach open_issue_xen]] +However, [[GNU Mach|microkernel/mach/gnumach]]'s Linux device driver glue +code isn't SMP-safe so build with --disable-linux-groups to test SMP and use +rumpdisk to provide disk access. -That is why for now GNU/Hurd will only use one logical processor (i.e. one core or one thread, depending on the socket type). +To build an SMP supported gnumach with kdb: +../configure --enable-ncpus=8 --enable-kdb --enable-apic --disable-linux-groups -Once this issue is solved, there are follow-up issues about +This will by default allow you to boot with one core isolated to the default +processor set, and all the other detected cpus will be in the slave processor set. +The slave processors need to be enabled per-task using RPCs to manipulate processor sets. + +See https://lists.gnu.org/archive/html/bug-hurd/2024-02/msg00088.html for a test program +that can enable a task to use the slave processors by calling ./smp /bin/bash for example. + +Unfortunately, there are race conditions causing hangs or crashes in Mach when attempting +to boot a full SMP system, (if you revert the slave processor pinning commit). +This is what needs to be debugged one-by-one by running each translator using ./smp until +we can squash these race condition bugs. + +There are follow-up issues about [[open_issues/multiprocessing]] and [[open_issues/multithreading]]. [[Project idea|open_issues/smp]]. diff --git a/faq/x-exit.mdwn b/faq/x-exit.mdwn new file mode 100644 index 00000000..5806cd11 --- /dev/null +++ b/faq/x-exit.mdwn @@ -0,0 +1,27 @@ +[[!meta copyright="Copyright © 2021 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 faq/running]] + +[[!meta title="On X session logout, the X server does not exit"]] + +This is due to a missing implementation of a corner case of Posix signaling for non-root processes to root processes. + +One can however use the usual ctrl-alt-backspace shortcut to kill the X server. + +You just need to configure it via the file: +`/etc/X11/xorg.conf.d/xorg-ctrl-backspace.conf` + + Section "InputDevice" + Identifier "Generic KeyBoard" + Driver "kbd" + Option "XkbOptions" "terminate:ctrl_alt_bksp" + EndSection diff --git a/open_issues/faccessat.mdwn b/faq/xserver-hurd-console.mdwn index 911acbb6..ebe2bf31 100644 --- a/open_issues/faccessat.mdwn +++ b/faq/xserver-hurd-console.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2022 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -8,14 +9,11 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] -[[!tag open_issue_glibc open_issue_hurd]] +[[!tag faq/running]] -`faccessat()` fails on some cases; in particular when: +[[!meta title="Cannot open keyboard (No such file or directory)"]] -* flags does not have `AT_EACCESS` -* dirfd is not `AT_FDCWD` -* pathname is not an absolute path +You are apparently not running the Hurd console, only the Mach console, which +Xorg does not know how to read. -In such case, it will return -1 setting `ENOTSUP` as errno. - -[[faccessat.c]] +Make sure to enable the Hurd console in `/etc/default/hurd-console` diff --git a/grub/tftp_boot.mdwn b/grub/tftp_boot.mdwn index cecc0196..a094f248 100644 --- a/grub/tftp_boot.mdwn +++ b/grub/tftp_boot.mdwn @@ -4,10 +4,10 @@ ### <a name="Debian_Grub"> Debian Grub </a> -The Debian grub packages do not have networking enabled, so you have to apt-get the source, modify the debian/rules file to include --enable-network-card and dpkg-buildpackage to get a .deb of grub that supports TFTP. +The Debian grub packages do not have networking enabled, so you have to apt the source, modify the debian/rules file to include --enable-network-card and dpkg-buildpackage to get a .deb of grub that supports TFTP. 1. cd /usr/src/debian -2. apt-get source grub +2. apt source grub 3. cd grub-\_VERSION\_ 4. Add `--enable-tulip` or similar for your NIC to the `./configure` line of the `configure-stamp` target in the `debian/rules` file. 5. `dpkg-buildpackage` (as `root`) @@ -62,7 +62,8 @@ in the *unstable* branch of the Debian archive. * [[running/Distrib]] -- Distributions * [[Public_Hurd_Boxen]] * [[Neighborhurd]]s and [[Subhurd]]s -* [[DDE]] -- Device Driver Environment +* [[DDE]] -- Old Device Driver Environment +* [[RUMP]] -- Modern Device Drivers ## Common Problems @@ -99,8 +100,6 @@ in the *unstable* branch of the Debian archive. * [[libps]] * In-development Libraries * [[libfuse]] -* Discontinued Libraries - * [[libthreads]] * [[IO_Path]] * [[Porting]] * [[Debugging]] diff --git a/hurd/ada4hurd.mdwn b/hurd/ada4hurd.mdwn index c783e53b..e5ef1359 100644 --- a/hurd/ada4hurd.mdwn +++ b/hurd/ada4hurd.mdwn @@ -51,7 +51,7 @@ Ada4Hurd provides tools and examples to ease Ada development in Hurd. It is at a * Install the build dependencies as root - $ apt-get install gnat libopentoken4-dev libxmlada5-dev libasis2014-dev + $ apt install gnat libopentoken4-dev libxmlada5-dev libasis2014-dev * Build @@ -65,4 +65,4 @@ Ada4Hurd provides tools and examples to ease Ada development in Hurd. It is at a * Run netfs tests * In netfs\_base directory - $ make trans\_dbg\_on
\ No newline at end of file + $ make trans\_dbg\_on diff --git a/hurd/bootstrap.mdwn b/hurd/bootstrap.mdwn index 83ad3218..fbce3bc1 100644 --- a/hurd/bootstrap.mdwn +++ b/hurd/bootstrap.mdwn @@ -58,6 +58,55 @@ it to load `/hurd/exec`) GNU Mach will eventually make the `$(task-resume)` function calls, and thus resume the ext2fs task only. +This starts a dance between the bootstrap processes: `ext2fs`, `exec`, `startup`, +`proc`, and `auth`. Indeed, there are a few dependencies between them: `exec` needs +`ext2fs` working to be able to start `startup`, `proc` and `auth`, and `ext2fs` needs to +register itself to `startup`, `proc` and `auth` so as to appear as a normal process, +running under uid 0. + +The base principle is that `ext2fs` has a nul bootstrap port set to while other +translators will have a non-nul bootstrap port, with which they will discuss. We +thus have a hierarchy between the bootstrap processes. `ext2fs` is at the root, +`exec` and `startup` are its direct children, and `auth` and `port` are direct +children of `startup`. + +Usually the bootstrap port is used when starting a translator, see +`fshelp_start_translator_long`: the parent translator starts the child and sets +its bootstrap port. The parent then waits for the child to call `fsys_startup` +on the bootstrap port, for the child to provide its control port, and for the +parent to provide the FS node that the child is translator for. + +For the bootstrap translators, the story is extended: + +* Between `ext2fs` and `startup`: `startup` additionally calls `fsys_init`, to +provide `ext2fs` with `proc` and `auth` ports. +* Between `startup` and `proc`: `proc` just calls `startup_procinit` to hand +over a `proc` port and get `auth` and `priv` ports. +* Between `startup` and `auth`: `auth` calls `startup_authinit` to hand over an +`auth` port and get a `proc` port, then calls `startup_essential_task` to notify +`startup` that the boot can proceed. +* For translators before `ext2fs`, the child calls `fsys_startup` to pass over +the control port of `ext2fs` (instead of its own control port, which is useless +for its parent). This is typically done in the `S_fsys_startup` stub, simply +forwarding it. The child also calls `fsys_init` to pass over the `proc` and +`auth` ports. Again, this is typically done in the `S_fsys_init` stub, simply +forwarding them. + +With that in mind, the dance between the bootstrap translators is happening as +described in the next sections. + +# Initialization of translators before ext2fs + +We plan to start pci-arbiter and rumpdisk translators before ext2fs. + +pci-arbiter's `main` function parses the arguments, and since it is given a disk +task port, it knows it is a bootstrap translator and thus initializes the +machdev library. `machdev_trivfs_init` resumes the disk task. + +rumpdisk's `main` function parses the arguments, and since it is given a FS task +port, it knows it is a bootstrap translator, and thus `machdev_trivfs_init` +resumes the FS task. + # ext2fs initialization ext2fs's `main` function starts by calling `diskfs_init_main`. @@ -68,7 +117,7 @@ opening the Mach console. Since the multiboot command line is available, `diskfs_init_main` sets the ext2fs bootstrap port to `MACH_PORT_NULL`: it is the bootstrap filesystem which -will be in charge of dancing with the exec translator. +will be in charge of dancing with the exec and startup translator. `diskfs_init_main` then initializes the libdiskfs library and spawns a thread to manage libdiskfs RPCs. @@ -76,19 +125,14 @@ manage libdiskfs RPCs. ext2fs continues its initialization: creating a pager, opening the hypermetadata, opening the root inode to be set as root by libdiskfs. -ext2fs then calls `diskfs_startup_diskfs` to really run the startup. +ext2fs then calls `diskfs_startup_diskfs` to really run the startup, implemented +by the libdiskfs library. -# diskfs bootstrap +# libdiskfs bootstrap Since the bootstrap port is `MACH_PORT_NULL`, `diskfs_startup_diskfs` calls `diskfs_start_bootstrap`. -TODO: we want `diskfs_startup_diskfs` to also call `task_get_bootstrap_port` to -call `fsys_startup` on its real bootstrap port once `diskfs_start_bootstrap` is -finished, for bootstrap translators before the root filesystem to know when the -root filesystem is ready, and register themselves as translators in the root -filesystem, register for shutdown notification, etc. - `diskfs_start_bootstrap` starts by creating a open port on itself for the current and root directory, all other processes will inherit it. @@ -108,14 +152,14 @@ its bootstrap port. `trivfs_startup` creates a control port for the exec translator, and calls `fsys_startup` on the bootstrap port to notify ext2fs that it is ready, give it -the control port, and get back a port on the underlying node for the exec +its exec control port, and get back a port on the underlying node for the exec translator (we want to make it show up on `/servers/exec`). -# diskfs taking back control +# libdiskfs taking back control `diskfs_execboot_fsys_startup` is thus called. It calls `dir_lookup` on `/servers/exec` to return the underlying node for the exec translator, and -stores the control port in `diskfs_exec_ctl`. It can then signal `execstarted`. +stores the `exec` control port in `diskfs_exec_ctl`. It can then signal `execstarted`. `diskfs_start_bootstrap` thus takes back control, It calls `fsys_getroot` on the control port of exec, and uses `dir_lookup` and `file_set_translator` to attach @@ -125,16 +169,27 @@ it to `/servers/exec`. be specified on the multiboot command line, but otherwise it will default to `/hurd/startup`. -Now that exec is up and running, the startup process can be created with +Now that exec is up and running, the `startup` process can be created with `exec_exec`. `diskfs_start_bootstrap` takes a lot of care in this: this is the first unix-looking process, it notably inherits the root directory and current working directory initialized above, it gets stdin/out/err on the mach console. It is passed as bootstrap port a port from the `diskfs_control_class`. +`diskfs_start_bootstrap` is complete, we are back to `diskfs_startup_diskfs`, +which checks whether ext2fs was given a bootstrap port, i.e. whether +the rumpdisk translator was started before ext2fs. If so, it +calls `diskfs_call_fsys_startup` which creates a new control port and passes +it do a call to `fsys_startup` on the bootstrap port, so rumpdisk gets access +to the ext2fs filesystem. Rumpdisk however does not return any `realnode` port, +since we are not exposing the ext2fs filesystem in rumpdisk, but rather the +converse. TODO: Rumpdisk forwards this `fsys_startup` call to pci-arbiter, so +the latter also gets access to the ext2fs filesystem. + # startup startup's `main` function starts and calls `task_get_bootstrap_port` to get its -bootstrap port, and `fsys_getpriv` to get a port on the ext2fs translator. It +bootstrap port, i.e. the control port of ext2fs, and `fsys_getpriv` on it to get +the host privileged port and device master port. It clears the bootstrap port so children do not inherit it. It sets itself up with output on the Mach console, and wires itself against swapping. It requests notification for ext2fs translator dying to detect it and print a warning in @@ -148,7 +203,7 @@ startup can then complete the unixish initialization, and run `/hurd/proc` and proc's `main` function starts. It initializes itself, and calls `task_get_bootstrap_port` to get a port on startup. It can then call -`startup_procinit` to pass it the proc port that will represent the startup +`startup_procinit` on it to pass it the proc port that will represent the startup task, and get ports on the auth server, the host privileged port, and device master port. @@ -159,7 +214,7 @@ ready. auth's `main` function starts. It creates the initial root auth handle (all permissions allowed). It calls `task_get_bootstrap_port` to get a port on -startup. It can then call `startup_authinit` to pass the initial root auth +startup. It can then call `startup_authinit` on it to pass the initial root auth handle, and get a port on the proc server. It can then register itself to proc. Eventually, auth calls `startup_essential_task` to tell startup that it is ready. @@ -181,29 +236,68 @@ filesystem on `/servers/startup`. `launch_core_servers` calls `startup_authinit_reply` to actually reply to the `startup_authinit` RPC with a port on proc. -`launch_core_servers` eventually calls `fsys_init` on its bootstrap port +`launch_core_servers` eventually calls `fsys_init` on its bootstrap port, to +give ext2fs the proc and auth ports. -# diskfs taking back control +diskfs' `diskfs_S_fsys_init` thus gets called. It first replies to startup, so +startup is not stuck in its `fsys_init` call and not able to reply to RPCs. From +then on, startup will be watching for `startup_essential_task` calls from the +various bootstrap processes. -diskfs' `diskfs_S_fsys_init` gets called, it thus knows that proc and auth are -ready, and can call `exec_init`. It initializes the default proc and auth ports -to be given to processes. +# libdiskfs taking back control -diskfs calls `startup_essential_task` to tell startup that it is -ready. +In diskfs' `diskfs_S_fsys_init`, diskfs now knows that proc and auth are ready, +and can call `exec_init` on the exec port. + +# exec getting initialized + +exec's `S_exec_init` gets called from the `exec_init` call from ext2fs. Exec can +register itself with proc, and eventually call `startup_essential_task` to tell +startup that it is ready. + +# back to libdiskfs initialization + +It also calls `fsys_init` +on its bootstrap port, i.e. rumpdisk. + +# rumpdisk getting initialized + +rumpdisk's `trivfs_S_fsys_init` gets called from the `fsys_init` call from +ext2fs. It calls `fsys_init` on its bootstrap port. + +# pci-arbiter getting initialized + +pci-arbiter's `trivfs_S_fsys_init` gets called from the `fsys_init` call from +rumpdisk. + +It gets the root node of ext2fs, sets all common ports, and install +pci-arbiter in the ext2fs FS as translator for `/servers/bus/pci`. + +It eventually calls `startup_essential_task` to tell startup that it is ready, +and requests shutdown notifications. + +# back to rumpdisk initialization + +It gets the root node of ext2fs, sets all common ports, and install +rumpdisk in the ext2fs FS as translator for `/dev/disk`. + +It eventually calls `startup_essential_task` to tell startup that it is ready, +and requests shutdown notifications. + +# back to libdiskfs initialization + +It initializes the default proc and auth ports to be given to processes. + +It calls `startup_essential_task` on the startup port to tell startup that +it is ready. Eventually, it calls `_diskfs_init_completed` to finish its initialization, and notably call `startup_request_notification` to get notified by startup when the system is shutting down. -# exec taking back control - -exec's `S_exec_init` gets called, it can register itself with proc, and -eventually call `startup_essential_task` to tell startup that it is ready. - # startup monitoring bootstrap progress -As mentioned above, the different essential tasks (ext2fs, proc, auth, exec) +As mentioned above, the different essential tasks (pci-arbiter, rumpdisk, ext2fs, proc, auth, exec) call `startup_essential_task` when they are ready. startup's `S_startup_essential_task` function thus gets called each time, and startup records each of them as essential, monitoring their death to crash the whole @@ -211,6 +305,7 @@ system. Once all of proc, auth, exec have called `startup_essential_task`, startup replies to their respective RPCs, so they actually start working altogether. It -also calls `launch_system`, which calls `launch_something`, which "launches +also calls `init_stdarrays` which sets the initial values of the standard exec data, and `frob_kernel_process` to plug the kernel task into the picture. +It eventually calls `launch_something`, which "launches something", which by default is `/libexec/runsystem`, but if that can not be found, launches a shell instead, so the user can fix it. diff --git a/hurd/building.mdwn b/hurd/building.mdwn index 31d909e5..63c33498 100644 --- a/hurd/building.mdwn +++ b/hurd/building.mdwn @@ -24,8 +24,8 @@ Building the Hurd requires the *build-essential* and *fakeroot* packages, their dependencies and additional packages that are specified by the source hurd package: - # apt-get install build-essential fakeroot - # apt-get build-dep hurd + # apt install build-essential fakeroot + # apt build-dep hurd ## ... on non-Debian systems @@ -41,9 +41,9 @@ git](http://savannah.gnu.org/git/?group=hurd): ... or (if you are working on a Debian system) the ones that are used for the [current Debian hurd package](http://packages.debian.net/source/unstable/hurd): - $ apt-get source hurd + $ apt source hurd -Please see the Debian [[FAQ]] before using `apt-get source`. +Please see the Debian [[FAQ]] before using `apt source`. The unpacked source tree is around 20 MiB, and the build tree (configured with `--disable-profile`) is around 100 MiB. @@ -93,6 +93,12 @@ or `/local/`, so your current Hurd servers will be replaced. To install to a different location, specify `--prefix=PREFIX` as `configure` parameter, e.g. `--prefix=/usr` (as done when having a real `/usr`). +To build acpi: + + $ make acpi + +You may need to install necessary acpi headers (`libacpica-dev` package in Debian based distro). + By default profiling versions of all the libraries and code are generated but this is useless in most of the cases, so we disable them by specifying `--disable-profile` on `configure`'s command line. diff --git a/hurd/dde/guide.mdwn b/hurd/dde/guide.mdwn index dd36f1f5..b6cf7753 100644 --- a/hurd/dde/guide.mdwn +++ b/hurd/dde/guide.mdwn @@ -58,11 +58,11 @@ Download the packages for offline installation: $ cd /mnt - $ apt-get -c etc/apt/apt.conf.offline update + $ apt -c etc/apt/apt.conf.offline update - $ apt-get -c etc/apt/apt.conf.offline build-dep hurd gnumach + $ apt -c etc/apt/apt.conf.offline build-dep hurd gnumach - $ apt-get -c etc/apt/apt.conf.offline install git-core build-essential libpciaccess-dev libpcap0.8-dev hurd-dev zlib1g-dev + $ apt -c etc/apt/apt.conf.offline install git-core build-essential libpciaccess-dev libpcap0.8-dev hurd-dev zlib1g-dev Get DDE code: @@ -117,9 +117,9 @@ so we can boot into Hurd to do the actual work. Once there, install the packages previously downloaded (again as root): - $ apt-get build-dep hurd gnumach + $ apt build-dep hurd gnumach - $ apt-get install git-core build-essential libpciaccess-dev libpcap0.8-dev hurd-dev zlib1g-dev + $ apt install git-core build-essential libpciaccess-dev libpcap0.8-dev hurd-dev zlib1g-dev Make sure we can build stuff as normal user: diff --git a/hurd/debugging/glibc.mdwn b/hurd/debugging/glibc.mdwn index a409f392..1b7e6ab1 100644 --- a/hurd/debugging/glibc.mdwn +++ b/hurd/debugging/glibc.mdwn @@ -44,24 +44,26 @@ testsuite, use: To save even more build, stop the build after configure has run, and then you can restart the build of only libc.so and libc.a with: - cd build-tree/hurd-i386-libc - make lib + make -C build-tree/hurd-i386-libc lib or of only libc.so with: - make objdir=$PWD/build-tree/hurd-i386-libc $PWD/build-tree/hurd-i386-libc/libc.so + make -C build-tree/hurd-i386-libc objdir=$PWD/build-tree/hurd-i386-libc $PWD/build-tree/hurd-i386-libc/libc.so or of the whole tree with: - cd build-tree/hurd-i386-libc - make + make -C build-tree/hurd-i386-libc or of just one subdir with for instance: - make subdir=libpthread -C libpthread ..=../ objdir=$PWD/build-tree/hurd-i386-libc + make -C htl subdir=htl ..=../ objdir=$PWD/build-tree/hurd-i386-libc (note that most subdirs need libc.so built) +Similarly, you can run the testsuite of a single directory the same way: + + make check -C htl subdir=htl ..=../ objdir=$PWD/build-tree/hurd-i386-libc + --- In some cases, printing to stdout/stderr is problematic. One can use a kernel diff --git a/hurd/documentation/translator_primer.mdwn b/hurd/documentation/translator_primer.mdwn index 92a1d5f9..073d5e07 100644 --- a/hurd/documentation/translator_primer.mdwn +++ b/hurd/documentation/translator_primer.mdwn @@ -84,7 +84,7 @@ What you do here is setting up the translator /hurd/hostmux on ftp: and passing Now that we can access ftp.gnu.org transparently, let's mount a remote ISO file: - $ settrans -c mnt /hurd/iso9660fs ftp://ftp.gnu.org/old-gnu/gnu-f2/hurd-F2-main.iso + $ settrans -c mnt /hurd/iso9660fs $PWD/ftp://ftp.gnu.org/old-gnu/gnu-f2/hurd-F2-main.iso $ ls mnt/ It is interesting to note that since the ISO9660 format is indexed, ftpfs does not have to download the whole ISO file, it merely fetches what iso9660fs requests. diff --git a/hurd/glibc.mdwn b/hurd/glibc.mdwn index 4b5e8d38..8e330aef 100644 --- a/hurd/glibc.mdwn +++ b/hurd/glibc.mdwn @@ -27,18 +27,18 @@ glibc. This should be working as per the following: $ mkdir -p /tmp/build/src $ cp -a /usr/src/glibc /tmp/build/src/ $ unset CFLAGS - $ /tmp/build/src/glibc/scripts/build-many-glibcs.py /tmp/build checkout - $ /tmp/build/src/glibc/scripts/build-many-glibcs.py /tmp/build host-libraries - $ /tmp/build/src/glibc/scripts/build-many-glibcs.py /tmp/build compilers i686-gnu + $ /tmp/build/src/glibc/scripts/build-many-glibcs.py --shallow /tmp/build checkout + $ /tmp/build/src/glibc/scripts/build-many-glibcs.py --strip /tmp/build host-libraries + $ /tmp/build/src/glibc/scripts/build-many-glibcs.py --strip /tmp/build compilers i686-gnu $ /tmp/build/src/glibc/scripts/build-many-glibcs.py /tmp/build glibcs i686-gnu Currently the master branch builds that way without any testsuite issue. -# Building +To save some disk space, after the compilers stage you can remove src/mpc, src/mpfr, src/binutils, src/linux. -One of the tests really put boxes on its knees: +Build logs are available in `/tmp/build/logs` - $ echo "tests-unsupported += test-lfs" >> sysdeps/mach/hurd/i386/Makefile +# Building One can build libc this way: @@ -52,3 +52,7 @@ One can build libc this way: One can run tests with the new libc by hand: $ ./testrun.sh ~/test + +One can build by hand some target with e.g.: + + $ make $PWD/htl/libpthread.so -C ../htl subdir=htl objdir=$PWD ..=../ diff --git a/hurd/interface/fs/19.mdwn b/hurd/interface/fs/19.mdwn index 86625d44..2a50d3e0 100644 --- a/hurd/interface/fs/19.mdwn +++ b/hurd/interface/fs/19.mdwn @@ -23,7 +23,10 @@ License|/fdl]]."]]"""]] Read entries from the directory. Each entry is identified by an index number starting at 0 and running through the file. This call fetches `nentries` (or any convenient number if `nentries` is -1) entries starting at `entry`, -returning an array of struct directs in `data`. The number of entries +returning a series of struct dirent in `data`. +Note that due to the variable-size `d_name` field, `d_reclen` has to be used to +jump from one struct dirent to the other. +The number of entries successfully read is returned in `amount`. If `entry` is bigger than the index of the last entry, then 0 is returned in `amount`. If `bufsize` is nonzero, never return more than `bufsize` bytes of data regardless. diff --git a/hurd/libports.mdwn b/hurd/libports.mdwn index b0a0f6d5..c2c39226 100644 --- a/hurd/libports.mdwn +++ b/hurd/libports.mdwn @@ -16,8 +16,8 @@ ports|microkernel/mach/port]]. It is documented in the [[Reference_Manual]]. Mach ports to the functionality the Hurd needs, that is, it is not meant to 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 +*libports* does not itself depend on *[[/libpthread]]*, but the appropriate +threading hooks are used if present, that is if *[[/libpthread]]* is used by another component. diff --git a/hurd/libthreads.mdwn b/hurd/libthreads.mdwn deleted file mode 100644 index aa429d81..00000000 --- a/hurd/libthreads.mdwn +++ /dev/null @@ -1,39 +0,0 @@ -[[!meta copyright="Copyright © 2011, 2012, 2013 Free Software Foundation, -Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled [[GNU Free Documentation -License|/fdl]]."]]"""]] - -`libthreads` a.k.a. C threads. - -**Note**: since Hurd migrated to [[libpthread]] as threading library, -the development and usage of libthreads has been discontinued. - - - -# Internals - -## Threading Model - -libthreads has a 1:1 threading model. - - -## Threads' Death - -A thread's death doesn't actually free the thread's stack (and maybe not the -associated Mach ports either). That's because there's no way to free the stack -after the thread dies (because the thread of control is gone); the stack needs -to be freed by something else, and there's nothing convenient to do it. There -are many ways to make it work. - -However, it isn't really a leak, because the unfreed resources do get used for -the next thread. So the issue is that the shrinkage of resource consumption -never happens, but it doesn't grow without bounds; it just stays at the maximum -even if the current number of threads is lower. - -The same issue exists in [[libpthread]]. diff --git a/hurd/porting/guidelines.mdwn b/hurd/porting/guidelines.mdwn index 5986269e..624f7fd5 100644 --- a/hurd/porting/guidelines.mdwn +++ b/hurd/porting/guidelines.mdwn @@ -132,6 +132,8 @@ If you get Bad File Descriptor error when trying to read from a file (or accessi <http://pubs.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html> +Also see <https://eklitzke.org/path-max-is-tricky> and <https://insanecoding.blogspot.com/2007/11/pathmax-simply-isnt.html> + Every unconditionalized use of `PATH_MAX`, `MAX_PATH` or `MAXPATHLEN` is a POSIX incompatibility. If there is no upper limit on the length of a path (as its the case for GNU), this symbol is not defined in any header file. Instead, you need to either use a different implementation that does not rely on the length of a string or use `sysconf()` to query the length at runtime. If `sysconf()` returns -1, you have to use `realloc()` to allocate the needed memory dynamically. Usually it is thus simpler to just use dynamic allocation. Sometimes the amount is actually known. Else, a geometrically growing loop can be used: for instance, see [Pulseaudio patch](http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=patch-pulse;att=1;bug=522100). Note that in some cases there are GNU extensions that just work fine: when the `__GLIBC__` macro is defined, `getcwd()` calls can be just replaced by `get_current_dir_name()` calls. Note: constants such as `_POSIX_PATH_MAX` are only the minimum required value @@ -140,10 +142,10 @@ for a potential corresponding `PATH_MAX` macro. They are not a replacement for Note 2: Yes, some POSIX functions such as `realpath()` actually assume that `PATH_MAX` is defined. This is a bug of the POSIX standard, which got fixed in -POSIX 2001, in which one can simply pass `NULL` to get a dynamically +POSIX 2008, in which one can simply pass `NULL` to get a dynamically allocated buffer. One can thus use: - #if _POSIX_VERSION >= 200112 || defined(__GLIBC__) + #if _POSIX_VERSION >= 200809 || defined(__GLIBC__) char *path = realpath(orig, NULL); #else char path[PATH_MATH]; diff --git a/hurd/porting/system_api_limitations.mdwn b/hurd/porting/system_api_limitations.mdwn index 1615ccc0..5fe13fdb 100644 --- a/hurd/porting/system_api_limitations.mdwn +++ b/hurd/porting/system_api_limitations.mdwn @@ -22,8 +22,5 @@ These are the known system API limits that have porting implications. **_[\#47998](http://bugs.debian.org/47998): `msgget` IPC not implemented_** -**_[[nice() doesn't work|open_issues/nice_vs_mach_thread_priorities]]_**. - **_[\#187391](http://bugs.debian.org/187391): libc0.3-dev: `sockaddr_un.sun_path` can't be assigned a `const char *` when compiling with g++_**<br />**breaks:** fam, gail<br />**status:** maybe this should be in [[PortingIssues]] (see _long_ bug log) -**_[\#190367](http://bugs.debian.org/190367): libc0.3-dev: `fcntl` `F_GETLK` not implemented (`ENOSYS`)_**<br />**breaks:** gnome-session (and others) from running<br />**error:** misc lock-related errors diff --git a/hurd/rump.mdwn b/hurd/rump.mdwn new file mode 100644 index 00000000..ddde657f --- /dev/null +++ b/hurd/rump.mdwn @@ -0,0 +1,65 @@ +[[!meta copyright="Copyright © 2009, 2010, 2011 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag stable_URL]] + + * [[community/gsoc/project ideas/driver glue code]] + + * [[open issues/user-space device drivers]] + + * [[open issues/device drivers and io systems]] + +--- + +The rump kernels provide existing real world drivers from netbsd. +Since [[DDE]] no longer seems like a promising approach to get drivers +for the Hurd, it appears that rump kernels are the best alternative. +It already does the hard work of providing an environment where the +foreign drivers can run, and offers the additional benefit of being +externally maintained. Rump also offers the necessary facilities for +running all drivers in separate userspace processes, which is more +desirable than drivers running in the microkernel. + +A rump kernel is a minimal and portable NetBSD kernel running in +userspace. Rump kernels provide drivers for modern hard drives, sound +cards, usb support, and a TCP/IP stack. Instead of re-inventing and +maintaining drivers ourselves, we can re-use the existing NetBSD +drivers. + +Hurd developers have enabled experimental support for modern hard +drives with a rump kernel. We call it rumpdisk, and you can try it in +the [[Debian GNU/Hurd image|hurd/running/qemu]]. + +As of May 2023, Hurd users are having good success with it in qemu +environments and some are using it on real hardware! + +We do hope to use rump kernels for usb support, sound support (this +was working at some point), and possibly a new TCP/IP stack, but work +has not completed on those projects. + +# Documentation + + * <http://www.fixup.fi/misc/usenix-login-2015/login_oct15_02_kantee.pdf> + + This is an an opinion paper that explains why operating systems need compartmentalized kernel drivers. + + * <https://github.com/rumpkernel/wiki/wiki/Tutorial:-Getting-started> + + A tutorial introduction for those interested in using and deploying rump kernels. + + * <https://core.ac.uk/display/41816390> + + "User space approach to audio device driving on UNIX-like systems" by Robert Millan Hernandez. + + +# Source Code + + * <https://github.com/rumpkernel> diff --git a/hurd/running/Guix.mdwn b/hurd/running/Guix.mdwn new file mode 100644 index 00000000..64f9d0e7 --- /dev/null +++ b/hurd/running/Guix.mdwn @@ -0,0 +1,19 @@ +[[!meta title="Guix"]] + +GNU/Hurd support has been integrated in Guix. + +--- +# QEMU Image +[[!inline pages=hurd/running/Guix/qemu_image raw=yes feeds=no]] + +--- +# Documentation + +As Hurd support is integrated in Guix, the official documentation (<https://guix.gnu.org/en/manual/devel/>) also works for Hurd. + +Guix has even support in its configuration language for creating Hurd VMs from a running Guix system (<https://guix.gnu.org/en/manual/devel/en/guix.html#The-Hurd-in-a-Virtual-Machine>). + +--- +# Status + +At the time of writing, the official Guix manual says that "This configuration is experimental and under development. The easiest way for you to give it a try is by setting up an instance of hurd-vm-service-type on your GNU/Linux machine (see hurd-vm-service-type). See Contributing, on how to help!" (<https://guix.gnu.org/en/manual/devel/en/guix.html#GNU-Distribution>). diff --git a/hurd/running/Guix/qemu_image.mdwn b/hurd/running/Guix/qemu_image.mdwn new file mode 100644 index 00000000..52985c6f --- /dev/null +++ b/hurd/running/Guix/qemu_image.mdwn @@ -0,0 +1,14 @@ +[//]: # ([[meta copyright="Copyright © 2011, 2012, 2014, 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]]."]]"""]] + +[[!meta title="Guix's QEMU Image"]] + +There is a QEMU image with [[Guix GNU/Hurd|guix]] pre-installed available +at <https://ci.guix.gnu.org/search/latest/image?query=spec:images+status:success+system:x86_64-linux+hurd-barebones.qcow2>. diff --git a/hurd/running/chroot.mdwn b/hurd/running/chroot.mdwn index eac67282..0f5ec88f 100644 --- a/hurd/running/chroot.mdwn +++ b/hurd/running/chroot.mdwn @@ -24,7 +24,7 @@ It can be a good idea to put the chroot on a separate translator, for instance: Debootstrap should be able to build the content: - # debootstrap sid chroot + # debootstrap --keyring=/usr/share/keyrings/debian-ports-archive-keyring.gpg --extra-suites=unreleased sid chroot http://deb.debian.org/debian-ports/ # Tricks diff --git a/hurd/running/cloud.mdwn b/hurd/running/cloud.mdwn index 736a7113..3d0d37ef 100644 --- a/hurd/running/cloud.mdwn +++ b/hurd/running/cloud.mdwn @@ -15,4 +15,4 @@ It is possible to run the Hurd as a KVM-based OpenStack cloud instance. [[For the time being|open_issues/virtio]], you'll have to avoid using virtio drivers, and use emulated hardware instead: - $ glance image-create --property hw_disk_bus=ide --property hw_cdrom_bus=ide --property hw_vif_model=rtl8139 --disk-format raw --container-format bare --name gnu-hurd --copy-from https://cdimage.debian.org/cdimage/ports/latest/hurd-i386/debian-hurd.img + $ glance image-create --property hw_disk_bus=ide --property hw_cdrom_bus=ide --property hw_vif_model=e1000 --disk-format raw --container-format bare --name gnu-hurd --copy-from https://cdimage.debian.org/cdimage/ports/latest/hurd-i386/debian-hurd.img diff --git a/hurd/running/debian/CrossInstall.mdwn b/hurd/running/debian/CrossInstall.mdwn index c7a099c6..26cd77af 100644 --- a/hurd/running/debian/CrossInstall.mdwn +++ b/hurd/running/debian/CrossInstall.mdwn @@ -17,9 +17,9 @@ Next we create a useful mountpoint and mount the partition. ### <a name="Retrieving_CrossHurd"> Retrieving CrossHurd </a> -Unless you don't run Debian GNU/Linux download it from <http://packages.debian.org/crosshurd>, or simply apt-get the package from Testing or Unstable. Avoid using the version from Stable since it probably is outdated. In case of problems, make sure to try the Unstable version before reporting the issue. +Unless you don't run Debian GNU/Linux download it from <http://packages.debian.org/crosshurd>, or simply apt the package from Testing or Unstable. Avoid using the version from Stable since it probably is outdated. In case of problems, make sure to try the Unstable version before reporting the issue. - # apt-get install crosshurd + # apt install crosshurd ### <a name="Cross_installing"> Cross installing </a> diff --git a/hurd/running/debian/DebianAptOffline.mdwn b/hurd/running/debian/DebianAptOffline.mdwn index 9596040d..f97e5148 100644 --- a/hurd/running/debian/DebianAptOffline.mdwn +++ b/hurd/running/debian/DebianAptOffline.mdwn @@ -24,11 +24,11 @@ As root on the internet connected OS: # mount /dev/DEBIAN_GNU_HURD_PARTITON /mnt # cd /mnt - # apt-get -c etc/apt/apt.conf.offline {update, upgrade, install foo, etc.} + # apt -c etc/apt/apt.conf.offline {update, upgrade, install foo, etc.} Then, reboot into your Debian GNU/Hurd installation and as root, run: - # apt-get {update, upgrade, install foo, etc.} + # apt {update, upgrade, install foo, etc.} ## If you _cannot_ mount your Debian GNU/Hurd partition under another OS. @@ -47,7 +47,7 @@ From the remote sytem, as any user, run: $ cd myhurd $ tar -xf myhurdsconf.tar $ mkdir -p var/lib/apt/lists/partial var/cache/apt/archives/partial tmp - $ apt-get -c etc/apt/apt.conf.offline {update, upgrade, install foo, etc.} + $ apt -c etc/apt/apt.conf.offline {update, upgrade, install foo, etc.} $ tar cf myhurdsconf.tar etc/apt/{apt.conf.offline,sources.list} var/ Copy _myhurdsconf.tar_ back to your Debian GNU/Hurd system. @@ -59,4 +59,4 @@ Finally, from your Debian GNU/Hurd installation as the root user: # tar -xf myhurdsconf.tar # mv var/cache/apt/archives/*.deb /var/cache/apt/archives/ # mv var/lib/apt/lists/*_* /var/lib/apt/lists/ - # apt-get {update, upgrade, install foo, etc.} + # apt {update, upgrade, install foo, etc.} diff --git a/hurd/running/debian/MediaPressKitDiscuss.mdwn b/hurd/running/debian/MediaPressKitDiscuss.mdwn index 2bd97290..05e1761a 100644 --- a/hurd/running/debian/MediaPressKitDiscuss.mdwn +++ b/hurd/running/debian/MediaPressKitDiscuss.mdwn @@ -71,6 +71,6 @@ I think another active process for tracking recent news (if it doesn't already e Here are some interesting urls from [this issue](http://www.debian.org/News/weekly/2003/03/) of the Debian Weekly news: -**Debian Presentations.** Wolfgang Borgert was [looking](http://lists.debian.org/debian-devel-0301/msg00991.html) for a set of slides on dpkg, apt-get and debconf. Javier Fern�ndez-Sanguino Pe�a [intends](http://lists.debian.org/debian-devel-0301/msg01022.html) to provide a 'presentations' section in the [Debian Documentation Project](http://cvs.debian.org/ddp/?cvsroot=debian-doc) (DDP) and has already created an [archive](http://dat.etsit.upm.es/~jfs/debian/www/ddp/slides/) of slides. Whilst the Debian web site does link to [talks](http://www.debian.org/events/talks) given by developers and some [sample slides](http://www.debian.org/events/materials/slides/), it is difficult to gather this information and publish it in a homogeneous way. Talks should be reported to <events@debianNOSPAM.org> and forwarded to him. +**Debian Presentations.** Wolfgang Borgert was [looking](http://lists.debian.org/debian-devel-0301/msg00991.html) for a set of slides on dpkg, apt and debconf. Javier Fern�ndez-Sanguino Pe�a [intends](http://lists.debian.org/debian-devel-0301/msg01022.html) to provide a 'presentations' section in the [Debian Documentation Project](http://cvs.debian.org/ddp/?cvsroot=debian-doc) (DDP) and has already created an [archive](http://dat.etsit.upm.es/~jfs/debian/www/ddp/slides/) of slides. Whilst the Debian web site does link to [talks](http://www.debian.org/events/talks) given by developers and some [sample slides](http://www.debian.org/events/materials/slides/), it is difficult to gather this information and publish it in a homogeneous way. Talks should be reported to <events@debianNOSPAM.org> and forwarded to him. -- [[Main/GrantBow]] - 22 Jan 2003 diff --git a/hurd/running/debian/after_install.mdwn b/hurd/running/debian/after_install.mdwn index d3d32a6f..927d05f1 100644 --- a/hurd/running/debian/after_install.mdwn +++ b/hurd/running/debian/after_install.mdwn @@ -11,7 +11,7 @@ typing a boring arcane. There are Debian-specific scripts that may help you. See [[GRUB]]'s page for this. -# Setup `apt-get` +# Setup `apt Installing packages without having a network connection is described [[DebianAptOffline]]. diff --git a/hurd/running/debian/qemu_image.mdwn b/hurd/running/debian/qemu_image.mdwn index 6ae16d8b..9984ac33 100644 --- a/hurd/running/debian/qemu_image.mdwn +++ b/hurd/running/debian/qemu_image.mdwn @@ -22,16 +22,27 @@ Usage: $ wget https://cdimage.debian.org/cdimage/ports/latest/hurd-i386/debian-hurd.img.tar.gz $ tar -xz < debian-hurd.img.tar.gz - $ kvm -m 1G -drive cache=writeback,file=$(echo debian-hurd-*.img) -no-reboot -net user,hostfwd=tcp:127.0.0.1:2222-:22 + $ kvm -m 1G -drive cache=writeback,file=$(echo debian-hurd-*.img) -no-reboot -net user,hostfwd=tcp:127.0.0.1:2222-:22 -net nic,model=e1000 -* Login as root (the root password is empty) +* Log in as root (the root password is empty) * Set up a root password with `passwd` +* update the system with `apt update && apt upgrade` + +* Log in as demo (the demo password is empty) +* Set up a demo password with `passwd` + +* You can also create another non-root user with `adduser <username>` +* and set the non-root user password with `passwd <username>` +* and add the non-root user to the sudo group via `gpasswd -a <user> sudo` + +* logout via `logout` + Optionally you may use `--curses` to keep your keyboard layout. If need be modprobe kvm_amd, kvm intel and kvm to get kvm support (which is much, much faster). Note that if you do not have a command named `kvm`, you can try something across the lines of: - $ qemu-system-i386 --enable-kvm -drive cche=writeback,file=$(echo debian-hurd-*.img) -net user,hostfwd=tcp:127.0.0.1:2222-:22 + $ qemu-system-i386 --enable-kvm -drive cche=writeback,file=$(echo debian-hurd-*.img) -net user,hostfwd=tcp:127.0.0.1:2222-:22 -net nic,model=e1000 Or, if your machine does not allow for KVM acceleration, omit `--enable-kvm` from the command. diff --git a/hurd/running/debian/status.mdwn b/hurd/running/debian/status.mdwn index 95e48edc..cf3592e7 100644 --- a/hurd/running/debian/status.mdwn +++ b/hurd/running/debian/status.mdwn @@ -1,4 +1,4 @@ Debian GNU/Hurd is currently an official, non-releasing Debian port. I.e., there is no testing or stable distribution. - - [Build daemon/archive status](http://unstable.buildd.net/buildd/hurd-i386_stats) - - [Number of registered users](http://buildd.net/cgi/archvote.phtml) + - [Build daemon/archive status](https://buildd.debian.org/status/architecture.php?a=hurd-i386&suite=sid) + - [Number of registered users](https://popcon.debian.org/stat/sub-hurd-i386.png) diff --git a/hurd/running/distrib.mdwn b/hurd/running/distrib.mdwn index 357d840a..5d12f8ec 100644 --- a/hurd/running/distrib.mdwn +++ b/hurd/running/distrib.mdwn @@ -14,6 +14,7 @@ There are several GNU distributions that are built on the Hurd. If you develop a ###Working distributions of GNU/Hurd: * [[Debian]] +* [[Guix]] ###GNU/Hurd distributions in early stages of development: diff --git a/hurd/running/qemu.mdwn b/hurd/running/qemu.mdwn index 6df06ace..c56292c8 100644 --- a/hurd/running/qemu.mdwn +++ b/hurd/running/qemu.mdwn @@ -24,6 +24,56 @@ You can use the following images to give the Hurd a try. [[!inline pages=hurd/running/debian/qemu_image raw=yes feeds=no]] +#### Trying out rumpdisk + +[[Rump kernels|hurd/rump]] provide new modern drivers for the Hurd. +We refer to rumpdisk as a rump kernel that provides drivers for modern +hard drives, SSDs, etc. The Rump kernels' integration into the Hurd +are still somewhat experimental, but they seem to work fairly well on +bleeding edge Debian. + +Once you have your latest qemu Debian GNU/Hurd image running, then you +can try the rumpdisk (be sure to pass "-m 2GB" or more). First, +add these sources to your /etc/apt/sources.list + + deb http://deb.debian.org/debian-ports unstable main + deb-src http://deb.debian.org/debian unstable main + deb http://deb.debian.org/debian-ports unreleased main + +Then, upgrade to the bleeding edge Debian GNU/Hurd: + + # apt update + # apt upgrade --without-new-pkgs + # apt dist-upgrade + +Now test to see if the rump kernel works before you make the change +permanent. Manually tweak your /boot/grub/grub.cfg like so: + + # multiboot /boot/gnumach-1.8-486.gz root=part:2:device:hd0 console=com0 + multiboot /boot/gnumach-1.8-486.gz root=part:2:device:wd0 console=com0 noide + +and your /etc/fstab + + #/dev/hd0s2 / ext2 defaults 0 1 + /dev/wd0s2 / ext2 defaults 0 1 + #/dev/hd0s1 none swap sw 0 0 + /dev/wd0s1 none swap sw 0 0 + #/dev/hd2 /media/cdrom0 iso9660 noauto 0 0 + /dev/wd2 /media/cdrom0 iso9660 noauto 0 0 + +Now you can poweroff your machine, reboot, and start using the +rumpdisk! You can make these changes permanent by tweaking +/etc/default/grub and telling it to use rumpdisk: + + GRUB_CMDLINE_GNUMACH="noide" + +Then update your grub: + + # update-grub + +Check that "noide" does appear in your /boot/grub/grub.cfg. + + ## Arch Hurd Live CD [[!inline pages=hurd/running/live_cd raw=yes feeds=no]] @@ -50,7 +100,7 @@ volunteers and may not have been tested extensively. ## Debian Installer -Instructions for creating a qemu image from the install CDs from debian installer can be found in the README alongside the d-i Hurd images: <http://people.debian.org/~sthibault/hurd-i386/installer/cdimage/> +Instructions for creating a qemu image from the install CDs from debian installer can be found in the README alongside the d-i Hurd images: <https://cdimage.debian.org/cdimage/ports/latest/hurd-i386/> --- # KVM acceleration @@ -60,7 +110,7 @@ Check if your CPU supports kvm: $ egrep '^flags.*(vmx|svm)' /proc/cpuinfo #### If you don't have hardware support (slow): - $ apt-get install qemu + $ apt install qemu Do not enable kernel-kqemu, as that assumes some particular behavior from the guest kernel, which we are reluctant to artificially add to gnumach. @@ -68,7 +118,7 @@ If QEMU with KVM is not available, [[Virtualbox]] reportedly has better performance. #### If you have hardware support (recommended): - $ apt-get install qemu-kvm + $ apt install qemu-kvm $ modprobe kvm Intel VTx/VTd: Enable Intel kvm in the BIOS @@ -119,7 +169,7 @@ First off you will need to create a disk image using `qemu-img`. I have set mine Next you will want to start up QEMU and begin the installation process. - $ qemu -m 1G -drive cache=writeback,file=hd0.img -cdrom debian-7.0-hurd-i386-NETINST-1.iso -net nic,model=rtl8139 -net user + $ qemu -m 1G -drive cache=writeback,file=hd0.img -cdrom debian-7.0-hurd-i386-NETINST-1.iso -net nic,model=e1000 -net user Now at his point do the regular install using `hd0` as your harddrive. Partition it and install the base system. @@ -167,7 +217,7 @@ Once you have finished installing the base system (might take some time) the sys Starting qemu/qemu-kvm: - $ kvm -m 1G -net nic -net user,hostfwd=tcp::5555-:22 -drive cache=writeback,file=hd0.img -vga vmware + $ kvm -m 1G -net nic,model=e1000 -net user,hostfwd=tcp::5555-:22 -drive cache=writeback,file=hd0.img -vga vmware vmsvga_value_write: guest runs Linux. Note: See below on port forwarding in the networking section. @@ -252,13 +302,13 @@ If you are on [[Debian GNU/Hurd|debian]], you can even use [[debian/DHCP]]. To get ssh working: - # apt-get install random-egd openssh-server (Similarly for telnet if preferred) + # apt install openssh-server (Similarly for telnet if preferred) (See also <http://www.nongnu.org/qemu/qemu-doc.html#SEC32>.) Outgoing internet connections should just work then. Testing it can be difficult with a minimal installation, -but `apt-get update` should work after you have filled out +but `apt update` should work after you have filled out `/etc/apt/sources.list`. After that you should be able to install other network packages, but note that `ping` doesn't work with QEMU's user-networking stack. @@ -288,7 +338,7 @@ This is the recommended way to work with a Command Line Interface (CLI) since al a) with ssh (assuming you have installed openssh-server) - $ kvm -m 1G -net nic -net user,hostfwd=tcp::5555-:22 -drive cache=writeback,file=hd0.img & + $ kvm -m 1G -net nic,model=e1000 -net user,hostfwd=tcp::5555-:22 -drive cache=writeback,file=hd0.img & Logging in to the running Hurd: @@ -305,7 +355,7 @@ Copying files: b) with telnet (assuming you have installed a telnet server, like telnetd) - $ kvm -m 1G -net nic -net user,hostfwd=tcp::5556-:23 -drive cache=writeback,file=hurd-install.qemu & + $ kvm -m 1G -net nic,model=e1000 -net user,hostfwd=tcp::5556-:23 -drive cache=writeback,file=hurd-install.qemu & Logging in to the running Hurd: @@ -346,7 +396,7 @@ Now it is time to start-up your QEMU Hurd system and get networking going in the **Important:** Remember you may need to use the `-M isapc` or `-isa` flag if using an older version of the gnumach package. - $ qemu -m 1G -drive cache=writeback,file=hd0.img -cdrom debian-K9-hurd-i386-CD1.iso -fda floppy.img -boot a -net nic -net tap + $ qemu -m 1G -drive cache=writeback,file=hd0.img -cdrom debian-K9-hurd-i386-CD1.iso -fda floppy.img -boot a -net nic,model=e1000 -net tap Once you have logged in as `root` run the `pfinet` translator with values that apply to your network. Think of your QEMU client as another computer in your network. @@ -355,14 +405,16 @@ Once you have logged in as `root` run the `pfinet` translator with values that a That should do it! Do not forget to edit/update `/etc/resolv.conf` to get DNS working. --- -# Multiboot +# Booting Hurd without grub, using qemu's multiboot support See "Linux/Multiboot boot specific" section on QEMU manpage. Get the multiboot modules. Either extract them from the disk image, or, download: - $ wget http://people.debian.org/~sthibault/hurd-i386/installer/cdimage/current/{gnumach.gz,ext2fs.static,ld.so.1} + $ wget https://cdimage.debian.org/cdimage/ports/latest/hurd-i386/gnumach.gz + $ wget https://cdimage.debian.org/cdimage/ports/latest/hurd-i386/ext2fs.static + $ wget https://cdimage.debian.org/cdimage/ports/latest/hurd-i386/exec.static Generally, these files need to correspond to the ones in the disk image, so don't forget to keep them up to date. @@ -372,18 +424,15 @@ you'll get told: *qemu: linux kernel too old to load a ram disk*. $ qemu [...] \ > --kernel gnumach \ + > --append 'root=device:hd0s1' \ > --initrd \ - > 'ext2fs.static --multiboot-command-line=${kernel-command-line} --host-priv-port=${host-port} --device-master-port=${device-port} --exec-server-task=${exec-task} -T typed device:hd0s1 $(task-create) $(task-resume)',\ - > 'ld.so.1 /hurd/exec $(exec-task=task-create)' + > 'ext2fs.static --multiboot-command-line=${kernel-command-line} --host-priv-port=${host-port} --device-master-port=${device-port} --exec-server-task=${exec-task} -T typed ${root} $(task-create) $(task-resume)',\ + > 'exec.static $(exec-task=task-create)' Note that, contrary to [[GRUB]]'s configuration file, you don't specify "`argv[0]`" here, and it's fortunate that neither ext2fs nor exec need a comma on their command line... -You can also use `--append [...]`, which will show up in `/proc/cmdline`. - -Command line above crashes with old qemu versions, for instance qemu 1.1.2 on Debian Wheezy, fixed by upgrading to wheezy-backports currently qemu 1.7.0, see [[!debbug 741873]] - --- # Related Links diff --git a/hurd/subhurd.mdwn b/hurd/subhurd.mdwn index a92a8d3f..d24369bc 100644 --- a/hurd/subhurd.mdwn +++ b/hurd/subhurd.mdwn @@ -37,6 +37,11 @@ boot it: $ gunzip debian-hurd.img.gz $ boot --kernel-command-line="fastboot root=pseudo-root" -T typed part:1:file:debian-hurd.img +/!\ If you face an error from the mach-defpager (most probably +because there is already a default pager), you can comment +the part that says `/hurd/mach-defpager` from the `/etc/hurd/runsystem.sysv` file +included within the `debian-hurd.img` file you are trying to use. + The 'fastboot' is necessary to skip the filesystem check which fails because the image assumes the root filesystem to be /etc/hd0s1. Once booted, you can correct this: @@ -77,7 +82,7 @@ debootstrap as root: mke2fs /dev/hd0s6 settrans -ca mnt /hurd/ext2fs /dev/hd0s6 - debootstrap sid mnt/ http://httpredir.debian.org/debian + debootstrap --keyring=/usr/share/keyrings/debian-ports-archive-keyring.gpg --extra-suites=unreleased sid chroot http://deb.debian.org/debian-ports/ settrans -fga mnt ## Booting @@ -134,7 +139,7 @@ In the subhurd, you can do basically all the same things as in the main Hurd. You can even set up networking: Just invoke `settrans` on the `/servers/socket/2` as usual inside the subhurd, using `/dev/eth0`, only using a different local IP than in the main Hurd. This way, the subhurd will be able to communicate to -the outside world with its own IP -- allowing for example to do `apt-get` +the outside world with its own IP -- allowing for example to do `apt inside the subhurd, or to `ssh` directly into the subhurd. If you want to access the subhurd processes from the outside, e.g. for diff --git a/hurd/translator.mdwn b/hurd/translator.mdwn index 32562a8b..dad26881 100644 --- a/hurd/translator.mdwn +++ b/hurd/translator.mdwn @@ -92,6 +92,7 @@ The [[concept|concepts]] of translators creates its own problems, too: * [[exec]] * [[proc]] * [[pfinet]] +* [[lwip]] * [[eth-filter]] * [[pflocal]] * [[hostmux]] @@ -107,6 +108,7 @@ The [[concept|concepts]] of translators creates its own problems, too: * [[firmlink]] * [[fifo]] * [[term]] +* [[checkperms]] * ... diff --git a/hurd/translator/checkperms.mdwn b/hurd/translator/checkperms.mdwn new file mode 100644 index 00000000..a8a52cb1 --- /dev/null +++ b/hurd/translator/checkperms.mdwn @@ -0,0 +1,233 @@ +[[!meta copyright="Copyright © 2021 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 *checkperms* translator implements deferred authorization. + +It is part of a project to enable asking for a grant of authorization +when processes access a file. It is built as a translator and a simple +permission granting program. + +The translator can delegate permission-granting to the program via two +FIFO files. The goal is to create a simple replacement for the +use-case of polkit of granting privilege to a process to access some +resource after user-interaction with a permission-granting daemon. + + +# Code + +The translator is available in the checkperm-deferred-authorization branch in [the hurd repository](https://git.savannah.gnu.org/cgit/hurd/hurd.git). + +The code for the program is provided in this article + +# Usage Example + +We restrict a the node /hello to require explicit permission for every +PID that does not have the group `user`. This notably does include +processes started by root. + + +## How it looks + +**First shell** as root: + + settrans -cga /hello $(realpath ~/Dev/hurd/trans/checkperms) --groupname=user + su - user --shell /bin/bash -c 'cat /hello' + # ⇒ HELLOWORLD # user has the group user + cat /hello # root does not have the group user, so + # this blocks until positive reply in the other shell + +**Second shell** (run the program): + + Process 732 tries to access file /hello but is not in the required group user. + USER PID %CPU %MEM SZ RSS TT STAT START TIME COMMAND + root 732 0.0 0.1 148M 3.55M p2 Sso Mon 1AM 0:01.10 -bash + Grant permission and add group "user" for 5 minutes? [y/N]> y + +**First shell** as root: + + # ⇒ HELLOWORLD + # only blocks once despite getting two reads from cat, + # because for the second read cat already has the group `user`. + + + +## Trying it yourself + +Setup the development environment with the code at ~/Dev similar to +https://www.draketo.de/software/hurd-development-environment + + +Compile and setup the translator: + + cd ~/Dev/hurd && \ + patch -p1 < checkperms.patch && \ + autoreconf -i && \ + ./configure --without-parted && \ + make && \ + touch trans/checkperms.c && \ + CFLAGS="$CFLAGS -g" make && \ + echo HELLOWORLD > /hello && \ + settrans -cga /hello $(realpath ~/Dev/hurd/trans/checkperms) --groupname=user + +Create the FIFOs: + + USER=root + GROUP=user + mkdir -p /run/$USER/request-permission + mkdir -p /run/$USER/grant-permission + mkfifo /run/$USER/request-permission/$GROUP + mkfifo /run/$USER/grant-permission/$GROUP + +Setup the permission-granting program in a separate shell: + + USER=root + GROUP=user + while true; do + PID="$(cat /run/$USER/request-permission/$GROUP)" + echo Process $PID tries to access file /hello but is not in the required group $GROUP. + ps-hurd -p $PID -aeux + if [[ "$(read -e -p 'Grant permission and add group "'$GROUP'" for 5 minutes? [y/N]> '; echo $REPLY)" == [Yy]* ]]; then + addauth -p $PID -g $GROUP + echo 0 > /run/$USER/grant-permission/$GROUP + (sleep 300 && rmauth -p $PID -g $GROUP 2>/dev/null) & + else + echo 1 > /run/$USER/grant-permission/$GROUP + fi + done + + +Access the translator as user without the required group and with the group: + + su - user --shell /bin/bash -c cat /hello' + cat /hello & + + +# Concept + +## The translator + +The translator is started with a GROUP as argument. When the file is +accessed, the translator checks whether the process has the given +group. If it does, it returns data read from the underlying file. + +If the process lacks the required group, the translator retrieves its +USER and PID and writes the PID into a FIFO located at + + /run/USER/request-permission/GROUP + +Then it reads from + + /run/USER/grant-permission/GROUP + +It blocks until it gets a reply. If it reads a 0 (=success), it reads +from the file and returns the data. + +## The permission granting program + +The permission granting program reads the PID from + + /run/USER/request-permission/GROUP + +retrieves information about the PID and asks the user whether to allow +the program. + +If the USER answers no, the RET value is non-zero. + +If the USER answers yes, the RET value is zero (0) +and the program adds the GROUP to the process at PID (using addauth). + +It also starts a daemon that will remove the group again after 5 +minutes (modelled after the temporary permissions to run privileged +without password granted by sudo). + +The program then writes the RET value into + + /run/USER/grant-permission/GROUP + +## What if the translator crashes? + +If the translator crashes, the permissions return to those of the +underlying node. For every user except root this usually means that +the process does not have access to the file. + +The failure-mode should therefore be safe. + +# Possibilities + +The most important use-case for this translator is to make it easier +to start programs with reduced permissions and only add these when +required. + +To setup deferred permissions for a single file, you can create a +group just for that file. Then each file can have its own permission +granting program. Having dedicated groups decouples authentication and +authorization while staying in the conventional *nix permissions +scheme. + +You can also set this translator on a file that gets accessed first +when a process accesses a set of related files that all have the same +group. Since the authorization-program here adds the group for 5 +minutes, the other files can afterwards be accessed, too. + +Since the translator simply defers to a program, that program could do +any action to get authorization, including `curl`. Administrators for +a local network could therefore set up terminals for unprivileged +users that request permissions from a local server when accessing a +file. That way permissions can easily be coordinated over multiple +machines. (naturally this does not restrict root who can always use +settrans -g to get raw access to the file) + + + + +# Open Issues + +## read-only + +[[!tag open_issue_hurd]] + +The current implementation only provides read-access, writing is +prevented. This is not an intrinsic limitation, only an implementation +artefact. + +## delegate + +The underlying file is currently read by the translator and the data +returned to the reading process. To reduce delays, it could directly +delegate to the underlying file. With the long term goal to provide +multiplexing of access, for example for audio, reading via the +translator could be preferable, though. + +## writing via system shell + +Writing to and reading from the FIFOs is currently done with +`system()`. It would be nicer to move to an implementation that does +not rely on the system-shell. + +## potential race-condition + +Accesses from two different translators can currently race for the +reply. To fix this, the translator should write the PID and a random +LABEL into the request. The program should repeat that label for +replies to ensure that the reply and request can be matched. If +receiving a non-matching reply, it MUST be written into the grant +again after a random delay to enable a matching translator to +retrieve the grant. +REQUEST: PID LABEL +GRANT: RET LABEL (RET=0 is success) +LABEL=$RANDOM + + +## multiple permission-granting programs + +The system assumes having a single permission granting program per +user. For a setup with multiple unconnected sessions per user (like +several TTYs) the permission granting program needs to coordinate +between these. diff --git a/hurd/translator/httpfs.mdwn b/hurd/translator/httpfs.mdwn index 8b02aa06..0ce0f30b 100644 --- a/hurd/translator/httpfs.mdwn +++ b/hurd/translator/httpfs.mdwn @@ -12,6 +12,84 @@ License|/fdl]]."]]"""]] While the httpfs translator works, it is only suitable for very simple use cases: it just provides the actual file contents downloaded from the URL, but no additional status information that are necessary for interactive use. (Progress indication, error codes, HTTP redirects etc.) +# Introduction + +Here we describe the structure of the /http filesystem for the Hurd. +Under the Hurd, we provide a translator called 'httpfs' which is intended +to provide the filesystem structure. + +The httpfs translator accepts an "http:// URL" as an argument. The underlying +node of the translator can be a file or directory. This is guided by the --mode +command lineoption. Default is a directory. + +If its a file, only file system read requests are supported on that node. If +its a directory, we can cd into that directory and ls would list the files in +the web server. A web server may provide a directory listing or it may not +provide, whatever it be the case the web server always returns an HTML stream +for an user request (GET command). So to get the files residing in the web +server, we have to parse the incoming HTML stream to find out the anchor +tags. These anchor tags point to different pages or files in the web +server. These file name are extracted and filled into the node of the +translator. An anchor tag can also be a pointer to an external URL, in such a +case we just show that URL as a regular file so that the user can make file +system read requests on that URL. In case the file is a URL, we change the name +of URL by converting all the /'s with .'s so that it can be displayed in the +file system. + +Only the root node is filled when the translator is set, subdirectories inside +that are filled as on demand, i.e. when a cd or ls occurs on that particular sub +directory. + +The File size is now displayed as 0. One way of getting individual file sizes is +sending a GET request for each file and cull the file size from Content-Length +field of an HTTP response. But this may put a very heavy burden on the network, +So as of now we have not incorporated this method with this http translator. + +The translator uses the libxml2 library for doing the parsing of HTML +stream. The libxml2 provides SAX interfaces for the parser which are used for +finding the begining of anchor tags `<A href="i.html">`. So the translator has +dependency on the libxml2 library. + +If the connection to the Internet through a proxy, then the user must explicitly +give the IP address and port of the proxy server by using the command line +options --proxy and --port. + + +# How to Use httpfs + + # settrans -a tmp/ /hurd/httpfs http://www.gnu.org/software/hurd/index.html + +<Remember to give the / at the end of the URL, unless you are specifying a specific file like www.hurd-project.com/httpfs.html > + + # cd tmp/ + + # ls -l + + # settrans -a tmp/ /hurd/httpfs http://www.gnu.org/software/hurd/index.html --proxy=192.168.1.103 + --port=3126 + +The above command should be used in case if the access to the Internet is +through a proxy server, substitute your proxies IP and port no.s + +# TODO + +- https:// support +- scheme-relative URL support (eg. "//example.com/") +- query-string and fragment support +- HTTP/1.1 support +- HTTP/2 support +- HTTP/3 support (there may exist a C library that provides HTTP/[123] + support). +- Teach httpfs to understand HTTP status codes like re-directs, 404 not found, + etc. +- Teach httpfs to look for "sitemaps". Many sites offer a sitemap, and this + would be a nifty way for httpfs to allow grep-ing the entire site's + contents. [[sitemaps.org|https://www.sitemaps.org]] is a great resource for + this. +- Teach httpfs to check if the computer has an internet connection at + startup and during operation. The translator causes 30 second + pauses on commands like "ls", when the internet is down. + # Source <http://www.nongnu.org/hurdextras/#httpfs> diff --git a/hurd/translator/lwip.mdwn b/hurd/translator/lwip.mdwn index efa59285..fab7d6f2 100644 --- a/hurd/translator/lwip.mdwn +++ b/hurd/translator/lwip.mdwn @@ -16,7 +16,10 @@ To configure lwip for internet connectivity, use the The argument /server/socket/2 is the node that the translator is to be attached to. This is followed by the translator program to run and any arguments to give it. -There, -i, -a, -g and -m are, quite obviously, the (Mach) device to use, the IP address, the gateway and netmask. +There, -i, -a, -g and -m are, quite obviously, the (Mach) device to use, the IP +address, the gateway and netmask. You can discover these values via the +`ifconfig` command (You need to run this command on the host system and NOT in +the qemu environment). More information can be found on Joan Lledo's blog: diff --git a/hurd/translator/pfinet/ipv6.mdwn b/hurd/translator/pfinet/ipv6.mdwn index ccb359cb..d864e256 100644 --- a/hurd/translator/pfinet/ipv6.mdwn +++ b/hurd/translator/pfinet/ipv6.mdwn @@ -139,7 +139,7 @@ Indeed, IPv6 now works properly, and the very machine hosting this wiki <youpi> which repo? <youpi> I don't have such commit here <gnu_srs> - http://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?id=2b2d7fdc42475019e5ce3eabc9c9673e3c13d89f + https://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?id=2b2d7fdc42475019e5ce3eabc9c9673e3c13d89f <gnu_srs> From which release, 2.4.x, 2.6.x? <youpi> it's very old <youpi> 2002 diff --git a/hurd/translator/procfs.mdwn b/hurd/translator/procfs.mdwn index 0228d4d4..b3753592 100644 --- a/hurd/translator/procfs.mdwn +++ b/hurd/translator/procfs.mdwn @@ -31,7 +31,7 @@ Madhusudan.C.S has implemented a new, fully functional [[procfs|madhusudancs]] f In August 2010, Jérémie Koenig [published another, new version](http://lists.gnu.org/archive/html/bug-hurd/2010-08/msg00165.html). -This can be found in <http://git.savannah.gnu.org/cgit/hurd/procfs.git/>. +This can be found in <https://git.savannah.gnu.org/cgit/hurd/procfs.git/>. Testing it is as simple as this: diff --git a/hurd/translator/tmpfs.mdwn b/hurd/translator/tmpfs.mdwn index 3d5cb74e..4db6542b 100644 --- a/hurd/translator/tmpfs.mdwn +++ b/hurd/translator/tmpfs.mdwn @@ -20,6 +20,18 @@ system|ext2fs]] on it, having a real `tmpfs` is better, as it need not deal with the additional block-level indirection layer that `ext2` (or any other disk-based file system) imposes. -`tmpfs` generally works, although it requires root permissions for file content; -see the [[discussion]] sub-pages for the past and current issues. -There is a [[!FF_project 271]][[!tag bounty]] on this task. +`tmpfs` generally works. See the [[discussion]] sub-pages for the +past and current issues. There is a [[!FF_project 271]][[!tag +bounty]] on this task. + +## How to use tmpfs + + $ settrans -ac tmp /hurd/tmpfs 1MB + $ cd tmp + $ touch file + $ cat file + + $ echo "tmpfs rocks!" > ./file + $ cat file + tmpfs rocks! + $
\ No newline at end of file diff --git a/hurd/translator/tmpfs/discussion.mdwn b/hurd/translator/tmpfs/discussion.mdwn index 72400121..d61fd796 100644 --- a/hurd/translator/tmpfs/discussion.mdwn +++ b/hurd/translator/tmpfs/discussion.mdwn @@ -107,7 +107,7 @@ License|/fdl]]."]]"""]] <antrik> mcsim: did you publish your in-progress work? <mcsim> there is a branch with working tmpfs in git repository: - http://git.savannah.gnu.org/cgit/hurd/hurd.git/log/?h=mplaneta/tmpfs/defpager + https://git.savannah.gnu.org/cgit/hurd/hurd.git/log/?h=mplaneta/tmpfs/defpager <jd823592> sorry for interrupting the meeting but i wonder what is a lazyfs? <mcsim> jd823592: lazyfs is tmpfs which uses own pager diff --git a/hurd/translator/ufs.mdwn b/hurd/translator/ufs.mdwn index 4d611e95..9e9c6f75 100644 --- a/hurd/translator/ufs.mdwn +++ b/hurd/translator/ufs.mdwn @@ -19,7 +19,7 @@ and will eat your data. <Arne`> There might be a copyright problem: <nalaginrut> well, there seems BSD-4clauses in the code: - http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/ufs/alloc.c + https://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/ufs/alloc.c <Arne`> braunr, tschwinge: Do you have any info on that? 4-clause BSD and GPL on the same code are a license incompatibility… <tschwinge> Arne`: I've put it onto my (long) TODO list. diff --git a/hurd/translator/unionfs.mdwn b/hurd/translator/unionfs.mdwn index 06524f3e..31162c37 100644 --- a/hurd/translator/unionfs.mdwn +++ b/hurd/translator/unionfs.mdwn @@ -15,7 +15,7 @@ License|/fdl]]."]]"""]] *Unionfs allows you to simply union one directory or translator into another one, so you see the files of both of them side by side.* -Source repository: <http://git.savannah.gnu.org/cgit/hurd/unionfs.git/> +Source repository: <https://git.savannah.gnu.org/cgit/hurd/unionfs.git/> Right now there are some problems with syncing, so please be aware that it might not work as expected. diff --git a/hurd/translator/xmlfs.mdwn b/hurd/translator/xmlfs.mdwn index a4de1668..6028d43f 100644 --- a/hurd/translator/xmlfs.mdwn +++ b/hurd/translator/xmlfs.mdwn @@ -11,6 +11,80 @@ License|/fdl]]."]]"""]] `xmlfs` is a translator that provides access to XML documents through the filesystem. +# How to Use xmlfs + + xmlfs - a translator for accessing XML documents + +This is only an alpha version. It works in read only. It supports +text nodes and attributes. It doesn't do anything fancy like size +computing, though. Here is an example of how to use it: + + $ wget http://cvs.savannah.nongnu.org/viewvc/*checkout*/hurdextras/xmlfs/example.xml?content-type=text%2Fplain; + $ settrans -ca xml /hurd/xmlfs example.xml #the website says to use ./xmlfs + $ cd xml; ls + library0 library1 + $ cd library0; ls -A + .text1 .text2 @name book0 book1 book2 sub-library0 sub-library1 + $ cat .text2 + +CDATA, again ! + + $ cat book0 + <book> + <author>Mark Twain</author> + <title>La case de l'oncle Tom</title> + <isbn>4242</isbn> + </book> + $ cat book0/author/.text + Mark Twain + +As you can see, text nodes are named .textN, with N an integer +starting from 0. Sorting is supposed to be stable, so you get the same +N every time you access the same file. If there is only one text node +at this level, N is ommitted. Attributes are prefixed with @. + +An example file, example.xml, is provided. Of course, it does not +contain anything useful. xmlfs has been tested on several-megabytes +XML documents, though. + +Comments are welcome. + + -- Manuel Menal <mmenal@hurdfr.org> + +# TODO +- Handle memory usage in a clever way: + - do not dump the nodes at each read, try to guess if read() + is called in a sequence of read() operations (e.g. cat reads + 8192 bytes by 8192 bytes) and if it is, cache the node + contents. That'd need a very small ftpfs-like GC. + - perhaps we shouldn't store the node informations from + first access to end and have a pool of them. That might come + with next entries though. +- Handle changes of the backing store (XML document) while running. + (Idea: we should probably attach to the XML node and handle + read()/write() operations ourselves, with libxml primitives.) +- Write support. Making things like echo >, sed and so on work is + quite obvious. Editing is not -that- simple, 'cause we could + want to save a not XML well-formed, and libxml will just return + an error. Perhaps we should use something like 'sync'. +- Handle error cases in a more clever way ; there are many error + conditions that will just cause xmlfs to crash or do strange + things. We should review them. +- Make sorting *really* stable. + +# TODO WISHLIST +-------- + +- Kilobug suggested a --xslt option that would make xmlfs provide + a tree matching the XSLT-modified document. + (Problem: In this case we cannot attach easily to the .xml 'cause + the user would loose access to theirs original document. Perhaps + we should allow an optional "file.xml" argument and check if it + is not the same as the file we are attaching to when --xslt is + specified.) +- DTD support ; perhaps XML schema/RelaxNG when I'm sure I understand + them ;-) + # Source diff --git a/ikiwiki.setup b/ikiwiki.setup index 1f58e0b8..9c21acb9 100644 --- a/ikiwiki.setup +++ b/ikiwiki.setup @@ -49,9 +49,9 @@ IkiWiki::Setup::Standard->import({ # where to build the wiki destdir => $destdir, # base url to the wiki - url => 'http://darnassus.sceen.net/~hurd-web', + url => 'https://darnassus.sceen.net/~hurd-web', # url to the ikiwiki.cgi - cgiurl => 'http://darnassus.sceen.net/cgi-bin/hurd-web', + cgiurl => 'https://darnassus.sceen.net/cgi-bin/hurd-web', # filename of cgi wrapper to generate cgi_wrapper => $cgi_wrapper, # mode for cgi_wrapper (can safely be made suid) @@ -151,9 +151,9 @@ IkiWiki::Setup::Standard->import({ # unix users whose commits should be checked by the pre-receive hook #untrusted_committers => [], # gitweb url to show file history ([[file]] substituted) - historyurl => 'http://darnassus.sceen.net/cgit/hurd-web.git/log/[[file]]', + historyurl => 'https://darnassus.sceen.net/cgit/hurd-web.git/log/[[file]]', # gitweb url to show a diff ([[file]], [[sha1_to]], [[sha1_from]], [[sha1_commit]], and [[sha1_parent]] substituted) - diffurl => 'http://darnassus.sceen.net/cgit/hurd-web.git/commit/[[file]]?id=[[sha1_commit]]', + diffurl => 'https://darnassus.sceen.net/cgit/hurd-web.git/commit/[[file]]?id=[[sha1_commit]]', # where to pull and push changes (set to empty string to disable) gitorigin_branch => $gitorigin_branch, # branch that the wiki is stored in @@ -325,9 +325,9 @@ IkiWiki::Setup::Standard->import({ # repolist plugin # URIs of repositories containing the wiki's source repositories => [qw{git://git.savannah.gnu.org/hurd/web.git - http://git.savannah.gnu.org/cgit/hurd/web.git + https://git.savannah.gnu.org/cgit/hurd/web.git git://darnassus.sceen.net/hurd-web.git - http://darnassus.sceen.net/cgit/hurd-web.git}], + https://darnassus.sceen.net/cgit/hurd-web.git}], # search plugin # path to the omega cgi program @@ -48,7 +48,7 @@ actions=yes]] Older news entries can be found in the [[news archive|news]]. For Hurd developers' musings have a look at the [[shared weblog|community/weblogs]]. -The [[recent changes]] page lists the latest changes of this website. +The [[@_recent_changes]] page lists the latest changes of this website. --- # Contributing @@ -44,12 +44,13 @@ everyone, take your chance to chat with GNU Hurd developers! # Channels -## Freenode +## Libera.Chat -`irc.freenode.net`, <http://freenode.net/> +`irc.libera.chat`, <http://libera.chat/> * `#hurd`, the official GNU Hurd IRC channel. Some of the Hurd developers - and users hang out there. [Logs](http://richtlijn.be/~larstiq/hurd/). + and users hang out there. [Old logs](http://richtlijn.be/~larstiq/hurd/). + [New logs](https://logs.guix.gnu.org/hurd). * `#hurdfr`, the French chapter. diff --git a/libpthread.mdwn b/libpthread.mdwn index 0f7f28fe..cc1c26c8 100644 --- a/libpthread.mdwn +++ b/libpthread.mdwn @@ -14,7 +14,7 @@ License|/fdl]]."]]"""]] # Sources -<http://git.savannah.gnu.org/cgit/hurd/libpthread.git/> +<https://git.savannah.gnu.org/cgit/hurd/libpthread.git/> # Specifics @@ -58,8 +58,6 @@ the next thread. So the issue is that the shrinkage of resource consumption never happens, but it doesn't grow without bounds; it just stays at the maximum even if the current number of threads is lower. -The same issue exists in [[hurd/libthreads]]. - The current implementation in libpthread is [[buggy|open_issues/libpthread/t/fix_have_kernel_resources]]. diff --git a/media_appearances.mdwn b/media_appearances.mdwn index 96c4d242..c4445f76 100644 --- a/media_appearances.mdwn +++ b/media_appearances.mdwn @@ -16,6 +16,13 @@ A lot of stuff is missing here. [[!toc levels=2]] +# 2021 + +## February + + * FOSDEM: {{$community/meetings/fosdem_2022#zammit_hurd}} + + # 2019 ## February diff --git a/microkernel/mach.mdwn b/microkernel/mach.mdwn index e9127a37..3abb548d 100644 --- a/microkernel/mach.mdwn +++ b/microkernel/mach.mdwn @@ -10,7 +10,7 @@ License|/fdl]]."]]"""]] [[!meta title="Mach"]] -Mach is a so-called first generation [[microkernel]]. Originally developed by Carnegie Mellon University (MCU) from 1985 to 1994, which was then forked and carried from 1996 onward by GNU. It is the +Mach is a so-called first generation [[microkernel]]. Originally developed by Carnegie Mellon University (CMU) from 1985 to 1994, which was then forked and carried from 1996 onward by GNU. It is the microkernel currently used by the [[Hurd]]. * [[Concepts]] @@ -18,15 +18,13 @@ microkernel currently used by the [[Hurd]]. * [[Documentation]] * [[History]] * [Torvalds, Tanenbaum - Debate](http://www.dina.dk/~abraham/Linus_vs_Tanenbaum.html) + Debate](http://choices.cs.illinois.edu/cache/Linus_vs_Tanenbaum.html) # Implementations * [[GNU_Mach|gnumach]] - * [Apple's Darwin](http://developer.apple.com/darwin/) - ([API](http://developer.apple.com/documentation/Darwin/Conceptual/KernelProgramming/index.html)) - (**non-free**) + * [Apple's XNU (Darwin)](https://github.com/apple-oss-distributions/xnu) (**non-free**) * [[open_issues/OSF_Mach]] diff --git a/microkernel/mach/gnumach/building.mdwn b/microkernel/mach/gnumach/building.mdwn index d3fe670a..b23985ac 100644 --- a/microkernel/mach/gnumach/building.mdwn +++ b/microkernel/mach/gnumach/building.mdwn @@ -19,55 +19,53 @@ enabled) is around 50 MiB. ## Getting the Source Code -You can either use the git repository (see <http://git.savannah.gnu.org/git/hurd/>), +You can either use the git repository (see <https://git.savannah.gnu.org/git/hurd/>), $ git clone https://git.savannah.gnu.org/git/hurd/gnumach.git/ + $ cd gnumach + $ autoreconf --install -... or get the Debian sources, if you're using Debian. (See +... or get the Debian sources to build a Debian package, if you're using Debian. (See [here](http://packages.debian.net/source/unstable/gnumach).) - $ apt-get source gnumach + $ apt source gnumach + $ cd gnumach-XXXXXXXX -## On Debian Systems: +## Building a `.deb` package on Debian Systems: ### Preparing for the Build Building GNU Mach requires the *build-essential* and *fakeroot* packages, and some additional dependencies specified by the gnumach source package: - # apt-get install build-essential fakeroot - # apt-get build-dep gnumach + # apt install build-essential fakeroot + # apt build-dep gnumach ### Building and Installing ... Debian `.deb` files -Change into the directory with the downloaded / unpacked GNU Mach sources, +Start the build process with - $ cd gnumach-XXXXXXXX + $ dpkg-buildpackage -us -uc -b -Start the build process with +But to get it built faster, you probably want to only build the most common uniprocessor variant: - $ dpkg-buildpackage -us -uc -b -rfakeroot + $ dpkg-buildpackage -us -uc -b -Ppkg.gnumach.onlyup [[GNU_Mach|gnumach]] is now building. To use the new kernel, you must install the resulting `.deb` package which is located one directory above the build directory and has a similar name as the build directory: - # dpkg -i ../gnumach_XXXXXXXX-X_hurd-i386.deb + # dpkg -i ../gnumach-image-1.8-486_*_hurd-i386.deb You can now reboot your computer and enjoy the new kernel. -## On non-Debian Systems: +## Building from the git repository: ### Preparing for the Build Building GNU Mach requires a C compiler, a _static_ 32 bit standard C library, your favourite flavor of awk (gawk) and GNU make. -First, create the configuration files: - - $ cd gnumach - $ autoreconf --install - GNU Mach (and the associated headers) need be built in a separate build directory: $ mkdir build @@ -77,7 +75,7 @@ Run configure: $ ../configure --prefix= -If building on a 64 bit host system, +If building on a Linux 64 bit host system, you need a number of additional settings to force a 32 bit build: $ ../configure --prefix= --host=i686-gnu LD=i686-linux-gnu-ld CC=i686-linux-gnu-gcc diff --git a/microkernel/mach/gnumach/debugging.mdwn b/microkernel/mach/gnumach/debugging.mdwn index 9534c758..bcff970e 100644 --- a/microkernel/mach/gnumach/debugging.mdwn +++ b/microkernel/mach/gnumach/debugging.mdwn @@ -73,15 +73,102 @@ and then type continue, to let Mach continue execution. The debugger will be ent struct db_watchpoint watch = { .task = NULL, .loaddr= 0x40e, .hiaddr = 0x40e+2, .link = NULL}; db_set_hw_watchpoint(&watch, 0); +To discover what an arbitrary address points to, try + + whatis 0x123400 + # GDB in QEMU When you're [[running_a_system_in_QEMU|hurd/running/qemu]] you can directly [use GDB on the running -kernel](http://www.nongnu.org/qemu/qemu-doc.html#SEC48). +kernel](https://www.qemu.org/docs/master/system/gdb.html). + +When debugggin 32-bit gnumach, you can specify the kernel file in the +command line with the `-kernel` option and the boot modules with +`-initrd`, as described in [[hurd/running/qemu]]. This however does +not work for 64-bit gnumach, due to a [limitation in +qemu](https://gitlab.com/qemu-project/qemu/-/issues/243). To overcome +this, you can either patch qemu to enable multiboot also for 64-bit +ELF, or build a bootable ISO image with `grub-mkrescue`. + +To enable the gdbserver on a running instance, you need to access the +qemu monitor and use the `gdbserver` command. For example, with +libvirt/virt-manager + + $ virsh --connect qemu:///session qemu-monitor-command --domain hurd --hmp --cmd gdbserver + +Otherwise, if you start qemu manually, you can use the `-s` and `-S` +shortcuts, that will open a tcp connection on port 1234 and wait for +gdb to attach before starting the vm. + +If you don't need a graphical interface, e.g. you're working on the +boot process, you could use stdio as an emulated serial port with +`-nographic`, and append `console=com0` to the kernel command line, +either in grub or with the `-append` option. + +Once qemu has started, you can connect to the gdbserver with + + $ gdb gnumach + ... + (gdb) target remote :1234 + (gdb) c + +You can also automate some steps with a `.gdbinit` file in your +working directory. For example: + + set print pretty + target remote :1234 + # let's set some breakpoints + b Panic + b c_boot_entry + b user_bootstrap + b ../i386/intel/pmap.c:1981 + # we can also refer to virtual addresses in userspace + b *0x804901d + # this shows the instruction being executed + display/i $pc + layout asm ## [[open_issues/debugging_gnumach_startup_qemu_gdb]] +## Debug 64-bit gnumach + +[[build|microkernel/mach/gnumach/building/]] 64-bit gnumach with: + + $ export CFLAGS=-g + $ ../configure --enable-kdb ... + +run a spare Hurd vm (prepare for data loss in vm): + +* `kvm -net user,hostfwd=tcp:127.0.0.1:2222-:22 -net nic,model=e1000 -drive file=$(echo debian-hurd*.img),cache=writeback -m 1G` +* `cd gnumach/build` +* `scp -P 2222 gnumach.gz user@127.0.0.1:/home/user/` +* You may copy `gnumach.gz` (also create new grub entry) or replace using `mv /home/user/gnumach.gz /boot/gnumach-xxx.gz` +* Shutdown vm. +* Append `console=com0` in boot menu and switch to console mode in qemu. (We have known issues with vga output for 64-bit.) +* You may load only required modules for debugging. +* `kvm -s -S -net user,hostfwd=tcp:127.0.0.1:2222-:22 -net nic,model=e1000 -drive file=$(echo debian-hurd*.img),cache=writeback -m 1G` (note: `-s -S` added.) +* `gdb ./gnumach` +* `(gdb) target remote :1234` +* Press `c` to continue booting. + + +example `/boot/grub/grub.cfg`: + + multiboot /boot/gnumach-1.8-486.gz root=part:2:device:hd0 console=com0 + ... + echo 'Loading the Hurd ...' + module /hurd/ext2fs.static ext2fs --readonly \ + --multiboot-command-line='${kernel-command-line}' \ + \ + --host-priv-port='${host-port}' --device-master-port='${device-port}' \ + --exec-server-task='${exec-task}' -T typed '${root}' \ + '$(fs-task=task-create)' '$(task-resume)' + module /lib/ld.so.1 exec /hurd/exec '$(exec-task=task-create)' + + + # Code Inside the Kernel diff --git a/microkernel/mach/gnumach/preemption.mdwn b/microkernel/mach/gnumach/preemption.mdwn index 520f7bc9..130bb58b 100644 --- a/microkernel/mach/gnumach/preemption.mdwn +++ b/microkernel/mach/gnumach/preemption.mdwn @@ -11,7 +11,7 @@ License|/fdl]]."]]"""]] [[!tag open_issue_gnumach]] -There currently is no kernel preemption in GNU Mach. +There currently is no kernel-land preemption in GNU Mach, only user-land preemption. If GNU Mach were made a a preemptive kernel, using [[continuation]]s would probably no longer make sense as the kernel itself, that is, kernel threads can diff --git a/microkernel/mach/mig/documentation.mdwn b/microkernel/mach/mig/documentation.mdwn index 07299d48..740949e0 100644 --- a/microkernel/mach/mig/documentation.mdwn +++ b/microkernel/mach/mig/documentation.mdwn @@ -57,7 +57,9 @@ November 1989. Department of Computer Science, Carnegie-Mellon University. See the citations about [Mach and matchmaker: kernel and language support for objectoriented distributed -systems](http://citeseer.ist.psu.edu/context/93073/0). "M. B. Jones and +systems](http://citeseer.ist.psu.edu/context/93073/0) +[(pdf)](https://kilthub.cmu.edu/ndownloader/files/12097610). +"M. B. Jones and R. F. Rashid, *Mach and matchmaker: kernel and language support for objectoriented distributed systems*, Proceedings of the Conference on Object-Oriented Programming Systems, Languages, and Applications, October 1986, diff --git a/microkernel/mach/mig/gnu_mig/building.mdwn b/microkernel/mach/mig/gnu_mig/building.mdwn index 486c461e..eed12e03 100644 --- a/microkernel/mach/mig/gnu_mig/building.mdwn +++ b/microkernel/mach/mig/gnu_mig/building.mdwn @@ -24,7 +24,7 @@ RCS](https://git.savannah.gnu.org/git/hurd/): ... or (if you are working on a Debian system) get the sources that are used for the [current Debian mig package](http://packages.debian.net/source/unstable/mig): - $ apt-get source mig + $ apt source mig The unpacked source tree is around 1 MiB, and the build tree also is around 1 MiB. @@ -35,8 +35,8 @@ The unpacked source tree is around 1 MiB, and the build tree also is around 1 Mi Building MIG requires the *build-essential* and *fakeroot* packages, and some additional dependencies specified by the mig source package: - # apt-get install build-essential fakeroot - # apt-get build-dep mig + # apt install build-essential fakeroot + # apt build-dep mig ### <a name="Building_and_Installing"> Building and Installing </a> <a name="_a_deb_file"> ... a _.deb_ file </a> @@ -48,6 +48,9 @@ Start the build process: $ dpkg-buildpackage -us -uc -b -rfakeroot +Note: if you are building on a non-32bit system, you need to also pass e.g. +`--target-arch=i386` to build the 32bit version. + This will create a _.deb_ package in the parent directory, which you can then install on your system. @@ -81,10 +84,10 @@ configure: $ GNU=~/gnu $ TARGET_CPPFLAGS=-I"$GNU"/include ../configure --prefix="$GNU" -If you are building on a 64 bit machine, you need to add a --host option: +If you want to build 32-bit gnumach on a 64-bit machine, you need to add a --target option. mig(com) will be build as ELF64 binary, but it will generate 32-bit stub code for gnumach: $ GNU=~/gnu - $ TARGET_CPPFLAGS=-I"$GNU"/include ../configure --prefix="$GNU" --host=i686-unknown-linux-gnu + $ TARGET_CPPFLAGS=-I"$GNU"/include ../configure --prefix="$GNU" --target=i686-gnu TARGET_CC=i686-linux-gnu-gcc Build and install the Mach Interface Generator into _$GNU_ (i.e. _~/gnu/_ in our example): diff --git a/microkernel/mach/thread.mdwn b/microkernel/mach/thread.mdwn index ccce643e..911b4493 100644 --- a/microkernel/mach/thread.mdwn +++ b/microkernel/mach/thread.mdwn @@ -32,6 +32,6 @@ Threads have scheduling parameters and maintain various statistics about themselves. On GNU/Hurd, APIs for Mach threads and thereabouts are provided by the -[[hurd/libthreads]] (cthreads), and [[libpthread]] (POSIX Threads) packages. +[[/libpthread]] (POSIX Threads) package. A task backing a thread is the basis for a [[UNIX process|unix/process]]. diff --git a/microkernel/viengoos.mdwn b/microkernel/viengoos.mdwn index 66c6ff36..f8643f7f 100644 --- a/microkernel/viengoos.mdwn +++ b/microkernel/viengoos.mdwn @@ -23,7 +23,7 @@ to some of the [[issues_uncovered_by_the_Hurd|challenges]]. Knowledge gained can then be integrated into something like [[Mach]]. The source can be downloaded from the *viengoos.git* repository, cf. -<http://git.savannah.gnu.org/gitweb/?p=hurd/viengoos.git>. You can +<https://git.savannah.gnu.org/gitweb/?p=hurd/viengoos.git>. You can check it out using, for example: git clone git://git.sv.gnu.org/hurd/viengoos.git diff --git a/news/2009-06-30.mdwn b/news/2009-06-30.mdwn index 5031de6c..ca5d4b3e 100644 --- a/news/2009-06-30.mdwn +++ b/news/2009-06-30.mdwn @@ -20,7 +20,7 @@ else="[[!paste id=full_news]]"]] > This month Thomas Schwinge [finished > migrating](http://lists.gnu.org/archive/html/bug-hurd/2009-06/msg00147.html) > the main Hurd, GNU Mach, MIG, libpthread and unionfs to Git. You can find -> the new repositories at <http://git.savannah.gnu.org/cgit/hurd/>. +> the new repositories at <https://git.savannah.gnu.org/cgit/hurd/>. > Also, he made [libpthread buildable > stand-alone](http://lists.gnu.org/archive/html/bug-hurd/2009-06/msg00166.html) diff --git a/news/2009-10-31.mdwn b/news/2009-10-31.mdwn index 5d625470..d41477cf 100644 --- a/news/2009-10-31.mdwn +++ b/news/2009-10-31.mdwn @@ -32,7 +32,7 @@ else="[[!paste id=full_news]]"]] > Also, Thomas Schwinge migrated Sergiu Ivanov's [[hurd/translator/nsmux]], > [[Flávio Cruz|flaviocruz]]' cl-hurd *(clisp bindings)*, and Carl Fredrik > Hammar [[hurd/libchannel]] repositories into our new [*incubator* Git -> repository](http://git.savannah.gnu.org/cgit/hurd/incubator.git/), making +> repository](https://git.savannah.gnu.org/cgit/hurd/incubator.git/), making > them easier to access for other contributors. > Our bunch of porters continued to make further Debian packages usable on diff --git a/news/2010-04-30.mdwn b/news/2010-04-30.mdwn index 0b50122d..4b0a2d4b 100644 --- a/news/2010-04-30.mdwn +++ b/news/2010-04-30.mdwn @@ -46,7 +46,7 @@ else="[[!paste id=full_news]]"]] > run with a simple `qemu -m 512 -hda debian-hurd-17042010-qemu.img`. > *Thomas Schwinge* updated [our glibc maintenance -> repository](http://git.savannah.gnu.org/cgit/hurd/glibc.git/?h=tschwinge/Roger_Whittaker) +> repository](https://git.savannah.gnu.org/cgit/hurd/glibc.git/?h=tschwinge/Roger_Whittaker) > to a recent version, including a bunch of the patches from the Debian glibc > package (and these are meant to eventually be submitted upstream). After a > long break, he as well diff --git a/news/2010-08-31.mdwn b/news/2010-08-31.mdwn index f3910b15..d78f6b64 100644 --- a/news/2010-08-31.mdwn +++ b/news/2010-08-31.mdwn @@ -60,8 +60,8 @@ else="[[!paste id=full_news]]"]] > looking for a Hurd-related project to work on, go looking > [[there|open_issues]]! He also converted and merged some of the [hurdextras > CVS repositories](http://www.nongnu.org/hurdextras/) into the [hurd Git -> repositories](http://git.savannah.gnu.org/cgit/hurd) and our -> [incubator](http://git.savannah.gnu.org/cgit/hurd/incubator.git/refs/). All +> repositories](https://git.savannah.gnu.org/cgit/hurd) and our +> [incubator](https://git.savannah.gnu.org/cgit/hurd/incubator.git/refs/). All > of this should make it easier for new contributors to join in. > The [[hurd/running/Arch_Hurd]] guys have some news to share, too: diff --git a/news/2010-10.mdwn b/news/2010-10.mdwn index c7312256..0f098a1f 100644 --- a/news/2010-10.mdwn +++ b/news/2010-10.mdwn @@ -53,7 +53,7 @@ Thomas Schwinge: > [[flubber|public_hurd_boxen]]'s root file system is totally hosed, and thus > needs to be > [re-installed](http://lists.gnu.org/archive/html/bug-hurd/2010-10/msg00003.html). -> (I've been running `apt-get dist-upgrade` when the box apparently crashed.) +> (I've been running `apt dist-upgrade` when the box apparently crashed.) > Running `e2fsck` on it spew out over 50.000 lines of illegal and > multiply-claimed block lists, before I terminated it, so no chance. I'll do > this over the weekend. `/home/` etc. are not affected, thanks to being on a diff --git a/news/2010.mdwn b/news/2010.mdwn index 2ba85266..a1adc686 100644 --- a/news/2010.mdwn +++ b/news/2010.mdwn @@ -65,7 +65,7 @@ the previous CD images, which were using an installer based on the old Debian boot floppies (and running under the Linux kernel)---Philip Charles has been maintaining these single-handedly for almost ten years! The new installer images are available from -<http://people.debian.org/~sthibault/hurd-i386/installer/cdimage/>. +<https://cdimage.debian.org/cdimage/ports/stable/hurd-i386>. Emilio Pozuelo Monfort was investigating specific compatibility problems exposed by the extensive test suites coming with some diff --git a/news/2011-q2-ps.mdwn b/news/2011-q2-ps.mdwn index f62a23ae..bb3c7fd7 100644 --- a/news/2011-q2-ps.mdwn +++ b/news/2011-q2-ps.mdwn @@ -102,7 +102,7 @@ the more common misunderstandings. * **Installation can still be challenging**: Please [[take notice|http://xkcd.com/293/]] of the - [README file](http://people.debian.org/~sthibault/hurd-i386/installer/cdimage/YES_REALLY_README.txt) -- + [README file](https://cdimage.debian.org/cdimage/ports/stable/hurd-i386/YES_REALLY_README.txt) -- just like with any software in development, there are some known pitfalls to avoid. (Or better yet, help to fix.) :-) diff --git a/news/2011-q2.mdwn b/news/2011-q2.mdwn index 1c677670..d6c962ac 100644 --- a/news/2011-q2.mdwn +++ b/news/2011-q2.mdwn @@ -34,7 +34,7 @@ Samuel Thibault [created](http://lists.gnu.org/archive/html/bug-hurd/2011-05/msg00189.html) the first Debian GNU/Hurd CD set with a graphical installer. You can dowload it at [the usual place for Debian CD -images](http://people.debian.org/~sthibault/hurd-i386/installer/cdimage/). +images](https://cdimage.debian.org/cdimage/ports/stable/hurd-i386). Amongst others, Samuel also [tracked down and fixed](http://lists.gnu.org/archive/html/bug-hurd/2011-05/msg00025.html) a port diff --git a/news/2011-q3.mdwn b/news/2011-q3.mdwn index 83fc30a5..587a8b6e 100644 --- a/news/2011-q3.mdwn +++ b/news/2011-q3.mdwn @@ -71,7 +71,7 @@ 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), +allocator](https://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 diff --git a/news/2012-q1-q2.mdwn b/news/2012-q1-q2.mdwn index 675883b9..86305a11 100644 --- a/news/2012-q1-q2.mdwn +++ b/news/2012-q1-q2.mdwn @@ -59,11 +59,11 @@ using a Nix-based GNU QEMU image. Thanks to his work, we now have Thomas on the other hand [moved](http://lists.gnu.org/archive/html/bug-hurd/2012-03/msg00063.html) the translators -[cvsfs](http://git.savannah.gnu.org/cgit/hurd/incubator.git/log/?h=cvsfs/master) +[cvsfs](https://git.savannah.gnu.org/cgit/hurd/incubator.git/log/?h=cvsfs/master) and -[smbfs](http://git.savannah.gnu.org/cgit/hurd/incubator.git/log/?h=smbfs/master) +[smbfs](https://git.savannah.gnu.org/cgit/hurd/incubator.git/log/?h=smbfs/master) into the [[incubator Git repository|source_repositories/incubator]], as well as -[libfuse](http://git.savannah.gnu.org/cgit/hurd/incubator.git/log/?h=libfuse/master), +[libfuse](https://git.savannah.gnu.org/cgit/hurd/incubator.git/log/?h=libfuse/master), reducing the barrier of entry to improving them, so integrating cvs and samba in the filesystem and using FUSE translators can be stabilized more easily. Also he @@ -84,10 +84,10 @@ took a dive into the core of the Hurd. Ludovic and [made console-run resilient against missing /dev/console](http://lists.gnu.org/archive/html/bug-hurd/2012-03/msg00002.html). Maksym [tested the performance of tmpfs](http://lists.gnu.org/archive/html/bug-hurd/2012-03/msg00040.html), -showing a speedup for apt-get calls from 22 seconds with +showing a speedup for apt calls from 22 seconds with [[hurd/libstore/examples/ramdisk]] and 32 seconds with [[hurd/translator/ext2fs]] to 16 seconds with [[hurd/translator/tmpfs]] for -apt-get invocations, showing the possible wins due to going deep. An obvious +apt invocations, showing the possible wins due to going deep. An obvious use case for tmpfs are [faster Hurd LiveCDs](http://lists.gnu.org/archive/html/bug-hurd/2012-03/msg00050.html). Samuel made it easier to dive in by diff --git a/news/2012-q3-q4.mdwn b/news/2012-q3-q4.mdwn index c0b8b3a0..d8178fa9 100644 --- a/news/2012-q3-q4.mdwn +++ b/news/2012-q3-q4.mdwn @@ -47,8 +47,8 @@ changes. Also Samuel Thibault [provided](http://lists.gnu.org/archive/html/bug-hurd/2012-12/msg00052.html) new [installation -CDs](http://people.debian.org/~sthibault/hurd-i386/installer/cdimage/current) -and a new [QEMU image](http://people.debian.org/~sthibault/hurd-i386/). +CDs](https://cdimage.debian.org/cdimage/ports/stable/hurd-i386) +and a new [QEMU image](https://cdimage.debian.org/cdimage/ports/stable/hurd-i386). Additionally to using pthreads, these now offer keyboard layout configuration. In [[glibc]], diff --git a/news/2013-09-27.mdwn b/news/2013-09-27.mdwn index bb574247..4c4e9b81 100644 --- a/news/2013-09-27.mdwn +++ b/news/2013-09-27.mdwn @@ -25,13 +25,13 @@ than the [GNU project's 30th birthday](http://www.gnu.org/gnu30/)? * **GNU Hurd 0.5**: [[!message-id desc=announcement "874n960vyq.fsf@kepler.schwinge.homeip.net"]], - [NEWS](http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/NEWS?id=v0.5) + [NEWS](https://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/NEWS?id=v0.5) * **GNU Mach 1.4**: [[!message-id desc=announcement "8761tm0vz8.fsf@kepler.schwinge.homeip.net"]], - [NEWS](http://git.savannah.gnu.org/cgit/hurd/gnumach.git/tree/NEWS?id=v1.4) + [NEWS](https://git.savannah.gnu.org/cgit/hurd/gnumach.git/tree/NEWS?id=v1.4) * **GNU MIG 1.4**: [[!message-id desc=announcement "877ge20vzt.fsf@kepler.schwinge.homeip.net"]], - [NEWS](http://git.savannah.gnu.org/cgit/hurd/mig.git/tree/NEWS?id=v1.4) + [NEWS](https://git.savannah.gnu.org/cgit/hurd/mig.git/tree/NEWS?id=v1.4) These new releases bundle bug fixes and enhancements done since the last releases more than a decade ago; really too many (both years and diff --git a/news/2015-04-10-releases.mdwn b/news/2015-04-10-releases.mdwn index f3064f20..853eb81a 100644 --- a/news/2015-04-10-releases.mdwn +++ b/news/2015-04-10-releases.mdwn @@ -20,13 +20,13 @@ else=" * **GNU Hurd 0.6**: [[!message-id desc=announcement "8738415d4z.fsf@kepler.schwinge.homeip.net"]], - [NEWS](http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/NEWS?id=v0.6) + [NEWS](https://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/NEWS?id=v0.6) * **GNU Mach 1.5**: [[!message-id desc=announcement "87618x5d5o.fsf@kepler.schwinge.homeip.net"]], - [NEWS](http://git.savannah.gnu.org/cgit/hurd/gnumach.git/tree/NEWS?id=v1.5) + [NEWS](https://git.savannah.gnu.org/cgit/hurd/gnumach.git/tree/NEWS?id=v1.5) * **GNU MIG 1.5**: [[!message-id desc=announcement "874moh5d5c.fsf@kepler.schwinge.homeip.net"]], - [NEWS](http://git.savannah.gnu.org/cgit/hurd/mig.git/tree/NEWS?id=v1.5) + [NEWS](https://git.savannah.gnu.org/cgit/hurd/mig.git/tree/NEWS?id=v1.5) If you want to give the Hurd a try, you may easily do so with [[Debian GNU/Hurd|hurd/running/debian]]. diff --git a/news/2015-10-31-releases.mdwn b/news/2015-10-31-releases.mdwn index 75ceb9cf..b721b1fd 100644 --- a/news/2015-10-31-releases.mdwn +++ b/news/2015-10-31-releases.mdwn @@ -21,7 +21,7 @@ else=" We're pleased to announce new releases! * **GNU Hurd 0.7**, - [NEWS](http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/NEWS?id=v0.7): + [NEWS](https://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/NEWS?id=v0.7): Version 0.7 (2015-10-31) @@ -43,7 +43,7 @@ We're pleased to announce new releases! Release tarballs may be downloaded from <ftp://ftp.gnu.org/gnu/hurd/>, <http://ftp.gnu.org/gnu/hurd/>, or checked out of Git, - <http://git.savannah.gnu.org/cgit/hurd/hurd.git>. SHA1 checksums: + <https://git.savannah.gnu.org/cgit/hurd/hurd.git>. SHA1 checksums: a735a07687f7996face3bd310af2254192a02f40 hurd-0.7.tar.bz2 d10b3c1de191ac88425aa30a03c4130e2a883b14 hurd-0.7.tar.bz2.sig @@ -58,7 +58,7 @@ We're pleased to announce new releases! [[hurd/what_is_the_GNU_Hurd]]. * **GNU Mach 1.6**, - [NEWS](http://git.savannah.gnu.org/cgit/hurd/gnumach.git/tree/NEWS?id=v1.6): + [NEWS](https://git.savannah.gnu.org/cgit/hurd/gnumach.git/tree/NEWS?id=v1.6): Version 1.6 (2015-10-31) @@ -90,7 +90,7 @@ We're pleased to announce new releases! Release tarballs may be downloaded from <ftp://ftp.gnu.org/gnu/gnumach/>, <http://ftp.gnu.org/gnu/gnumach/>, or checked out of Git, - <http://git.savannah.gnu.org/cgit/hurd/gnumach.git>. SHA1 checksums: + <https://git.savannah.gnu.org/cgit/hurd/gnumach.git>. SHA1 checksums: 73e09c43955ef2e3459b2877b5e6d6bbe517b8c3 gnumach-1.6.tar.bz2 96ff426b3b94acf327a88f25c80ab5b5f26ed94a gnumach-1.6.tar.bz2.sig @@ -106,7 +106,7 @@ We're pleased to announce new releases! [[microkernel/mach/documentation]]. * **GNU MIG 1.6**, - [NEWS](http://git.savannah.gnu.org/cgit/hurd/mig.git/tree/NEWS?id=v1.6): + [NEWS](https://git.savannah.gnu.org/cgit/hurd/mig.git/tree/NEWS?id=v1.6): Version 1.6 (2015-10-31) @@ -115,7 +115,7 @@ We're pleased to announce new releases! Release tarballs may be downloaded from <ftp://ftp.gnu.org/gnu/mig/>, <http://ftp.gnu.org/gnu/mig/>, or checked out of Git, - <http://git.savannah.gnu.org/cgit/hurd/mig.git>. SHA1 checksums: + <https://git.savannah.gnu.org/cgit/hurd/mig.git>. SHA1 checksums: a9a4b5666834afe8fb861453c5b3ef324201f1d3 mig-1.6.tar.bz2 93562c45bbda40ad31f74f6f2fd0c064ef8f0ec5 mig-1.6.tar.bz2.sig @@ -134,8 +134,8 @@ We're pleased to announce new releases! Snapshot tarballs may be downloaded from <ftp://alpha.gnu.org/gnu/hurd/>, <http://alpha.gnu.org/gnu/hurd/>, or checked out of Git, - <http://git.savannah.gnu.org/cgit/hurd/glibc.git> and - <http://git.savannah.gnu.org/cgit/hurd/libpthread.git>. SHA1 checksums: + <https://git.savannah.gnu.org/cgit/hurd/glibc.git> and + <https://git.savannah.gnu.org/cgit/hurd/libpthread.git>. SHA1 checksums: 5b709297f8622444695f13723f77dfc8754b8ed9 glibc-2.19-hurd+libpthread-20151031.tar.bz2 b970e604368fd80420ef029bb1c86fc2f7b2c382 glibc-2.19-hurd+libpthread-20151031.tar.bz2.sig diff --git a/news/2016-05-18-releases.mdwn b/news/2016-05-18-releases.mdwn index ff1b2c30..33702f8c 100644 --- a/news/2016-05-18-releases.mdwn +++ b/news/2016-05-18-releases.mdwn @@ -21,7 +21,7 @@ else=" We're pleased to announce new releases! * **GNU Hurd 0.8**, - [NEWS](http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/NEWS?id=v0.8): + [NEWS](https://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/NEWS?id=v0.8): Version 0.8 (2016-05-18) @@ -45,7 +45,7 @@ We're pleased to announce new releases! Release tarballs may be downloaded from <ftp://ftp.gnu.org/gnu/hurd/>, <http://ftp.gnu.org/gnu/hurd/>, or checked out of Git, - <http://git.savannah.gnu.org/cgit/hurd/hurd.git>. SHA1 checksums: + <https://git.savannah.gnu.org/cgit/hurd/hurd.git>. SHA1 checksums: 38585aed93645704477d91d01136e1ae750a5ecb hurd-0.8.tar.bz2 531d5035427830e87828a79bf6794531250784d0 hurd-0.8.tar.bz2.sig @@ -60,7 +60,7 @@ We're pleased to announce new releases! [[hurd/what_is_the_GNU_Hurd]]. * **GNU Mach 1.7**, - [NEWS](http://git.savannah.gnu.org/cgit/hurd/gnumach.git/tree/NEWS?id=v1.7): + [NEWS](https://git.savannah.gnu.org/cgit/hurd/gnumach.git/tree/NEWS?id=v1.7): Version 1.7 (2016-05-18) @@ -83,7 +83,7 @@ We're pleased to announce new releases! Release tarballs may be downloaded from <ftp://ftp.gnu.org/gnu/gnumach/>, <http://ftp.gnu.org/gnu/gnumach/>, or checked out of Git, - <http://git.savannah.gnu.org/cgit/hurd/gnumach.git>. SHA1 checksums: + <https://git.savannah.gnu.org/cgit/hurd/gnumach.git>. SHA1 checksums: 4438c7c10f8eef019ada45b749c0796d620d08de gnumach-1.7.tar.bz2 6cdf299118066e3280dcc68f75477659fc783f7d gnumach-1.7.tar.bz2.sig @@ -99,7 +99,7 @@ We're pleased to announce new releases! [[microkernel/mach/documentation]]. * **GNU MIG 1.7**, - [NEWS](http://git.savannah.gnu.org/cgit/hurd/mig.git/tree/NEWS?id=v1.7): + [NEWS](https://git.savannah.gnu.org/cgit/hurd/mig.git/tree/NEWS?id=v1.7): Version 1.7 (2016-05-18) @@ -122,7 +122,7 @@ We're pleased to announce new releases! Release tarballs may be downloaded from <ftp://ftp.gnu.org/gnu/mig/>, <http://ftp.gnu.org/gnu/mig/>, or checked out of Git, - <http://git.savannah.gnu.org/cgit/hurd/mig.git>. SHA1 checksums: + <https://git.savannah.gnu.org/cgit/hurd/mig.git>. SHA1 checksums: 25d87f0271678d044a8af1f45492a96bee32e486 mig-1.7.tar.bz2 481dce92b8eb718231bf9d409c0e0c9337dc1f90 mig-1.7.tar.bz2.sig @@ -144,8 +144,8 @@ We're pleased to announce new releases! Snapshot tarballs may be downloaded from <ftp://alpha.gnu.org/gnu/hurd/>, <http://alpha.gnu.org/gnu/hurd/>, or checked out of Git, - <http://git.savannah.gnu.org/cgit/hurd/glibc.git> and - <http://git.savannah.gnu.org/cgit/hurd/libpthread.git>. SHA1 checksums: + <https://git.savannah.gnu.org/cgit/hurd/glibc.git> and + <https://git.savannah.gnu.org/cgit/hurd/libpthread.git>. SHA1 checksums: 3722b7f52aac89c66f064e1e6d19ec9b92ffc9e0 glibc-2.19-hurd+libpthread-20160518.tar.bz2 69dfe1297013056b4b0d6436a1b3906c1bb67a52 glibc-2.19-hurd+libpthread-20160518.tar.bz2.sig diff --git a/news/2016-12-18-releases.mdwn b/news/2016-12-18-releases.mdwn index 124358e4..6d4f9e26 100644 --- a/news/2016-12-18-releases.mdwn +++ b/news/2016-12-18-releases.mdwn @@ -21,7 +21,7 @@ else=" We're pleased to announce new releases! * **GNU Hurd 0.9**, - [NEWS](http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/NEWS?id=v0.9): + [NEWS](https://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/NEWS?id=v0.9): Version 0.9 (2016-12-18) @@ -43,7 +43,7 @@ We're pleased to announce new releases! Release tarballs may be downloaded from <ftp://ftp.gnu.org/gnu/hurd/>, <http://ftp.gnu.org/gnu/hurd/>, or checked out of Git, - <http://git.savannah.gnu.org/cgit/hurd/hurd.git>. SHA1 checksums: + <https://git.savannah.gnu.org/cgit/hurd/hurd.git>. SHA1 checksums: 7e6f406e5202501216a0da4b4ee7914f1e0a7552 hurd-0.9.tar.bz2 ffa8d40a99835824a0228bf54570c054d7fe8bf0 hurd-0.9.tar.bz2.sig @@ -58,7 +58,7 @@ We're pleased to announce new releases! [[hurd/what_is_the_GNU_Hurd]]. * **GNU Mach 1.8**, - [NEWS](http://git.savannah.gnu.org/cgit/hurd/gnumach.git/tree/NEWS?id=v1.8): + [NEWS](https://git.savannah.gnu.org/cgit/hurd/gnumach.git/tree/NEWS?id=v1.8): Version 1.8 (2016-12-18) @@ -89,7 +89,7 @@ We're pleased to announce new releases! Release tarballs may be downloaded from <ftp://ftp.gnu.org/gnu/gnumach/>, <http://ftp.gnu.org/gnu/gnumach/>, or checked out of Git, - <http://git.savannah.gnu.org/cgit/hurd/gnumach.git>. SHA1 checksums: + <https://git.savannah.gnu.org/cgit/hurd/gnumach.git>. SHA1 checksums: 4b59c7f7bc814576d2b88c43c0cdba292824f230 gnumach-1.8.tar.bz2 e6262e991a1e056bb87741a9456811cf73e8f7cd gnumach-1.8.tar.bz2.sig @@ -105,7 +105,7 @@ We're pleased to announce new releases! [[microkernel/mach/documentation]]. * **GNU MIG 1.8**, - [NEWS](http://git.savannah.gnu.org/cgit/hurd/mig.git/tree/NEWS?id=v1.8): + [NEWS](https://git.savannah.gnu.org/cgit/hurd/mig.git/tree/NEWS?id=v1.8): Version 1.8 (2016-12-18) @@ -113,7 +113,7 @@ We're pleased to announce new releases! Release tarballs may be downloaded from <ftp://ftp.gnu.org/gnu/mig/>, <http://ftp.gnu.org/gnu/mig/>, or checked out of Git, - <http://git.savannah.gnu.org/cgit/hurd/mig.git>. SHA1 checksums: + <https://git.savannah.gnu.org/cgit/hurd/mig.git>. SHA1 checksums: f765881d6ed4e883372eee52fd7842e7048a3da8 mig-1.8.tar.bz2 2091b6632176eeba1dac524d0ae939334ed51fdb mig-1.8.tar.bz2.sig @@ -135,8 +135,8 @@ We're pleased to announce new releases! Snapshot tarballs may be downloaded from <ftp://alpha.gnu.org/gnu/hurd/>, <http://alpha.gnu.org/gnu/hurd/>, or checked out of Git, - <http://git.savannah.gnu.org/cgit/hurd/glibc.git> and - <http://git.savannah.gnu.org/cgit/hurd/libpthread.git>. SHA1 checksums: + <https://git.savannah.gnu.org/cgit/hurd/glibc.git> and + <https://git.savannah.gnu.org/cgit/hurd/libpthread.git>. SHA1 checksums: 55c9b6c61991a9ea585f019c787fe0e1da756cd4 glibc-2.23-hurd+libpthread-20161218.tar.bz2 1475fff2029fcd2c655d6ea05af5efa74d224b4f glibc-2.23-hurd+libpthread-20161218.tar.bz2.sig diff --git a/news/2021-08-14-debian_gnu_hurd_2021.mdwn b/news/2021-08-14-debian_gnu_hurd_2021.mdwn new file mode 100644 index 00000000..536b85b3 --- /dev/null +++ b/news/2021-08-14-debian_gnu_hurd_2021.mdwn @@ -0,0 +1,45 @@ +[[!meta copyright="Copyright © 2021 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 date="2021-08-14 00:00 UTC"]] + +Debian GNU/Hurd 2021 released! +[[!if test="included()" then="""[[!toggle id=full_news +text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" +else=" +[[!paste id=full_news]]"]] + +[[!cut id="full_news" text=""" + +It is with huge pleasure that the Debian GNU/Hurd team announces the +**release of Debian GNU/Hurd 2021**. + +This is a snapshot of Debian "sid" at the time of the stable Debian +"bullseye" release (August 2021), so it is mostly based on the same +sources. It is not an official Debian release, but it is an official +[[Debian GNU/Hurd|hurd/running/debian]] port release. + +Read the [announcement email](https://lists.debian.org/debian-hurd/2021/08/msg00040.html). + +--- + +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/news/2023-06-11-debian_gnu_hurd_2023.mdwn b/news/2023-06-11-debian_gnu_hurd_2023.mdwn new file mode 100644 index 00000000..c814cb8d --- /dev/null +++ b/news/2023-06-11-debian_gnu_hurd_2023.mdwn @@ -0,0 +1,45 @@ +[[!meta copyright="Copyright © 2021 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 date="2023-06-11 00:00 UTC"]] + +Debian GNU/Hurd 2023 released! +[[!if test="included()" then="""[[!toggle id=full_news +text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" +else=" +[[!paste id=full_news]]"]] + +[[!cut id="full_news" text=""" + +It is with huge pleasure that the Debian GNU/Hurd team announces the +**release of Debian GNU/Hurd 2023**. + +This is a snapshot of Debian "sid" at the time of the stable Debian +"bookworm" release (June 2023), so it is mostly based on the same +sources. It is not an official Debian release, but it is an official +[[Debian GNU/Hurd|hurd/running/debian]] port release. + +Read the [announcement email](https://lists.gnu.org/archive/html/bug-hurd/2023-06/msg00038.html). + +--- + +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/news/2023-q3.mdwn b/news/2023-q3.mdwn new file mode 100644 index 00000000..c2dd012a --- /dev/null +++ b/news/2023-q3.mdwn @@ -0,0 +1,193 @@ +[[!meta copyright="Copyright © 2013 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2024-01-01 22:22 UTC"]] + +Hello! Welcome to a new qoth. This qoth covers new and interesting GNU/Hurd +developments in Q3 of 2023! +[[!if test="included()" then="""[[!toggle id=full_news +text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" +else=" +[[!paste id=full_news]]"]] + +[[!cut id="full_news" text=""" + +Joan Lledo modified the PCI arbiter to prevent mapping I/O region +files. He previously sent some patches to implement mapping region +and ROM files using `mmap()`. However, a `BAR` region can represent +either memory or I/O space, and only memory should be allowed to be +mapped. Since I/O `BARs` only contain I/O addresses, he went ahead +and [[prevented the mapping of I/O region +files|https://lists.gnu.org/archive/html/bug-hurd/2023-07/msg00041.html]]. The +next step is to make IO spaces available for users through the +pci-arbiter. He plans to add a new RPC that checks for permission and +calls `i386_io_perm_create()`. Then it returns the resulting port. + +Our Google summer of code student Vedant Tewari decided to port rust, +and the rust porting effort is making good progress. [[The build +process is a bit +wonky|https://lists.gnu.org/archive/html/bug-hurd/2023-08/msg00091.html]], +and Debian is using an older rust version. Check out [[the rust pull +request|https://github.com/rust-lang/rust/pull/115230]] that adds Hurd +support! + +[[Samuel|samuelthibault]] worked on setting up +[[PAE|https://en.wikipedia.org/wiki/Physical_Address_Extension]], +which will eventually let us use more than 4GB of RAM on a 32-bit +Hurd! It is also useful for the X86_64 architecture. He also fixed the +[[jemalloc|https://lists.debian.org/debian-hurd/2023/08/msg00000.html]] +build. + +Samuel was incredibly productive this quarter making the `X86_64` bit +port more stable. He fixed the 64-bit Hurd [[ +PIE|https://lists.gnu.org/archive/html/bug-hurd/2023-08/msg00040.html]] +build, and he got [[git +working|https://lists.gnu.org/archive/html/bug-hurd/2023-08/msg00059.html]] +on the 64-bit port! Though a few of the [[git +tests|https://lists.gnu.org/archive/html/bug-hurd/2023-08/msg00069.html]] +are failing on both `X86_64` and the 32 bit port. He fixed the [[glibc +build|https://lists.gnu.org/archive/html/bug-hurd/2023-08/msg00064.html]], +which involved fixing `pmap_remove` and `pmap_protect`. He discovered +that [[core dumping is currently causing +problems|https://lists.gnu.org/archive/html/bug-hurd/2023-08/msg00068.html]] +on the 64-bit port, and he temporarily encourages people to disable +core dumping. Samuel fixed some [[networking +issues|https://lists.gnu.org/archive/html/bug-hurd/2023-08/msg00027.html]] +and a [[dpkg +issue|https://lists.gnu.org/archive/html/bug-hurd/2023-08/msg00058.html]] +for the 64-bit port. It was hard to discover what the problem was, +because the debugging tools have not been ported to the 64-bit port. +He add some helpers to locking to fix some bugs, and he encourages other +developers to help him fix the debugging tools for X86-64. It seems +that most developers are currently running the 64-bit Hurd in a +virtual machine and not in real hardware. + +Luca Dariz got a patch series merged +[[for|https://lists.gnu.org/archive/html/bug-hurd/2023-08/msg00000.html]] +[[the|https://lists.gnu.org/archive/html/bug-hurd/2023-08/msg00001.html]] +[[64|https://lists.gnu.org/archive/html/bug-hurd/2023-08/msg00002.html]] +[[bit|https://lists.gnu.org/archive/html/bug-hurd/2023-08/msg00003.html]] +[[port|https://lists.gnu.org/archive/html/bug-hurd/2023-08/msg00004.html]]. + +Sergey implemented +[[MAP_EXCL|https://lists.gnu.org/archive/html/bug-hurd/2023-07/msg00010.html]] +and provided `MAP_FIXED_NOREPLACE` and `MAP_TRYFIXED` as aliases of +`(MAP_FIXED|MAP_EXCL)` as well other `mmap` work. He explains: + +> `MAP_FIXED` is defined to silently replace any existing mappings at +> the address range being mapped over. However, this is dangerous and +> only rarely desired behavior. +> +> Various Unix systems provide replacements or additions to `MAP_FIXED`. +> +> * SerenityOS and Linux provide `MAP_FIXED_NOREPLACE`. If the address space +> already contains a mapping in the requested range, Linux returns +> `EEXIST`. SerenityOS returns `ENOMEM`, however that is a bug, as the +> `MAP_FIXED_NOREPLACE` implementation is intended to be compatible with +> Linux. +> +> * DragonFly BSD, NetBSD, and OpenBSD provide `MAP_TRYFIXED`, but with +> different semantics. DragonFly BSD returns `ENOMEM` if the requested +> range already contains existing mappings. NetBSD does not return an +> error, but instead creates the mapping at a different address if the +> requested range contains mappings. OpenBSD behaves the same, but also +> notes that this is the default behavior even without `MAP_TRYFIXED` +> (which is the case on the Hurd too). +> +> Since the Hurd leans closer to the BSD side, add `MAP_EXCL` as the +> primary API to request the behavior of not replacing existing +> mappings. Declare `MAP_FIXED_NOREPLACE` and `MAP_TRYFIXED` as +> aliases of `(MAP_FIXED|MAP_EXCL)`, so any existing software that +> checks for either of those macros will pick them up +> automatically. For compatibility with Linux, return `EEXIST` if a +> mapping already exists. + +Damien Zammit added a USB mass storage translator via +[[rumpusbdisk|https://lists.gnu.org/archive/html/bug-hurd/2023-07/msg00025.html]]. +Though it has some issues as he explains: + +> Netdde sneems to exhibit a bug when running `ifdown /dev/eth0` +> simultanously to running the rumpusbdisk translator, because to the +> two devices share the same IRQ. + +Damien also worked on the Hurd's SMP support (much of his SMP +contributions is based on the earlier work done by Almudena Garcia): + +* He tweaked [[GNU Mach's +scheduler|https://lists.gnu.org/archive/html/bug-hurd/2023-08/msg00084.html]], +and he merged [[three|https://lists.gnu.org/archive/html/bug-hurd/2023-08/msg00080.html]] [[GNU Mach|https://lists.gnu.org/archive/html/bug-hurd/2023-08/msg00010.html]] [[commits|https://lists.gnu.org/archive/html/bug-hurd/2023-08/msg00018.html]]. + +* He added a [[show all +runqs|https://lists.gnu.org/archive/html/bug-hurd/2023-09/msg00072.html]] +command to GNU Mach's kernel debugger. + +* He also [[improved SMP in GNU +Mach|https://lists.gnu.org/archive/html/bug-hurd/2023-09/msg00048.html]] +by storing the struct processor in a percpu area and avoiding an +expensive `cpu_number` every call of `current_processor()`, as well as +getting the cpu_number from an offset in the percpu area. Further +improvements can be made by using other percpu areas. It was untested +on 64 bit. + +* Damien also taught GNU Mach to use the x86 CPUID instruction to get +the [[CPU +ID|https://lists.gnu.org/archive/html/bug-hurd/2023-08/msg00056.html]] +for speed. He reduced the time it takes to get the CPUID. He made it +100 times faster! + +* He mentioned +[[some|https://lists.gnu.org/archive/html/bug-hurd/2023-09/msg00075.html]] [[issues|https://lists.gnu.org/archive/html/bug-hurd/2023-09/msg00046.html]]: +60% of the time, booting a 32 bit Hurd, with SMP enabled, fails to +boot (sometimes apparently getting stuck in the rumpdisk). When it +does boot, it is not particularly stable and likely to crash. + +Essentially, the SMP work is progressing, but it is not ready for +production use. His recent work made the non-SMP faster, and a 32 bit +Hurd, with SMP enabled and only one core, [[appears relatively stable +(but slow to +boot)|https://lists.gnu.org/archive/html/bug-hurd/2023-09/msg00046.html]]. +The [[32-bit SMP enabled Hurd may soon be as fast as the non-SMP +Hurd|https://lists.gnu.org/archive/html/bug-hurd/2023-09/msg00074.html]]. +Eventually the SMP enabled Hurd will be faster than a non-SMP Hurd. + +Flavio Cruz halved the size of `mach_msg_type_long_t`, from 16 to 8 +bytes. He also [[simplified the overall 64bit RPC +ABI|https://lists.gnu.org/archive/html/bug-hurd/2023-08/msg00049.html]], +removing "holes" in `mach_msg_type_t` or `mach_msg_type_long_t`, which +prevents possible leakages to userspace. + +Some Hurd people talked to Kent Overstreet, the author of +[[bcachefs|https://bcachefs.org/]] to discuss the possibility of +porting Linux's newest filesystem to the Hurd; the conversation [[was +recorded|https://lists.gnu.org/archive/html/bug-hurd/2023-09/msg00073.html]]. +While most Hurd developers believe that it would possible to port +bcachefs to the Hurd, all agree that it would be difficult to port and +hard to maintain. No Hurd developers are currently planning or +working on porting bcachefs to the Hurd. But perhaps you want to? + +So if you want to test if your favorite packages work on the Hurd and +contribute towards making the full GNU system usable for a wider range +of people, please [[check the contributing page|contributing]]. + +--- + +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/news/2023-q4.mdwn b/news/2023-q4.mdwn new file mode 100644 index 00000000..ae36dea8 --- /dev/null +++ b/news/2023-q4.mdwn @@ -0,0 +1,120 @@ +[[!meta copyright="Copyright © 2013 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2024-01-05 22:22 UTC"]] + +Hello! Welcome to a new qoth. This qoth covers new and interesting GNU/Hurd +developments in Q4 of 2023! +[[!if test="included()" then="""[[!toggle id=full_news +text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" +else=" +[[!paste id=full_news]]"]] + +[[!cut id="full_news" text=""" + +Samuel Thibault fixed gcc's Hurd's default pie and [[added static pie +support|https://lists.gnu.org/archive/html/bug-hurd/2023-10/msg00061.html]]. +He also added a [[whatis +command|https://lists.gnu.org/archive/html/bug-hurd/2023-10/msg00007.html]] +to GNU Mach's kernel debugger, which can determine what an +address points to (a stack? a port? some kalloc? ...). He also added +[[hurd-amd64 support to +GCC|https://lists.debian.org/debian-hurd/2023/11/msg00039.html]]. + +Samuel requested that the Hurd team set up a [[continuous +integration,|https://lists.gnu.org/archive/html/bug-hurd/2023-12/msg00007.html]] +so that when developers make code changes, they can be certain that +they did not break anything. It turns out that the Hurd supports +several different environments: 32 bit, 64 bit, 32-on-64 bit, ACPI, +non-ACPI, SMP, non-SMP, Xen, etc. Apparently Flavio has a [[personal +CI|https://github.com/flavioc/cross-hurd/actions/runs/7080757561]], +but it is set up in a Debian independent way. If you are interested in +helping the Hurd project set up a CI, then please get in touch! + +Luca Dariz worked on adding [[some simple GNU Mach user-space tests +|https://lists.gnu.org/archive/html/bug-hurd/2023-10/msg00031.html]]. +With a working MiG, a GNU/Linux machine can run make check in the GNU +Mach source code, which will launch qemu to ensure that 32 bit (PAE +and non PAE), 32 on 64 bit, and full 64 bit GNU Mach works. We +currently do this testing on GNU/Linux, because qemu does not run on +the Hurd. + +Many people worked on the Hurd's new [[x86_64 bit +support|https://lists.gnu.org/archive/html/bug-hurd/2023-10/msg00036.html]]. +A 64-bit debian buildd is set up, and we can bootstrap a chroot! The +hurd-amd64 wanna-build infrastructure is also set up. We are having +issues reliably building packages on a 64-bit Hurd, which lead Samuel +to uncover and fix [[a proc +leak|https://lists.gnu.org/archive/html/bug-hurd/2023-11/msg00035.html]]. + +Flavio Cruz [[improved GNU Mach's +IPC|https://lists.gnu.org/archive/html/bug-hurd/2023-11/msg00033.html]] +by reordering `mach_msg_type_t` fields to byte align `msgt_name` and +`msgt_size`. He also created a patch series to [[avoid message +resizing for +x86_64|https://lists.gnu.org/archive/html/bug-hurd/2023-11/msg00028.html]]. +He also [[removed untyped mach RPC +code|https://lists.gnu.org/archive/html/bug-hurd/2023-11/msg00026.html]]. +GNU Mach uses typed IPC. The Hurd could support both typed and +untyped, but it appears that the Hurd only uses typed RPC. So it +seems best to remove any untyped RPC code. + +Sergey Bugaev added [[GNU Mach entry re-coalescing +support|https://darnassus.sceen.net/~hurd-web/open_issues/gnumach_vm_map_entry_forward_merging/]]. +Essentially, Mach was not always able to merge two vm entries that are +made next to each other, which was slowing down ext2, bash, etc. Sergey +allowed GNU Mach to merge entries in the common cases, which greatly +helps ext2fs for instance. + +Sergey is also working on [[porting the Ladybird web +browser|https://lists.gnu.org/archive/html/bug-hurd/2023-11/msg00013.html]] +to the Hurd. The author of this post uses the [[netsurf web +browser|https://www.netsurf-browser.org/]] on the Hurd, which works on +simple websites like wikipedia, but it badly renders javascript heavy +websites, which makes many websites un-useable. If Sergey is +successful in porting [[Ladybird|https://ladybird.dev/]], then Hurd +users could start using sites like Github! It is worth noting that +someone should update the [[Firefox +port|https://lists.debian.org/debian-hurd/2014/09/msg00070.html]] as +well. + +Sergey also started [[porting the Hurd to +AArch64!|https://lists.gnu.org/archive/html/bug-hurd/2023-12/msg00110.html]] +While a port to RISC-V might be more exciting, it is worth mentioning +that AArch64 is more established. What is interesting is that Sergey +is already able to build Hurd servers for AArch64! Normally, in order +to run the binaries, one would port GNU Mach to AArch64. Luckily for +us, he turned to GDB and directly ran a 'Hello World' Hurd AArch64 +binary on Linux! This helped him fix some bugs along the way. We +still need to define the ABI and complete the GNU Mach port, but this +is exciting news! + +Tobias Platen started [[porting GNU Mach to +Power9|https://lists.gnu.org/archive/html/bug-hurd/2023-10/msg00021.html]]. + +So if you want to test if your favorite packages work on the Hurd and +contribute towards making the full GNU system usable for a wider range +of people, please [[check the contributing page|contributing]]. + +--- + +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/news/2024-q1.mdwn b/news/2024-q1.mdwn new file mode 100644 index 00000000..eb756283 --- /dev/null +++ b/news/2024-q1.mdwn @@ -0,0 +1,203 @@ +[[!meta copyright="Copyright © 2013 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2024-04-05 11:07 UTC"]] + +Hello! Welcome to a new qoth. This qoth covers new and interesting GNU/Hurd +developments in Q1 of 2024! +[[!if test="included()" then="""[[!toggle id=full_news +text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" +else=" +[[!paste id=full_news]]"]] + +[[!cut id="full_news" text=""" + +Etienne Brateau modified console-client to use [xkbcommon instead of x11 for xkb +extended +support](https://lists.gnu.org/archive/html/bug-hurd/2024-03/msg00060.html), +which improves keyboard layout coverage a lot! + +Flavio Cruz also worked on [porting GDB to the 64-bit +Hurd](https://lists.gnu.org/archive/html/bug-hurd/2024-02/msg00147.html), +implemented `setcontext/getcontext/makecontext/swapcontex ()` in +[glibc](https://lists.gnu.org/archive/html/bug-hurd/2024-02/msg00106.html), and [implemented child process resource +accounting](https://lists.gnu.org/archive/html/bug-hurd/2024-02/msg00098.html). +The latter implements`getrusage(RUSAGE_CHILDREN, )` and populates child related +data in `times()`. + +He fixed the [perl testsuite for the +Hurd](https://lists.gnu.org/archive/html/bug-hurd/2024-03/msg00021.html), and he +also posted a [RFC to enhance tracing +utilities](https://lists.gnu.org/archive/html/bug-hurd/2024-03/msg00034.html), +which he used to port the RPC format to 64 bit. + +Flavio also had a smattering of fixes +[here](https://lists.gnu.org/archive/html/bug-hurd/2024-01/msg00219.html), +[here](https://lists.gnu.org/archive/html/bug-hurd/2024-02/msg00091.html), +[here](https://lists.gnu.org/archive/html/bug-hurd/2024-02/msg00151.html), +[here](https://lists.gnu.org/archive/html/bug-hurd/2024-03/msg00008.html), and +[here](https://lists.gnu.org/archive/html/bug-hurd/2024-03/msg00068.html). + +Damien Zammit had some fixes including [fixing the console with APIC +enabled](https://lists.gnu.org/archive/html/bug-hurd/2024-01/msg00277.html), +[patching GNU Mach to support ACPI +v2](https://lists.gnu.org/archive/html/bug-hurd/2024-01/msg00278.html), [fixing +baud rate on com +ports](https://lists.gnu.org/archive/html/bug-hurd/2024-01/msg00176.html), +[porting the Hurd to some AMD +CPUs](https://lists.gnu.org/archive/html/bug-hurd/2024-01/msg00220.html) (WIP), +[adding HPET (high precision +timers)](https://lists.gnu.org/archive/html/bug-hurd/2024-02/msg00039.html). He +also worked on making `ext2fs` [use xattr by default to store +translators](https://lists.gnu.org/archive/html/bug-hurd/2024-03/msg00012.html). + +Damien also worked on more SMP fixes +[here](https://lists.gnu.org/archive/html/bug-hurd/2024-02/msg00016.html), +[here](https://lists.gnu.org/archive/html/bug-hurd/2024-02/msg00021.html), +[here](https://lists.gnu.org/archive/html/bug-hurd/2024-02/msg00051.html), +[here](https://lists.gnu.org/archive/html/bug-hurd/2024-02/msg00063.html), +[here](https://lists.gnu.org/archive/html/bug-hurd/2024-02/msg00079.html), and +[here](https://lists.gnu.org/archive/html/bug-hurd/2024-02/msg00124.html). +Hurd currently boots in SMP mode on the BSP. Damien wrote a test program that lets you run a [task on the APs](https://lists.gnu.org/archive/html/bug-hurd/2024-02/msg00088.html). + +Sergey Bugaev [patched binutils to support the GNU/Hurd on +AArch64](https://lists.gnu.org/archive/html/bug-hurd/2024-01/msg00000.html), and +he wrote some patches to make the Hurd easier to port +[here](https://lists.gnu.org/archive/html/bug-hurd/2024-01/msg00002.html), +[here](https://lists.gnu.org/archive/html/bug-hurd/2024-01/msg00063.html), and +[here](https://lists.gnu.org/archive/html/bug-hurd/2024-03/msg00100.html), + +Sergey also posted a fairly large [RFC patch series for his AArch64 +port](https://lists.gnu.org/archive/html/bug-hurd/2024-01/msg00022.html). He +writes: + + MIG seems to just work (thanks to all of Flávio's work!). I'm using + the same message ABI as on x86_64, and haven't seen any issues so far + — neither compiler errors / failed static assertions (about struct + sizes and such), nor hardware errors from misaligned accesses. + + +He also mentions that "the hardware hardening features (BTI, MTE, PAC) are +currently 'not really supported', but I do want to support them in the future." +Samuel merged +[many](https://lists.gnu.org/archive/html/bug-hurd/2024-01/msg00050.html) +[of](https://lists.gnu.org/archive/html/bug-hurd/2024-01/msg00051.html) +[the](https://lists.gnu.org/archive/html/bug-hurd/2024-01/msg00052.html) +[patches](https://lists.gnu.org/archive/html/bug-hurd/2024-01/msg00062.html). + +In Sergey's later glibc patch series, he wrote about the [AArch64 port +progress](https://lists.gnu.org/archive/html/bug-hurd/2024-03/msg00114.html). He +wrote: + + Last time, there was no AArch64 port of GNU Mach, and so the only testing + I have done was running a simple statically-linked executable on Linux under + GDB, which, nevertheless, helped me identify and fix a number of issues. + + Since then, however, I have been (some may say, relentlessly) working on + filling in the missing piece, namely porting GNU Mach (with important help & + contributions by Luca D.). I am happy to report that we now have an + experimental port of GNU Mach that builds and works on AArch64! While that may + sound impressive, note that various things about it are in an extremely basic, + proof-of-concept state rather than being seriously production-ready; and also + that Mach is a small kernel (indeed, a microkernel), and it was designed from + the start (back in the 80s) to be portable, so most of the "buisness logic" + functionality (virtual memory, IPC, tasks/threads/scheduler) is explicitly + arch-independent. + + Despite the scary "WIP proof-of-concept" status, there is enough + functionality in Mach to run userland code, handle exceptions and + syscalls, interact with the MMU to implement all the expected virtual + memory semantics, schedule/switch tasks and threads, and so on. + Moreover, all of GNU Mach's userspace self-tests pass! + + This meant there was enough things in place for me to try running + glibc on it, and the amazing thing is my simple test executable, the + same one I previously tested on Linux with GDB, just worked on real + Mach without me having to make any additional changes to the glibc + side, or even recompile it. + + But I did not stop there, and I got several of the core Hurd servers + working! Namely, these are ext2fs, exec, startup, auth, and proc + servers. All of them but ext2fs are dynamically linked; ld + aarch64.so.1 sucessfully locates and maps the programs themselves + and their required dependencies, and Mach pages in code and data + pages from ext2fs as they are accessed, transparently to the + program, just as one would expect it to. + + +Be sure to read more from his announcement +[email](https://lists.gnu.org/archive/html/bug-hurd/2024-03/msg00114.html). + +Sergey also announced [a new Alpine distro based on Hurd](https://lists.gnu.org/archive/html/bug-hurd/2024-01/msg00180.html) (it +currently does not have a name). His goal is to add another Hurd distribution, +which will force the Hurd to work with different software and hopefully fix more +bugs. Alpine Linux also usually runs the latest software, so this new Hurd +distribution will be for those who like living on the bleeding edge. He writes: + + + I have ported many Alpine packages to build with (i386, for now) GNU + Mach, the Hurd, and glibc, replacing Linux and musl. If you want a + specific number: as of yesterday, I have 299 installable packages; the + number of source packages is of course several times less than that. + Still, this includes things like curl, ncurses, nano, native binutils + & gcc & mig, libffi, openrc, openssl, util-linux, busybox, apk-tools, + ... and of course gnumach, hurd (with dependencies like libdaemon, + parted, ...), and glibc. Importantly, all this cleanly bootstraps + using the scripts/bootstrap.sh script that they provide; this is too + somewhat like Flávio's scripts, but it uses the real full Alpine + package definitions for e.g. GCC (patched by me for glibc / Hurd + support). + + Above the kernel and libc, things remain much as they were in upstream + Alpine: the system boots (will boot — I haven't tried it yet) with + busybox init & OpenRC, and uses busybox as its basic userland. GNU + software such as Bash is installable, too. + + +This new Hurd distribution currently does not have a mailing list, irc room, or +website. If you are interesting +in helping Sergei to develop it further, then please email bug-hurd@gnu.org. + +Luca Dariz added [userspace +tests](https://lists.gnu.org/archive/html/bug-hurd/2024-01/msg00125.html), which +work with qemu. We currently test the Hurd in qemu on a GNU/Linux host. He also described how [he currently uses the 64-bit +Hurd](https://lists.gnu.org/archive/html/bug-hurd/2024-01/msg00047.html). +Perhaps you should follow that advice if you want to try running a 64-bit Hurd +on qemu. + +Manolo de Medici made a WIP patch series that gets [qemu +to run on the +Hurd](https://lists.gnu.org/archive/html/bug-hurd/2024-01/msg00153.html). + +I organized a belated GNU/Hurd Christmas party. We had 6 or 7 +attenders, which was pretty awesome! I was not able to record the event, so +perhaps we should try for another meet perhaps at the end of Q2. If you would +like to help me plan/organize/join such a party, then please email +bug-hurd@gnu.org. + +If you want to test if your favorite packages work on the Hurd and +contribute towards making the full GNU system usable for a wider range +of people, please [[check the contributing page|contributing]]. + +--- + +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/index/discussion.mdwn b/njaelani/discussion.mdwn index 404e47ab..404e47ab 100644 --- a/index/discussion.mdwn +++ b/njaelani/discussion.mdwn diff --git a/open_issues/64-bit_port.mdwn b/open_issues/64-bit_port.mdwn index 9382a0d5..aa49e64b 100644 --- a/open_issues/64-bit_port.mdwn +++ b/open_issues/64-bit_port.mdwn @@ -13,79 +13,163 @@ License|/fdl]]."]]"""]] [[!inline pages="title(Is there a 64-bit version?)" feeds="no" raw="yes"]] -There is a `master-x86_64` [[GNU Mach -branch|http://git.savannah.gnu.org/cgit/hurd/gnumach.git/log/?h=master-x86_64]]. -As of 2012-11-20, it only supports the [[microkernel/mach/gnumach/ports/Xen]] platform for now. - **What is left for initial support (32-on-64) is** - * add 64bit boot support from grub's multiboot - * implement 32/64 RPC compatibility for RPCs served by kernel. - -See [[http://lists.gnu.org/archive/html/bug-hurd/2012-04/msg00000.html]] + * Fixing bugs :) **For pure 64bit support, we need to** - * add 64bit definitions in binutils - * add 64bit definitions in gcc - * implement 64bit variants of code in glibc/sysdeps/mach/i386 and glibc/sysdeps/mach/hurd/i386 - * implement 64bit variants of code in libpthread/sysdeps/i386, libpthread/sysdeps/mach/i386, libpthread/sysdeps/mach/hurd/i386 - * fetch from Linux 64bit variant of code in ./pfinet/linux-src/arch/i386 and ./pfinet/linux-src/include/asm-i386 - * define the mig ABI - * bootstrap a distrib, e.g. Debian hurd-amd64 (see [[https://jenkins.debian.net/view/rebootstrap/job/rebootstrap_hurd-amd64_gcc8/]] ) - -# IRC, freenode, #hurd, 2011-10-16 - - <youpi> it'd be really good to have a 64bit kernel, no need to care about - addressing space :) - <braunr> yes a 64 bits kernel would be nice - <braunr> i guess it wouldn't be too hard to have a special mach kernel for - 64 bits processors, but 32 bits userland only - <youpi> well, it means tinkering with mig - -[[mig_portable_rpc_declarations]]. - - -# IRC, freenode, #hurd, 2012-10-03 - - <braunr> youpi: just so you know in case you try the master-x86_64 with - grub - <braunr> youpi: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689509 - <youpi> ok, thx - <braunr> the squeeze version is fine but i had to patch the wheezy/sid one - <youpi> I actually hadn't hoped to boot into 64bit directly from grub - <braunr> youpi: there is code in viengoos that could be reused - <braunr> i've been thinking about it for a time now - <youpi> ok - <braunr> the two easiest ways are 1/ the viengoos one (a -m32 object file - converted with objcopy as an embedded loader) - <braunr> and 2/ establishing an identity mapping using 4x1 GB large pages - and switching to long mode, then jumping to c code to complete the - initialization - <braunr> i think i'll go the second way with x15, so you'll have the two :) - - -## IRC, freenode, #hurd, 2013-07-02 - -In context of [[mondriaan_memory_protection]]. - - <xscript> BTW, it's not like I have an infinite amount of time for this, - but having 64-bit support would be valuable for me, so I might contribute - that back if it's not a too monumental task - <xscript> I saw some discussions about 32bit apps on top of 64bit mach, but - I'd like a full 64bit system - <xscript> any clues? - <xscript> I suppose the compiler support is all there already - <xscript> is MIG (and mach) the only piece missing? - <braunr> the problem is the interfaces themselves - <braunr> type widths - <braunr> as passed between userspace and kernel - - -## IRC, OFTC, #debian-hurd, 2013-10-05 - - <dharc> and what about 64 bit support, almost done? - <youpi> kernel part is done - <youpi> MIG 32/64 trnaslation missing - -[[mig_portable_rpc_declarations]]. + * bootstrap a distrib + * port gdb + * Fix bugs :) + * Notably it seems to be requiring at least 2G memory to boot. + +**Installing a 64bit chroot** + +You can use the pre-built image from https://people.debian.org/~sthibault/hurd-i386/initrd-amd64.img.gz and boot that. + +Make sure to have `debootstrap >= 1.0.128+nmu2+hurd.1` + + debootstrap --foreign --verbose --arch hurd-amd64 --include=debian-keyring,wget,curl,inetutils-ping,openssh-server,openssh-client,nano,less --keyring=/usr/share/keyrings/debian-keyring.gpg sid chroot-hurd-amd64 https://people.debian.org/~sthibault/tmp/hurd-amd64 + mkdir chroot-hurd-amd64/etc/apt/trusted.gpg.d + ln -s /usr/share/keyrings/debian-keyring.gpg chroot-hurd-amd64/etc/apt/trusted.gpg.d/ + +Then boot it, it will drop you into a shell. You'll probably want to use a nicer shell: + + bash + +You need to make / writable: + + fsysopts / --writable + +and then run the second stage of the deboostrap (and clear debs): + + /debootstrap/debootstrap --second-stage + apt clean + +set a root password: + + passwd + +Avoid core dumpings for now (not supported and hangs): + + rm -f /servers/crash + ln -s crash-kill /servers/crash + +Disable the Hurd console, buggy for now: + + export TERM=mach + nano /etc/default/hurd + # set ENABLE to 'false' + +And reboot: + + reboot-hurd + +After reboot, you'll probably want to setup network: + + vi /etc/network/interfaces + # put there this: + auto /dev/eth0 + iface /dev/eth0 inet static + address 10.0.2.15/16 + gateway 10.0.2.2 + +**Creating a 64bit disk image** + +You can use the pre-built image from https://people.debian.org/~sthibault/hurd-i386/disk-amd64.img.gz and boot that. + +To make a bootable system we really better make the disk image partitioned, and mount the partition: + + dd < /dev/zero > disk.img bs=1M count=1 seek=1000 + fdisk disk.img + # create a new primary partition spanning the whole disk: n p and just accept the defaults, and finish with w + settrans -ca disk /hurd/storeio -T typed file:disk.img + settrans -ca disk1 /hurd/storeio -T typed part:1:file:disk.img + mke2fs disk1 + settrans -ca chroot-hurd-amd64 /hurd/ext2fs disk1 + +(here we assume that fdisk puts the partition at sector 2048, that's indeed the +current default behavior) + +Then run the same debootstrap command as above. + +You can then make the disk bootable: + + mkdir chroot-hurd-amd64/boot/grub + tee chroot-hurd-amd64/boot/grub/grub.cfg << 'EOF' + set default="0" + set timeout=5 + menuentry "Debian GNU/Hurd amd64" { + insmod ext2 + set root=(hd0,1) + multiboot /boot/gnumach-1.8-486.gz root=part:1:device:wd0 + module /hurd/pci-arbiter.static pci-arbiter \ + --host-priv-port='${host-port}' --device-master-port='${device-port}' \ + --next-task='${disk-task}' \ + '$(pci-task=task-create)' '$(task-resume)' + module /hurd/rumpdisk.static rumpdisk \ + --next-task='${fs-task}' \ + '$(disk-task=task-create)' + module /hurd/ext2fs.static ext2fs --readonly \ + --multiboot-command-line='${kernel-command-line}' \ + --exec-server-task='${exec-task}' -T typed '${root}' \ + '$(fs-task=task-create)' + module /lib/ld-x86-64.so.1 exec /hurd/exec '$(exec-task=task-create)' + } + EOF + grub-install --modules="part_msdos ext2" --boot-directory chroot-hurd-amd64/boot disk + settrans -ga chroot-hurd-amd64 + settrans -ga disk + settrans -ga disk1 + +Then boot it, and proceed like for the chroot case. + +**Creating a pbuilder chroot** + +Here is a sample `/etc/pbuilderrc`: + + MIRRORSITE=https://people.debian.org/~sthibault/tmp/hurd-amd64 + AUTOCLEANAPTCACHE=yes + EXTRAPACKAGES="eatmydata" + if [ -z "$LD_PRELOAD" ]; then + LD_PRELOAD=libeatmydata.so + else + LD_PRELOAD="$LD_PRELOAD":libeatmydata.so + fi + export LD_PRELOAD + DEBOOTSTRAPOPTS=( + '--variant=buildd' + '--force-check-gpg' + '--keyring=/usr/share/keyrings/debian-keyring.gpg' + ) + APTKEYRINGS=(/usr/share/keyrings/debian-keyring.gpg) + +And this is needed until we get the `aptitude` package built: + + sudo ln -sf pbuilder-satisfydepends-apt /usr/lib/pbuilder/pbuilder-satisfydepends + +And then you can run `sudo pbuilder create` , `sudo pbuilder login` , `pdebuild` + +**Installing from the debian-ports archive** + +For now it's quite empty (not even gcc), but it can be debootstrapped. That will be used to build packages on the buildds. + + debootstrap --foreign --verbose --arch hurd-amd64 --extra-suites=unreleased --include=debian-ports-archive-keyring --keyring=/usr/share/keyrings/debian-ports-archive-keyring.gpg sid chroot-hurd-amd64 https://deb.debian.org/debian-ports/ + +**Installing proper & more packages** + +The `people.debian.org` repository is only for bootstraping the distribution. Proper packages are getting uploaded on the usual mirror: + +``` +deb http://deb.debian.org/debian-ports sid main +deb http://deb.debian.org/debian-ports unreleased main +``` + +**Installing a 64bit system** + +In principle crosshurd should be working, one however should add this source to get more packages for now: + + deb http://people.debian.org/~sthibault/tmp/hurd-amd64 unstable + +into /etc/crosshurd/sources.list/gnu diff --git a/open_issues/Upstart.mdwn b/open_issues/Upstart.mdwn deleted file mode 100644 index 1972e197..00000000 --- a/open_issues/Upstart.mdwn +++ /dev/null @@ -1,69 +0,0 @@ -[[!meta copyright="Copyright © 2013, 2014 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]]."]]"""]] - - -[[!template id=highlight text="""/!\ Obsolete /!\ - ---- - -[[systemd|Systemd]] has almost universally replaced upstart."""]] - -Upstart is an event based init system that is GPL licensed, however upstream -contributions are under a CLA that permits proprietary relicensing. - -Most major GNU/Linux distributions are choosing systemd as their init system -instead of upstart. The original upstart developers seem to have stopped -developing it. - -The following are the words of Colin Watson on the debian-ctte@lists.debian.org -mailing list and list the requirements of a potential HURD port: - ->I haven't looked at this in much detail, and I suspect Dimitri hasn't -yet although IIRC he did express some interest in doing so. But I -haven't seen anyone else try to outline the scope of a port, so let me -try to do so for the sake of general understanding. As far as I know, -the hardest parts would be inotify, ptrace, and prctl -(PR_SET_CHILD_SUBREAPER). - ->inotify is used to notice changes to configuration files. This is -certainly helpful for users, but it isn't critical as "initctl -reload-configuration" works without it. We could probably do without -this with the aid of a dpkg trigger. - ->ptrace is used for "expect fork" and "expect daemon"; as I indicated in -another post, I think it would be preferable to avoid these in Debian -and quite possibly to compile them out. (This would mean we wouldn't be -able to translate Ubuntu jobs quite as directly, and a number of -important jobs would definitely need to be changed, but the conversion -isn't usually particularly difficult.) - ->prctl (PR_SET_CHILD_SUBREAPER) is used to make SIGCHLD notification work -properly when Upstart is supervising a user session. This isn't a -required feature and could easily be compiled out until suitable kernel -support is available (this actually seems like the sort of thing that -could be done in the Hurd without too much difficulty, but I haven't -looked into it). If absent, it might well impede the ability to do an -advanced desktop port, but it wouldn't get in the way of porting the -bulk of services. - ->There might also be odds and ends around the details of wait status -handling. - -inotify seems to be a feature that is often used in GNU/Linux programs, and -implementing the feature in the HURD seems like a better and more rewarding -option than porting the code in Upstart. - -Although many daemons double fork, that behavior seems to be dying out, and -one can comfortably ignore the "expect fork/daemon" functionality of Upstart -(and compile it out). - -[[!tag open_issue_porting]] - -See also the discussion about upstart on the [[systemd]] page. diff --git a/open_issues/adduser.mdwn b/open_issues/adduser.mdwn deleted file mode 100644 index 713a1dd3..00000000 --- a/open_issues/adduser.mdwn +++ /dev/null @@ -1,37 +0,0 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] - -[[!meta title="adduser: posix_spawn() error=1073741826"]] - -[[!tag open_issue_porting]] - -`adduser` does work as expected, the following warnings are spurious, they just -appear when one doesn't have the nscd package. They do not appear on Linux boxes -because there posix_spawn doesn't report ENOENT for exec(). POSIX indeed says -that `if the error occurs after the calling process successfully returns, the -child process shall exit with exit status 127'. The Hurd however reports all -errors, thus the warning. - - $ sudo adduser foo - Adding user `foo' ... - Adding new group `foo' (1002) ... - posix_spawn() error=1073741826 - posix_spawn() error=1073741826 - posix_spawn() error=1073741826 - Adding new user `foo' (1002) with group `foo' ... - posix_spawn() error=1073741826 - posix_spawn() error=1073741826 - posix_spawn() error=1073741826 - posix_spawn() error=1073741826 - Creating home directory `/home/foo' ... - Copying files from `/etc/skel' ... - [...] - -Reported at [[!debbug 623199]]. diff --git a/open_issues/alarm_setitimer.mdwn b/open_issues/alarm_setitimer.mdwn index a1c8a7d3..5f121ca6 100644 --- a/open_issues/alarm_setitimer.mdwn +++ b/open_issues/alarm_setitimer.mdwn @@ -58,7 +58,7 @@ This issue was recently fixed (around January 2013). (e19a2fad70b187e5efe79768f86a1f05cb5e0390, Tue Feb 21 02:41:18 2012) <braunr> yes, fixed :) <braunr> patch committed at - http://git.savannah.gnu.org/cgit/hurd/glibc.git/log/?h=rbraun/setitimer_fix + https://git.savannah.gnu.org/cgit/hurd/glibc.git/log/?h=rbraun/setitimer_fix <youpi> and pushed to the debian package diff --git a/open_issues/anatomy_of_a_hurd_system.mdwn b/open_issues/anatomy_of_a_hurd_system.mdwn index 82f2333c..9232186f 100644 --- a/open_issues/anatomy_of_a_hurd_system.mdwn +++ b/open_issues/anatomy_of_a_hurd_system.mdwn @@ -1050,12 +1050,12 @@ Actually, the Hurd has never used an M:N model. Both libthreads (cthreads) and l <teythoon> as I said, the wire format is specified, the semantics only in written form in the source <teythoon> this is an example of the ipc specification for the proc server - http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/hurd/process.defs + https://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/hurd/process.defs <crocket> teythoon, how file server interacts with file clients should be defined as a formal protocol, too. <teythoon> do you consider the ipc description a kind of formal protocol ? <crocket> - http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/hurd/process.defs can + https://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/hurd/process.defs can be considered as a formal protocol. <crocket> However, the file server protocol should be defined on top of IPC protocol. diff --git a/open_issues/arm_port.mdwn b/open_issues/arm_port.mdwn index 26e0b770..8a2bc27f 100644 --- a/open_issues/arm_port.mdwn +++ b/open_issues/arm_port.mdwn @@ -9,56 +9,152 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] -Several people have expressed interested in a port of GNU/Hurd for the ARM -architecture. +Several people have expressed interested in a port of GNU/Hurd for the +ARM architecture. Luckily a userspace port of the Hurd servers and +glibc is underway. As early as January 1, 2024 an AArch64 port is +making some progress. Sergey did some hacking on glibc, binutils, +GCC, and added some headers to GNU Mach. He was able to build the +core Hurd servers: ext2fs, proc, exec, and auth. +One would think that he would need to port GNU Mach to run the +binaries, but Sergey ran a statically linked hello world executable on +GNU/Linux, under GDB, being careful to skip over and emulate syscalls +and RPCs. The glibc port has the TLS setup, hwcaps / cpu-features, +and ifuncs. -# IRC, freenode, #hurd, 2012-07-28 +Now to some of the more technical things: - <mcsim> Has anyone heard about porting hurd and gnu/mach to arm - architecture? - <braunr> mcsim: i think so - <braunr> mcsim: why are you asking ? - <mcsim> I found an article where author stated that he has ported hurd to - arm, but I have never met this information before. - <mcsim> He wrote ethernet driver and managed to use ping command - <mcsim> author's name is Sartakov Vasily - <braunr> well that's possible, a long time ago - <braunr> and it was probably not complete enough to be merged upstream - <braunr> like many other attempts at many other things - <mcsim> Not so long. Article is dated by June 2011. - <braunr> do you have a link ? - <mcsim> Yes, but it is in Russian. - <braunr> oh - <braunr> well i don't remember him sharing that with us - <antrik> mcsim: he did some work on porting Mach, but AIUI never got it - nearly finished - <antrik> nowadays he does L4 stuff - <antrik> was also at FOSDEM +- The TLS implementation is basically complete and working. We're +using `tpidr_el0` for the thread pointer (as can be seen in the listing +above), like GNU/Linux and unlike Windows (which uses x18, apparently) +and macOS (which uses `tpidrro_el0`). We're using "Variant I" layout, as +described in "ELF Handling for Thread-Local Storage", again same as +GNU/Linux, and unlike what we do on both x86 targets. This actually +ends up being simpler than what we had for x86! The other cool thing +is that we can do `msr tpidr_el0, x0` from userspace without any +gnumach involvement, so that part of the implementation is quite a bit +simpler too. +- Conversely, while on x86 it is possible to perform "cpuid" and +identify CPU features entirely in user space, on AArch64 this requires +access to some EL1-only registers. On Linux and the BSDs, the kernel +exposes info about the CPU features via `AT_HWCAP` (and more recently, +`AT_HWCAP2`) auxval entries. Moreover, Linux allows userland to read +some otherwise EL1-only registers (notably for us, `midr_el1`) by +catching the trap that results from the EL0 code trying to do that, +and emulating its effect. Also, Linux exposes `midr_el1` and +`revidr_el1` values through procfs. -## IRC, freenode, #hurd, 2012-10-09 +- The Hurd does not use `auxval`, nor is gnumach involved in `execve` anyway. +So I thought the natural way to expose this info would be with an RPC, +and so in `mach_aarch64.defs` I have an `aarch64_get_hwcaps` routine that +returns the two hwcaps values (using the same bits as `AT_HWCAP{,2}`) and +the values of `midr_el1`/`revidr_el1`. This is hooked to `init_cpu_features` +in glibc, and used to initialize `GLRO(dl_hwcap)` / `GLRO(dl_hwcap2)` and +eventually to pick the appropriate ifunc implementations. - <mcsim> bootinfdsds: There was an unfinished port to arm, if you're - interested. - <tschwinge> mcsim: Has that ever been published? - <mcsim> tschwinge: I don't think so. But I have an email of that person and - I think that this could be discussed with him. +- The page size (or rather, paging granularity) is notoriously not +necessarily 4096 on ARM, and the best practice is for userland not to +assume any specific page size and always query it dynamically. GNU +Mach will (probably) have to be built support for some specific page +size, but I've cleaned up a few places in glibc where things were +relying on a statically defined page size. +- There are a number of hardware hardening features available on AArch64 +(PAC, BTI, MTE — why do people keep adding more and more workarounds, +including hardware ones, instead of rewriting software in a properly +memory-safe language...). Those are not really supported right now; all +of them would require some support form gnumach side; we'll probably +need new protection flags (`VM_PROT_BTI`, `VM_PROT_MTE`), for one thing. -## IRC, freenode, #hurd, 2012-10-10 +We would need to come up with a design for how we want these to work +Hurd-wide. For example I imagine it's the userland that will be +generating PAC keys (and settings them for a newly exec'ed task), +since gnumach does not contain the functionality to generate random +values (nor should it); but this leaves an open question of what +should happen to the early bootstrap tasks and whether they can start +using PAC after initial startup. - <tschwinge> mcsim: If you have a contact to the ARM porter, could you - please ask him to post what he has? - <antrik> tschwinge: we all have the "contact" -- let me remind you that he - posted his questions to the list... +- Unlike on x86, I believe it is not possible to fully restore +execution context (the values of all registers, including `pc` and +`cpsr`) purely in userland; one of the reasons for that being that we +can apparently no longer do a load from memory straight into `pc`, +like it was possible in previous ARM revisions. So the way `sigreturn +()` works on Linux is of course they have it as a syscall that takes a +`struct sigcontext`, and writes it over the saved thread state, which +is similiar to `thread_set_state ()` in Mach-speak. The difference +being that `thread_set_state ()` explicitly disallows you to set the +calling thread's state, which makes it impossible to use for +implementing `sigreturn ()`. So I'm thinking we should lift that +restriction; there's no reason why `thread_set_state ()` cannot be +made to work on the calling thread; it only requires some careful +coding to make sure the return register (`%eax`/`%rax`/`x0`) is *not* +rewritten with `mach_msg_trap`'s return code, unlike normally. +But other than that, I do have an AArch64 versions of `trampoline.c` +and `intr-msg.h` (complete with `SYSCALL_EXAMINE` & +`MSG_EXAMINE`). Whether they work, we'll only learn once we have +enough of the Hurd running to have the proc server. -## IRC, freenode, #hurd, 2012-10-17 +MIG seems to just work (thanks to all the Flávio's work!). We are +using the `x86_64` ABI, and I have not seen any issues so far — +neither compiler errors / failed static assertions (about struct sizes +and such), nor hardware errors from misaligned accesses. - <mcsim> tschwinge: Hello. The person who I wrote regarding arm port of - gnumach still hasn't answered. And I don't think that he is going to - answer. +To bootstrap gnumach someone must fix the console, set up the virtual +memory, thread states, context switches, irqs and userspace entry +points, etc. + +Also, there is a bunch of design work to do. + +Will/can AArch64 use the same mechanism for letting userland handle +interrupts? Do we have all the mechanisms required for userland to +poke at specific addresses in memory (to replace I/O ports)? — I +believe we do, but I haven't looked closely. + +AFAIK there are no I/O ports in ARM, the usual way to configure things +is with memory-mapped registers, so this might be easy. About IRQs, +probably it needs to be arch-specific anyway. + +What should the API for manipulating PAC keys look like? Perhaps it +should be another flavor of thread state, but then it is really +supposed to be per-task, not per-thread. Alternatively, we could add a +few aarch64-specific RPCs in `mach_arrch64.defs` to read and write the +PAC keys. But also AFAICS Mach currently has no notion of per-task +arch-specific data (unlike for threads, and other than the VM map), so +it'd be interesting to add one. Could it be useful for something +else? + +What are the debugging facilities available on ARM / AArch64? Should +we expose them as more flavors of thread state, or something else? +What would GDB need? + +Should gnumach accept tagged addresses (like `PR_SET_TAGGED_ADDR_CTRL` +on Linux)? + +Can we make Linux code (in-Mach drivers, pfinet, netdde, ...) work on +AArch64? + +One can trivially port pfinet to AArch64. Eventually, we should fix +any remaining issues with lwip. That way we can stop spending time +maintaining pfinet, which is Linux's old abandoned networking stack. + +Developers will have a difficult time porting the in-Mach drivers +(arm64 was probably not even a thing at the time). We can perhaps +port Netdde, but we should instead get our userspace drivers from a +rumpkernel. + +Starting the kernel itself should be easy, thanks to GRUB, but it +shouldn't be too hard to add support for U-Boot either if needed. + +I think more issues might come out setting up the various pieces of +the system. For example, some chips have heterogeneous cores, +(e.g. mine has two A72 cores and four A53 cores) so SMP will be more +complicated. + +Also, about the serial console, it might be useful at some point to +use a driver from userspace, if we can reuse some drivers from netbsd +or linux, to avoid embedding all of them in gnumach. # IRC, freenode, #hurd, 2012-11-15 diff --git a/open_issues/automatic_backtraces_when_assertions_hit.mdwn b/open_issues/automatic_backtraces_when_assertions_hit.mdwn deleted file mode 100644 index df7294e9..00000000 --- a/open_issues/automatic_backtraces_when_assertions_hit.mdwn +++ /dev/null @@ -1,79 +0,0 @@ -[[!meta copyright="Copyright © 2010, 2012 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled [[GNU Free Documentation -License|/fdl]]."]]"""]] - -[[!tag open_issue_glibc]] - - -# IRC, unknown channel, unknown date - - <azeem> tschwinge: ext2fs.static: thread-cancel.c:55: hurd_thread_cancel: Assertion `! __spin_lock_locked (&ss->critical_section_lock)' failed. - <youpi> it'd be great if we could have backtraces in such case - <youpi> at least just the function names - <youpi> and in this case (static), just addresses would be enough - - -# IRC, freenode, #hurd, 2012-07-19 - -In context of the [[ext2fs_libports_reference_counting_assertion]]. - - <braunr> pinotree: tschwinge: do you know if our packages are built with - -rdynamic ? - <pinotree> braunr: debian's cflags don't include it, so unless the upstream - build systems do, -rdynamic is not added - <braunr> i doubt glibc' backtrace() is able to find debugging symbol files - on its own - <pinotree> what do you mean? - <braunr> the port reference bug youpi noticed is rare - <pinotree> even on linux, a program compiled with normal optimizations (eg - -O2 -g) can give just pointer values in backtrace()'s output - <braunr> core dumps are unreliable at best - -[[crash_server]]. - - <braunr> uh, no, backtrace does give names - <braunr> but not with -fomit-frame-pointer - <braunr> unless the binary is built with -rdynamic - <braunr> at least it used to - <pinotree> not really, when being optimized some steps can be optimized - away (eg inlines) - <braunr> that's ok - <braunr> anyway, the point is i'd like a way that can give us as much - information as possible when the problem happens - <braunr> the stack trace being the most useful imo - <pinotree> do you face issues currently with backtrace()? - <braunr> not tried yet - <braunr> i guess i could make the application trap in the kernel, and fault - there, so we can attach gdb while still in the pager address space :> - <pinotree> that would imply the need for interactivity when the fault - happens, wouldn't it? - <braunr> no - <braunr> it would remain this way until someone comes, hours, days later - <braunr> pinotree: well ok, it would require interactivity, but not *when* - it happens ;p - <braunr> pinotree: right, it needs -rdynamic - - -## IRC, freenode, #hurd, 2012-07-21 - - <braunr> tschwinge: my current "approach" is to introduce an infinite loop - <braunr> it makes the faulting task mapped in often enough to use gdb - through qemu - <braunr> ... :) - <tschwinge> My understanding is that glibc already does have some mechanism - for that: I have seen it print backtraces whendetecting malloc - inconsistencies (double free and the lite). - <braunr> yes, i thought it used the backtrace functions internally though - <braunr> that is, execinfo - <braunr> but this does require -rdynamic - - -# GCC's libbacktrace - -Introduced in GCC commit ecd3459e7bb829202601e3274411135a15c64dde. diff --git a/open_issues/bash.mdwn b/open_issues/bash.mdwn index f6b14a08..a8a71810 100644 --- a/open_issues/bash.mdwn +++ b/open_issues/bash.mdwn @@ -46,14 +46,3 @@ After having noticed that this error doesn't occur if starting *bash* with bash: start_pipeline: pgrp pipe: (ipc/mig) wrong reply message ID So, there's something different with stdout in / after the SIGINT handler. - - -# IRC, freenode, #hurd, 2013-01-13 - -Perhaps completely unrelated to the issue above, perhaps not. - - <tschwinge> bash: xmalloc: ../../../bash/lib/sh/strtrans.c:60: cannot - allocate 261 bytes (323584 bytes allocated) - <tschwinge> 1.5 GiB RAM were free. - <tschwinge> This happened when I did a rever history search (C-r [...]), - and then pressed C-c. diff --git a/open_issues/bcachefs.mdwn b/open_issues/bcachefs.mdwn new file mode 100644 index 00000000..aa39bce0 --- /dev/null +++ b/open_issues/bcachefs.mdwn @@ -0,0 +1,326 @@ +[[!meta copyright="Copyright © 2007, 2008, 2010, 2011 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + +The Hurd's primary filesystem is ext2, which works but lacks modern +features. With ext2, Hurd users reguarly deal with filesystem +corruption. Ext2 does not have a journal, so Hurd users occasionally +have to deal with filesystem corruption. `fsck` can fix most of the +issues (with loss of random data), but without a proper journal the +Hurd currently is not a good a OS for long-term data storage. + +Bcachefs is a modern COW (copy-on-write) open source filesystem for +Linux, which intends to replace Btrfs and ZFS while having the +performance of ext4 or XFS. It is almost 100,000 lines of code. +Btrfs is 150,000 lines of code. Bcachefs is structured as a +filesystem built on top of a database. There is a clean small +database transaction layer. That core database library is maybe +25,000 lines of code. + +Some Hurd developers recently [[talked with +Bcachefs|https://youtube.com/watch?v=bcWsrYvc5Fg]] author Kent +Overstreat about porting bcachefs to the Hurd. There are currently no +concrete plans to do so due to lack of developer man power. + +90% of the Bcachefs filesystem code builds and runs in userspace. It +uses a shim layer that makes maps kernel locking primatives to +pthreads, the kernel io API is mapped to AIO, etc. Bcachefs does +intend to eventually rewrite most or all of its current codebase into +rust. + +Kent is ok with us merging a shim layer for libstore that maps to the +Unix filesystem API. That would be a header file that goes into the +bcachefs code. + +There is a somewhat working FUSE port of bcachefs, but Kent is not +certain that is a good way to run bcachefs in userspace. Kent wants +to use the FUSE port to help in debbugging. Suppose bcachefs starts +acting up, then you could switch to running it in userspace and attach +GDB to the running process. This is currently not possible. + +We could port bcachefs to the Hurd's native filesystem API: libdiskfs. + +One interesting aspect of the conversation was Kent's goal of re-using +kernel code in userspace. The Linux kernel hashtable code is high +performance, resizeable, lockless, and builds and runs in userspace. +As long as you have liburcu, then you can use the kernel hashtable in +userspace on the Hurd. This might be useful to use on the Hurd. + +Bcachefs is liscensed as GPLv2, and many of Kent's previous employers +own the patents, including Google. Kent is ok with potentially making +the license GPLv2+, as long as there was not a promise to keep +bcachefs GPLv2 only. + +# IRC logs + +https://logs.guix.gnu.org/hurd/2023-09-26.log + + <solid_black> maybe I'm wrong though, do you know much about fuse? or file systems? + <damo22> no i dont know much about filesystems + <damo22> what is bcachefs? + <solid_black> see? :D + <azert> I agree that someone intimate in the Mach pager api, libdiskfs and fuse would be great at that meeting + <solid_black> I do kind of understand Mach VM / paging, I must say + <solid_black> from the looks of it, I even understand it best among those who have looked at it recently + <solid_black> and I mostly understand libdiskfs + <damo22> so go to the meeting + <damo22> what is fuse? do we even need it for hurd? + <damo22> file systems in userspace + <solid_black> FUSE is "filesystem in user space", it's both the name for the concept, and the name of Linux's specific mechanism, of offloading fs to userland + <damo22> yeah, i think it may be unneeded for filesystem on hurd + <solid_black> it's basically a giant hack that pretends to be a fileystem implementation to the rest of the kernel, and then sends requests and receives responses from a userland program that _actually_ implements the fs + <solid_black> on the Hurd, *of course* filesystems are implemented in userland, that's the only and tnhe natural way everything works + <solid_black> but that's where the similarities end + <solid_black> you cannot just take a linux fuse fs, using libfuse, and run it on the Hurd + <solid_black> there has been a project make a library that would have the same API as libfuse, but act as a Hurd translator, specifically to facilitate porting linux filesystems + <damo22> i imagine fuse has an api + <solid_black> last I heard, it was never completed, but who knows + <solid_black> it has a kerne <->userland protocol and a userspace library (libfuse) for implementing that protocol, yes + <damo22> solid_black: you seem to know more about fuse than you admitted + <solid_black> https://www.gnu.org/software/hurd/hurd/libfuse.html + <solid_black> I know the basics, around as much as I have just told you + <azert> I think that gnucode idea was that this would be the easiest to port bcachefs to the Hurd, but I doubt it would be the best + <solid_black> I have also hacked on a C++ fuse fs (darling-dmg), though I don't think I interacted with the fuse parts of it much + <azert> Or even the easier + <solid_black> yeah, I don't think it'd be the best or the easiest one either + <damo22> if someone implemented libfuse api and made it as a hurd translator, surely it would work natively? + <damo22> <braunr> zacts: the main problem seems to be the interactions between the fuse file system and virtual memory (including caching) + <braunr> something the hurd doesn't excel at + <braunr> it *may* be possible to find existing userspace implementations that don't use the system cache (e.g. implement their own) + <azert> Yes, that’s a possibility that needs to be kept open for discussion + <nikolar> Sounds interesting + <solid_black> youpi: ping + <youpi> pong + <solid_black> hello! + <solid_black> any thoughts on the above discussion? are you going to participate in the call that's being set up? + <youpi> I don't have time for it + <youpi> (AFAIK the fuse hurd implementation does work to some extent) + <solid_black> I should at least try out Hurd's fuse before the call, good idea + <solid_black> maybe read up on the Linux's fuse + <solid_black> thoughts on using fuse vs libdiskfs for bcachefs? + <youpi> using fuse would probably be less work + <youpi> and it'd probably mean fixing things in libfuse, which can benefit many other FS anyway + <solid_black> is it true that the "low level" API of libfuse is unimplemented and unimplementable? + <youpi> I don't know what that "low level" API is + <solid_black> this IIUC https://github.com/libfuse/libfuse/blob/master/include/fuse_lowlevel.h + <solid_black> > libfuse offers two APIs: a "high-level", synchronous API, and a "low-level" asynchronous API. In both cases, incoming requests from the kernel are passed to the main program using callbacks. When using the high-level API, the callbacks may work with file names and paths instead of inodes, and processing of a request finishes when the callback function returns. When using the low-level API, the callbacks must work with inodes and responses must be se + <solid_black> nt explicitly using a separate set of API functions. + <youpi> where did you read that it'd be unimplementable ? + <solid_black> https://git.savannah.gnu.org/cgit/hurd/incubator.git/tree/README?h=libfuse/master + <solid_black> > This is simply because it is to specific to the Linux kernel and (besides that) it is not farly used now. + <youpi> In case the latter should change in the future, we might want to re-think about that issue though. + <solid_black> so, sounds like it's perhaps implementable in theory, but that'd require additional work and design + <youpi> see the sentence below... + <solid_black> the low-level API is what bcachefs uses + <youpi> well, additional work and design, of course + <solid_black> seems to, at least, from a quick glance + <youpi> any async API needs some + <youpi> but I don't see why it would not be possible + <youpi> mig precisely supports asynchronous stubs + <solid_black> bcachefs-tools/cmd_fusermount.c is just 1274 lines, which inspires some hope + <solid_black> asynchrony is not the problem, I imagine (but I haven't looked), but being too tied to Linux might be + <youpi> it's not really tied, as in it doesn't seem to use linux-specific functions + <youpi> but it uses linux-like notions, which indeed need to be translated to the hurdish notions + <youpi> but that's not something really tough + <youpi> just needs to be worked on + +https://logs.guix.gnu.org/hurd/2023-09-27.log#103329 + + <solid_black> libfuse as shipped as Debian doesn't seem very + functional, I can't even build a simple program against it: + 'i386-gnu/libfuse.so: undefined reference to `assert'' + + <solid_black> (assert is of course a macro in glibc) + <solid_black> and it segfaults in fuse_main_real + <solid_black> lowleve fuse ops do seem to map to netfs concept nicely, as far as I can see so far + <solid_black> and (again, so far) I don't see any asynchrony in how bcachefs uses fuse, i.e. they always fuse_reply() inside the method implementation + + <solid_black> but if we had to implement low-level fuse API, this would be an issue + <solid_black> because netfs is syncronous + <solid_black> this is again a place where I don't think netfs is actually that useful + <solid_black> libfuse should be its own standalone tranlator library, a peer to lib{disk,net,triv}fs + <solid_black> yell at me if you disagree + <youpi> or perhaps make it use libdiskfs ? + <youpi> there's significant code in libdiskfs that you'd probably not want to reimplement in libfuse + <solid_black> like what? + <youpi> starting a translator + <youpi> all the posix semantic bits + <solid_black> (this is another thing, I don't believe there is a significant difference that explains libdiskfs and libnetfs being two separate libraries. but it's too late to merge them, and I'm not an fs dev) + + <solid_black> starting a translator is abstracted into libfshelp specifically so it can be easily reused? + <solid_black> is libdiskfs synchronous? + <youpi> I'm just saying things out of my memory + <solid_black> scratch that, diskfs does not work like that at all + <youpi> piece of it is in fshelp yes + <solid_black> it works on pagers, always + <youpi> but significant pieces are in libdiskfs too + <youpi> and you are saying you are not an FS person :) + <youpi> you do know libdiskfs etc. well beyond the average + <youpi> perhaps not the ext2 FS structure, but that's not really important here + <youpi> see e.g. the short-circuits in file-get-trans.c + <solid_black> I may understand how the Hurd's translator libraries work, somewhat better than the avergae person :) + <youpi> and the code around fshelp_fetch_root + <solid_black> but I don't know about how filesystems are actually organized, on-disk (beyond the basics that there any inodes and superblocks and journaled writes and btrees etc) + <youpi> you don't really need to know more about that + <solid_black> nor do I know the million little things about how filesystem code should be written to be robust and performant + <solid_black> yeah so as I was saying, libdiskfs expects files to be mappable (diskfs_get_filemap_pager_struct), and then all I/O is implemented on top of that + <solid_black> e.g. to read, libdiskfs queries that pager from the impl, maps it into memory, and copies data from there to the reply message + <solid_black> I must have mentioned that already, I'd like to rewrite that code path some day to do less copying + <solid_black> I imagine this might speed up I/O heavy workloads + <youpi> ? it doesn't copy into the reply + <youpi> it transfers map + <solid_black> it does, let me find the code + <youpi> in some corner cases yes + <youpi> but not normal case + <youpi> https://darnassus.sceen.net/~hurd-web/hurd/io_path/ + <solid_black> libdiskfs/rdwr-internal.c, it does pager_memcpy, which is a glorified memcpy + fault handling + <solid_black> don't trust that wiki page + <youpi> why not ? + <youpi> not, pager_memcpy is not just a memcpy + <youpi> it's using vm_copy whenever it can + <youpi> i.e. map transfer + <solid_black> well yes, but doesn't the regular memcpy also attempt to do that? + <youpi> it happens to do so indeed + <youpi> but that' doesn't matter: I do mean it's trying *not* copying + <youpi> by going through the mm + <youpi> note: if a wiki page is bogus, propose a fix + <solid_black> I think there was another copy on the path somewhere (in the server, there's yet another in the client of course), but I can't quite remember where + <solid_black> and I wouldn't rely on that vm_copy optimization + <solid_black> it's may be useful when it working, but we have to design for there to not be a need to make a copy in the first place + <solid_black> ah well, pager_read_page does the other copy + <youpi> when things are not aligned etC. you'll have to do a copy anyway + <solid_black> but then again, this is all my idle observations, I'm not an fs person, I haven't done any profiling, and perhaps indeed all these copies are optimized away with vm_copy + <youpi> where in pager_read_page do you see a copy? + <youpi> it should be doing a store_read + <youpi> passing the pointer to the driver + <solid_black> ext2fs/pager.c:file_pager_read_page (at line 220 here, but I haven't pulled in a while) + <solid_black> it does do a store_read, and that returns a buffer, and then it may have to copy that into the buffer it's trying to return + <solid_black> though in the common case hopefully it'll read everything in a single read op + <youpi> it's in the new_buf != *buf + offs case + <youpi> which is not supposed to be the usual case + <solid_black> but now imagine how much overhead this all is + <youpi> what? the ifs? + <solid_black> we're inside io_read, we already have a buffer where we should put the data into + <youpi> I have to go give a course, gotta go + <solid_black> we could just device_read() into there + <youpi> you also want to use a cache + <youpi> otherwise it'll be the disk that'll kill yiour performance + <youpi> so at some point you do have to copy from the cache to the application + <youpi> that's unavoidable + <youpi> or if it's large, you can vm_copy + copy-on-write + <youpi> but basically, the presence of the cache means you can have to do copies + <youpi> and that's far less costly than re-reading from the disk + <solid_black> why can't you return the cache page directly from io_read RPC? + <youpi> that's vm_copy, yes + <youpi> but then if the app modifies the piece, you have to copy-on-write + <youpi> anywauy, really gottago + <solid_black> that part is handled by Mach + <solid_black> right, so once you're back: my conclusion from looking at libfuse is that it should be rewritten, and should not be using netfs (nor diskfs), but be its own independent translator framework + <solid_black> and it just sounds like I'm going to be the one who is going to do it + <solid_black> and we could indeed use bcachefs as a testbed for the low level api, and darling-dmg for the high level api + <solid_black> I installed avfs from Debian (one of the few packages that depend on libfuse), and sure enough: avfs: symbol lookup error: /lib/i386-gnu/libfuse.so.1: undefined symbol: assert_perror + <solid_black> upstream fuse is built with Meson 🤩️ + <solid_black> I'm wondering whether this would be better done as a port in the upstream libfuse, or as a Hurd-specific libfuse lookalike that borrows some code from the upstream one (as now) + <damo22> solid_black: what is your argument to rewrite a translator framework for fuse? + <damo22> i dont understand + <solid_black> hi + <damo22> hi + <solid_black> basically, 1. while the concepts of libfuse *lowlevel* api seem to match that of hurd / netfs, they seem sufficiently different to not be easily implementable on top of netfs + <solid_black> particularly, the async-ness of it, while netfs expects you to do everything synchronously + <damo22> is that a bug in netfs? + <solid_black> this could be maybe made to work, by putting the netfs thread doing the request to sleep on a condition variable that would get signalled once the answer is provided via the fuse api... but I don't think that's going to be any nicer than designing for the asynchrony from the start + <solid_black> it's not a bug, it's just a design decision, most Hurd tranalators are structured that way + <damo22> maybe you can rewrite netfs to be asynchronous and replace it + <solid_black> i.e.: it's rare that translators use MIG_NO_REPLY + explicit reply, it's much more common to just block the thread + <solid_black> 2. the current state is not "somewhat working", it's "clearly broken" + <damo22> why not start by trying to implement rumpdisk async + <damo22> and see what parts are missing + <solid_black> wdym rumpdisk async? + <damo22> rumpdisk has a todo to make it asynchronous + <damo22> let me find the stub + <damo22> * FIXME: + <damo22> * Long term strategy: + <damo22> * + <damo22> * Call rump_sys_aio_read/write and return MIG_NO_REPLY from + <damo22> * device_read/write, and send the mig reply once the aio request has + <damo22> * completed. That way, only the aio request will be kept in rumpdisk + <damo22> * memory instead of a whole thread structure. + <solid_black> ah right, that reminds me: we still don't have proper mig support for returning errors asynchronously + <damo22> if the disk driver is not asynchronous, what is the point of making the filesystem asynchronous? + <solid_black> the way this works, being asynchronous or not is an implementatin detail of a server + <solid_black> it doesn't matter to others, the RPC format is the same + <solid_black> there's probably not much point in asynchrony for a real disk fs like bcachefs, which must be why they don't use it and reply immediately + <solid_black> but imagine you're implementing an over-the-network fs with fuse, then you'd want asynchrony + <damo22> what is your goal here? do you want to fix libfuse? + <solid_black> I don't know + <solid_black> I'm preparing for the call with Kent + <solid_black> but it looks like I'm going to have to rewrite libfuse, yes + <damo22> possibly the caching is important + <damo22> ie, where does it happen + <solid_black> maybe, yes + <solid_black> does fuse support mmap? + <damo22> idk + <damo22> good q for kent + <solid_black> one essential fs property is coherence between mmap and r/w + <solid_black> so it you change a byte in an mmaped file area, a read() of that byte after that should already return the new value + <solid_black> same for write() + read from memory + <solid_black> this is why libdiskfs insists on reading/writing files via the pager and not via callbacks + <solid_black> I wonder how fuse deals with this + <damo22> good point, no idea + <solid_black> does fuse really make the kernel handle O_CREAT / O_EXCL? I can't imagine how that would work without racing + <solid_black> guess it could be done by trying opening/creating in a loop, if creation itself is atomic, but this is not nice + <damo22> something is still slowing down smp + <damo22> it cant possibly be executing as fast as possible on all cores + <damo22> if more cores are available to run threads, it should boot faster not slower + <azert> Hi damo22, your reasoning would hold if the kernel wouldn’t be “wasting” most of its time running in kernel mode tasks + <azert> If replacing CPU_NUMBER by a better implementation gave you a two digits improvement, that kind of implies that the kernel is indeed taking most of the cpu + <damo22> yes i mean, something in the kernel is slowing down smp + <azert> What about vm_map and all thread tasks synchronization + <azert> ? + <damo22> i dont understand how the scheduler can halt the APs in machine_idle() and not end up wasting time + <damo22> how does anything ever run after HLT + <damo22> in that code path + <damo22> if the idle thread halts the processor the only way it can wake up is with an interrupt + <damo22> but then, does MARK_CPU_ACTIVE() ever run? + <damo22> hmm it does + <azert> I think that normally the cpu would be running scheduler code and get a thread by itself. + <damo22> thats not how it works + <damo22> most of the cpus are in idle_continue + <damo22> then on a clock interrupt or ast interrupt, they are woken to choose a thread i think + <damo22> s/choose/run + <azert> If they are in cpu_idle then that’s what happens, yea + <azert> But normally they wouldn’t be in cpu idle but running the schedule and just a thread on their own + <azert> Cpu_idle basically turns off the cpu + <azert> To save power + <damo22> every time i interrupt the kernel debugger, its in cpu-idle + <damo22> i dont know if it waits until it is in that state so maybe thats why + <azert> That means that there is nothing to schedule + <azert> Or yea that’s another explanation + <damo22> yes, exactly i think it is seemingly running out of threads to schedule + <azert> A bug in the debugger + <damo22> i need to print the number of threads in the queue + <youpi> adding a show subcommand for the scheduler state would probably be useful + <youpi> solid_black: btw, about copies, there's a todo in rumpdisk's rumpdisk_device_read : /* directly write at *data when it is aligned */ + <solid_black> youpi: indeed, that looks relevant, and wouldn't be hard to do + <solid_black> ideally, it should all be zero-copy (or: minimal number of copies), from the device buffer (DMA? idk how this works, can dma pages be then used as regular vm pages?) all the way to the data a unix process receives from read() or something like that + <solid_black> without "slow" memcpies, and ideally with little vm_copies too, though transferring ages in Mach messages is ok + <solid_black> s/ages/pages/ + <solid_black> read() requires ones copy purely because it writes into the provided buffer (and not returns a new one), and we don't have mach_msg_overwrite + <solid_black> though again one would hope vm_copy would help there + <solid_black> ...I do think that it'd be easier to port bcachefs over to netfs than to rewrite libfuse though + <solid_black> but then nothing is going to motivate me to work on libfuse + <azert> solid_black: I never work on things that don’t motivate me somehow + <azert> Btw, if you want zerocopy for IO, I think you need to do asynchronous io + <azert> At least that’s the only way for me to make sense of zerocopy + <solid_black> I don't think sync vs async has much to do with zero-copy-ness? w + + diff --git a/open_issues/clock_gettime.mdwn b/open_issues/clock_gettime.mdwn index 407a104c..d9f05999 100644 --- a/open_issues/clock_gettime.mdwn +++ b/open_issues/clock_gettime.mdwn @@ -95,7 +95,7 @@ In context of [[select]]. ## IRC, freenode, #hurd, 2013-02-12 <braunr> pinotree: - http://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?h=rbraun/select_timeout_pthread_v2&id=6ec50e62d9792c803d00cbff1cab2c0b3675690a + https://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?h=rbraun/select_timeout_pthread_v2&id=6ec50e62d9792c803d00cbff1cab2c0b3675690a <pinotree> uh nice <pinotree> will need two small inline functions to convert time_data_t <-> timespec, but that's it diff --git a/open_issues/copyright_assignment.mdwn b/open_issues/copyright_assignment.mdwn new file mode 100644 index 00000000..dd5fa3d4 --- /dev/null +++ b/open_issues/copyright_assignment.mdwn @@ -0,0 +1,20 @@ +[[!meta copyright="Copyright © 2021 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]]."]]"""]] + +Current issues with copyright assignments: + +* David Michael never started the process. +* Kalle Olavi Niemitalo ([contribution](https://savannah.gnu.org/bugs/index.php?48930) [contribution](https://savannah.gnu.org/bugs/index.php?49056)) [does not want to assign copyright](https://lists.gnu.org/archive/html/bug-hurd/2016-10/msg00069.html) +* Olaf Buddenhagen, faced with process issues, gave up around 2016 july 23rd. +* Brent Baccala (cases #1160318 #1497319): does not want to assign all past+future changes, would rather provide code under a BSD licence, or assign copyright separately for each contribution (request-assign.changes). +* Sergey Bugaev (case #1722866): sent form on 2021 May 8th, got answer on May 24th, immediately answered that there was an error in the actual family name. Eventually that was fixed, but the papers have the name in an order which is not proper for Russian law. Moved on with it. But hasn't had any answer during august and september. And then he got conscribed and so we won't have any news from him until around november 2022. +* Luca Dariz (case #1803259): process ongoing, sent form on 2022 Feb 1st, got answer on Feb 11th, pending completion. +* Various main contributors consider copyright assignment an unnecessary burden, the Hurd being considered as never-to-be-key-software. diff --git a/open_issues/crt0_o_crt1_o_debug_info_relocation_invalid_symbol_index.mdwn b/open_issues/crt0_o_crt1_o_debug_info_relocation_invalid_symbol_index.mdwn deleted file mode 100644 index b94c0c1d..00000000 --- a/open_issues/crt0_o_crt1_o_debug_info_relocation_invalid_symbol_index.mdwn +++ /dev/null @@ -1,41 +0,0 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled [[GNU Free Documentation -License|/fdl]]."]]"""]] - -[[!tag open_issue_glibc open_issue_gcc]] - - $ gcc -o /dev/null -x c /dev/null - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 0 has invalid symbol index 12 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 1 has invalid symbol index 13 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 2 has invalid symbol index 2 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 3 has invalid symbol index 2 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 4 has invalid symbol index 12 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 5 has invalid symbol index 14 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 6 has invalid symbol index 14 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 7 has invalid symbol index 14 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 8 has invalid symbol index 2 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 9 has invalid symbol index 2 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 10 has invalid symbol index 13 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 11 has invalid symbol index 14 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 12 has invalid symbol index 14 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 13 has invalid symbol index 14 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 14 has invalid symbol index 14 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 15 has invalid symbol index 14 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 16 has invalid symbol index 14 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 17 has invalid symbol index 14 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 18 has invalid symbol index 14 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 19 has invalid symbol index 14 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 20 has invalid symbol index 14 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 21 has invalid symbol index 14 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 22 has invalid symbol index 22 - /usr/lib/gcc/i486-gnu/4.4.5/../../../crt1.o: In function `_start': - (.text+0x18): undefined reference to `main' - collect2: ld returned 1 exit status - -Likewise for `-static`, `crt0.o`. diff --git a/open_issues/cvs_tasks_file.mdwn b/open_issues/cvs_tasks_file.mdwn deleted file mode 100644 index 67b64651..00000000 --- a/open_issues/cvs_tasks_file.mdwn +++ /dev/null @@ -1,18 +0,0 @@ -[[!meta copyright="Copyright © 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009 -Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] - -[[!meta title="CVS tasks file"]] - -[[!tag open_issue_hurd]] - -The canonical [tasks -file](http://savannah.gnu.org/cgi-bin/viewcvs/~checkout~/hurd/hurd/tasks?rev=HEAD&content-type=text/plain) -from the CVS archive. diff --git a/open_issues/emacs.mdwn b/open_issues/emacs.mdwn index e00c3d4e..21661f02 100644 --- a/open_issues/emacs.mdwn +++ b/open_issues/emacs.mdwn @@ -12,1531 +12,30 @@ License|/fdl]]."]]"""]] [[!tag open_issue_porting]] -GNU Emacs mostly does work, however there are a few issues. - - * `dired` on a directory hangs. (Use `C-g C-g` to break the unresponsive - operation.) - - * Configuration in `src/s/`: `gnu.h` uses `bsd-common.h`. `gnu-kfreebsd.h` - uses `gnu-linux.h` -- we probably should too. - - * `gnu-linux.h` makes a few things depend on `/proc` (also see - `HAVE_PROCFS`) -- either resort to our own ways, or enhance our - [[hurd/translator/procfs]] accordingly. - - * `sysdep.c` - - * Got a hang when compiling GNU Emacs 23, when it was compiling `.el` to - `.elc` files. Looked like busy-looping inside glibc. This was not - reproducible so far. - - * Debian emacs23_23.1+1-2, grubber, (probably) busy-looping in `ext2fs` on - `/media/data` when resuming emacs23 build in `~/tmp/emacs/emacs23-*/` - (`dpkg-buildpackage -B -uc -nc 2>&1 | tee L`). No modifications to - `emacs23-*` so far, I think. Hangs always in the same place, it seems, and - reproducible. Tarred to `emacs23-23.1+1.tar.bz2` (beware: empty and - zero-permission files: - `emacs23-23.1+1/.pc/debian-site-init-el.diff/lisp/site-init.el`, - `emacs23-23.1+1/.pc/autofiles.diff/src/config.in~`). At hang-time: the - rootfs is fine (`syncfs -c -s /` works; `syncfs` involving `/media/data` - hangs). Plan: GDB on that ext2fs, and see what's hanging / locked. [[!tag - open_issue_hurd]] - +GNU Emacs works pretty well. It works beautifully in X. --- -# 2010-10-11 - -Apparently, none of the Debian emacs packages are installable at the moment. - -Try to compile bzr trunk. - -System (sort-of) crashed during build. Perhaps while / or shortly after -dumping `src/emacs`, as there was such a zero-sized file. (Log file doesn't -show anything useful.) Removed the truncated `src/emacs`, continued build: - - [...] - Compiling /home/tschwinge/tmp/emacs/trunk/lisp/cedet/srecode/mode.el - Parsing *srecode-map-tmp* (LALR)... - Parsing *srecode-map-tmp* (LALR)...done - Segmentation fault - make[2]: *** [cedet/srecode/mode.elc] Error 139 - make[2]: Leaving directory `/media/data/home/tschwinge/tmp/emacs/trunk.build/lisp' - make[1]: *** [compile-main] Error 2 - make[1]: Leaving directory `/media/data/home/tschwinge/tmp/emacs/trunk.build/lisp' - make: *** [lisp] Error 2 - -Command line: - - $ EMACSLOADPATH=/home/tschwinge/tmp/emacs/trunk/lisp LC_ALL=C /home/tschwinge/tmp/emacs/trunk.build/src/emacs -batch --no-site-file -f batch-byte-compile /home/tschwinge/tmp/emacs/trunk/lisp/cedet/srecode/mode.el - -GDB: - - Program received signal SIGSEGV, Segmentation fault. - mark_object (arg=1) at /home/tschwinge/tmp/emacs/trunk/src/alloc.c:5343 - 5343 if (STRING_MARKED_P (ptr)) - (gdb) bt - #0 mark_object (arg=1) at /home/tschwinge/tmp/emacs/trunk/src/alloc.c:5343 - #1 0x0818080f in Fgarbage_collect () at /home/tschwinge/tmp/emacs/trunk/src/alloc.c:4993 - #2 0x08196db3 in Ffuncall (nargs=1, args=0x23fce70) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2987 - #3 0x081ce8e1 in Fbyte_code (bytestr=139696577, vector=141708997, maxdepth=28) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 - #4 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 - #5 0x08196bb3 in Ffuncall (nargs=1, args=0x23fcff0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 - #6 0x081ce8e1 in Fbyte_code (bytestr=139922913, vector=141583493, maxdepth=28) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 - #7 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 - #8 0x08196bb3 in Ffuncall (nargs=3, args=0x23fd170) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 - #9 0x081ce8e1 in Fbyte_code (bytestr=140515737, vector=141583205, maxdepth=24) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 - #10 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 - #11 0x08196bb3 in Ffuncall (nargs=2, args=0x23fd2f0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 - #12 0x081ce8e1 in Fbyte_code (bytestr=139911193, vector=139312997, maxdepth=12) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 - #13 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 - #14 0x08196bb3 in Ffuncall (nargs=3, args=0x23fd460) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 - #15 0x081ce8e1 in Fbyte_code (bytestr=136508105, vector=136508125, maxdepth=20) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 - #16 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 - #17 0x08196bb3 in Ffuncall (nargs=3, args=0x23fd5e0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 - #18 0x081ce8e1 in Fbyte_code (bytestr=136508849, vector=136508869, maxdepth=20) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 - #19 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 - #20 0x08195bff in apply_lambda (fun=136508805, args=139814646, eval_flag=1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3100 - #21 0x08195ef4 in Feval (form=139814582) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2412 - #22 0x081bb206 in readevalloop (readcharfun=138475290, stream=<value optimized out>, sourcename=139636697, printflag=0, unibyte=138364586, readfun=138364586, - start=138364586, end=138364586, evalfun=<value optimized out>) at /home/tschwinge/tmp/emacs/trunk/src/lread.c:1734 - #23 0x081bbad7 in Fload (file=140023529, noerror=138364586, nomessage=138364610, nosuffix=138364586, must_suffix=138364586) - at /home/tschwinge/tmp/emacs/trunk/src/lread.c:1225 - #24 0x081a1357 in Frequire (feature=141037690, filename=138364586, noerror=138364586) at /home/tschwinge/tmp/emacs/trunk/src/fns.c:2694 - #25 0x08196d83 in Ffuncall (nargs=2, args=0x23fdb90) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2996 - #26 0x081ce8e1 in Fbyte_code (bytestr=140023705, vector=141489853, maxdepth=8) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 - #27 0x08196304 in Feval (form=141177630) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2358 - #28 0x081bb206 in readevalloop (readcharfun=138475290, stream=<value optimized out>, sourcename=140023785, printflag=0, unibyte=138364586, readfun=138364586, - start=138364586, end=138364586, evalfun=<value optimized out>) at /home/tschwinge/tmp/emacs/trunk/src/lread.c:1734 - #29 0x081bbad7 in Fload (file=139743441, noerror=138364586, nomessage=138364610, nosuffix=138364586, must_suffix=138364586) - at /home/tschwinge/tmp/emacs/trunk/src/lread.c:1225 - #30 0x081a1357 in Frequire (feature=140528330, filename=138364586, noerror=138364586) at /home/tschwinge/tmp/emacs/trunk/src/fns.c:2694 - #31 0x08196d83 in Ffuncall (nargs=2, args=0x23fe030) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2996 - #32 0x081ce8e1 in Fbyte_code (bytestr=139743489, vector=139592949, maxdepth=8) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 - #33 0x08196304 in Feval (form=139785254) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2358 - #34 0x081bb206 in readevalloop (readcharfun=138475290, stream=<value optimized out>, sourcename=139743569, printflag=0, unibyte=138364586, readfun=138364586, - start=138364586, end=138364586, evalfun=<value optimized out>) at /home/tschwinge/tmp/emacs/trunk/src/lread.c:1734 - #35 0x081bbad7 in Fload (file=139985769, noerror=138364586, nomessage=138364610, nosuffix=138364586, must_suffix=138364586) - at /home/tschwinge/tmp/emacs/trunk/src/lread.c:1225 - #36 0x081a1357 in Frequire (feature=140528282, filename=138364586, noerror=138364586) at /home/tschwinge/tmp/emacs/trunk/src/fns.c:2694 - #37 0x08196d83 in Ffuncall (nargs=2, args=0x23fe5c4) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2996 - #38 0x0819879e in Fapply (nargs=2, args=0x23fe5c4) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2453 - #39 0x08196e26 in Ffuncall (nargs=3, args=0x23fe5c0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2971 - #40 0x081ce8e1 in Fbyte_code (bytestr=139665665, vector=140243293, maxdepth=12) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 - #41 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 - #42 0x08196bb3 in Ffuncall (nargs=2, args=0x23fe730) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 - #43 0x081ce8e1 in Fbyte_code (bytestr=139663633, vector=140113917, maxdepth=16) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 - #44 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 - #45 0x08196bb3 in Ffuncall (nargs=2, args=0x23fe8a0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 - #46 0x081ce8e1 in Fbyte_code (bytestr=139651313, vector=141733317, maxdepth=16) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 - #47 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 - #48 0x08196bb3 in Ffuncall (nargs=1, args=0x23fea20) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 - #49 0x081961cd in Feval (form=142062606) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2324 - #50 0x08198ec2 in internal_lisp_condition_case (var=139619738, bodyform=142062606, handlers=142059126) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:1407 - #51 0x081cdb3a in Fbyte_code (bytestr=139651065, vector=138947149, maxdepth=64) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:869 - #52 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 - #53 0x08196bb3 in Ffuncall (nargs=3, args=0x23fed10) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 - #54 0x081ce8e1 in Fbyte_code (bytestr=139638617, vector=140190309, maxdepth=32) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 - #55 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 - #56 0x08195bff in apply_lambda (fun=141815293, args=139024998, eval_flag=1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3100 - #57 0x08195ef4 in Feval (form=139025038) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2412 - #58 0x08198ec2 in internal_lisp_condition_case (var=138727490, bodyform=139025038, handlers=138994086) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:1407 - #59 0x081cdb3a in Fbyte_code (bytestr=141397873, vector=139422605, maxdepth=12) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:869 - #60 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 - #61 0x08196bb3 in Ffuncall (nargs=2, args=0x23ff150) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 - #62 0x081ce8e1 in Fbyte_code (bytestr=141396361, vector=138448733, maxdepth=20) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 - #63 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 - #64 0x08196bb3 in Ffuncall (nargs=1, args=0x23ff2d0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 - #65 0x081ce8e1 in Fbyte_code (bytestr=136699577, vector=136699597, maxdepth=40) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 - #66 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 - #67 0x08196bb3 in Ffuncall (nargs=2, args=0x23ff460) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 - #68 0x081ce8e1 in Fbyte_code (bytestr=136685793, vector=136685813, maxdepth=28) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 - #69 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 - #70 0x08196bb3 in Ffuncall (nargs=1, args=0x23ff5e0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 - #71 0x081ce8e1 in Fbyte_code (bytestr=136683265, vector=136683285, maxdepth=24) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 - #72 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 - #73 0x08195bff in apply_lambda (fun=136683245, args=138364586, eval_flag=1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3100 - #74 0x08195ef4 in Feval (form=138740766) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2412 - #75 0x0812dd83 in top_level_2 () at /home/tschwinge/tmp/emacs/trunk/src/keyboard.c:1336 - #76 0x081951dc in internal_condition_case (bfun=0x812dd70 <top_level_2>, handlers=138394034, hfun=0x8132020 <cmd_error>) - at /home/tschwinge/tmp/emacs/trunk/src/eval.c:1460 - #77 0x08131de5 in top_level_1 (ignore=138364586) at /home/tschwinge/tmp/emacs/trunk/src/keyboard.c:1344 - #78 0x081952a9 in internal_catch (tag=138392170, func=0x8131d80 <top_level_1>, arg=138364586) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:1204 - #79 0x08131e53 in command_loop () at /home/tschwinge/tmp/emacs/trunk/src/keyboard.c:1299 - #80 0x0813220a in recursive_edit_1 () at /home/tschwinge/tmp/emacs/trunk/src/keyboard.c:929 - #81 0x08132332 in Frecursive_edit () at /home/tschwinge/tmp/emacs/trunk/src/keyboard.c:991 - #82 0x0812727b in main (argc=<value optimized out>, argv=0x23ffad8) at /home/tschwinge/tmp/emacs/trunk/src/emacs.c:1718 - -Next: restarted from scratch, rebuilt without optimizations. -`--prefix=$PWD.install --build=i686-pc-gnu --enable-asserts ---enable-checking=all CFLAGS=-g` - - $ make - [...] - Dumping under the name emacs [sits here for a long time] - - $ vmstat - pagesize: 4K - size: 324M - free: 9.16M - active: 56M - inactive: 242M - wired: 17.6M - zero filled: 8.75G - reactivated: 0 - pageins: 289M - pageouts: 371M - page faults: 12508128 - cow faults: 1411724 - memobj hit ratio: 99% - swap size: 512M - swap free: 512M - -Apparently low memory, but doesn't swap out. - -Uses a lot of CPU time, as observed with `xm top`. - -Creating another `screen` window as user tschwinge doesn't get to the shell -prompt. - -Running `vmstat` works in a `screen` window that is already open, but running -`ps -Af` just hangs; adding `-M` helps. - -Perhaps the /media/data/ file system (which backs /home/) is in a inconsistent -state / deadlocked? - -More specifically, this does not work / does not exit: - - login> syncfs -s -c /media/data/ & - [2] 10785 - -But this works: - - login> syncfs -s -c / & - [3] 10786 - login> - [3]+ Done syncfs -s -c / - -Thus, the rootfs still is responsive; /media/data/ is not. - - login> ps -F hurd-long -T -M -w -A & - [4] 10796 - login> PID TH# UID PPID PGrp Sess TH Vmem RSS %CPU User System Args - 0 0 1 1 1 16 132M 1M 0.0 0:04.84 0:54.84 /hurd/proc - 0 0.0 0:00.00 0:00.13 - 1 0.0 0:00.30 0:03.55 - 2 0.0 0:00.30 0:04.21 - 3 0.0 0:00.65 0:06.88 - 4 0.0 0:00.02 0:00.31 - 5 0.0 0:00.32 0:03.72 - 6 0.0 0:00.00 0:00.23 - 7 0.0 0:00.00 0:00.03 - 8 0.0 0:00.30 0:03.17 - 9 0.0 0:00.47 0:04.69 - 10 0.0 0:00.62 0:06.42 - 11 0.0 0:00.40 0:05.91 - 12 0.0 0:00.47 0:04.18 - 13 0.0 0:00.10 0:00.73 - 14 0.0 0:00.56 0:05.97 - 15 0.0 0:00.26 0:04.61 - 1 0 1 1 1 1 146M 368K 0.0 0:00.00 0:00.03 /hurd/init root=device:hd0 - 0 0.0 0:00.00 0:00.03 - 2 - 1 1 1 7 418M 19.5M 0.0 0:00.00 0:12.16 root=device:hd0 - 0 0.0 0:00.00 0:00.00 - 1 92.6 0:00.00 46:33.66 - 2 0.0 0:00.00 0:12.07 - 3 0.0 0:00.00 0:00.05 - 4 0.0 0:00.00 0:00.02 - 5 0.0 0:00.00 0:00.00 - 6 0.0 0:00.00 0:00.01 - 3 0 1 1 1 173 409M 15.7M 0.2 4:39.39 34:08.86 ext2fs -A --multiboot-command-line=root=device:hd0 --host-priv-port=1 --device-master-port=2 -- - [165CM-exec-server-task=3 -T typed device:hd0 - 0 0.0 0:00.00 0:00.02 - 1 0.0 0:21.78 2:32.67 - 2 0.0 0:00.15 0:01.33 - 3 0.0 0:00.07 0:01.13 - 4 0.0 0:22.09 2:32.56 - 5 0.0 0:00.11 0:01.30 - 6 0.0 0:21.57 2:32.78 - 7 0.2 0:04.10 0:54.37 - 8 0.0 0:00.00 0:00.01 - 9 0.0 0:20.96 2:30.00 - 10 0.0 0:00.09 0:01.05 - 11 0.0 0:00.09 0:00.94 - 12 0.0 0:21.59 2:32.40 - 13 0.0 0:21.50 2:32.02 - 14 0.0 0:00.00 0:00.92 - 15 0.0 0:00.07 0:00.60 - 16 0.0 0:00.09 0:00.86 - 17 0.0 0:00.04 0:00.88 - 18 0.0 0:00.13 0:00.91 - 19 0.0 0:00.04 0:00.91 - 20 0.0 0:00.02 0:00.89 - 21 0.0 0:00.08 0:00.97 - 22 0.0 0:00.05 0:00.84 - 23 0.0 0:00.04 0:00.86 - 24 0.0 0:00.09 0:00.86 - 25 0.0 0:00.11 0:00.88 - 26 0.0 0:00.04 0:00.64 - 27 0.0 0:21.10 2:32.22 - 28 0.0 0:20.32 2:29.92 - 29 0.0 0:20.58 2:31.51 - 30 0.0 0:20.50 2:32.72 - 31 0.0 0:21.05 2:30.05 - 32 0.0 0:19.78 2:33.40 - 33 0.0 0:20.55 2:31.88 - 34 0.0 0:00.00 0:00.06 - 35 0.0 0:00.00 0:00.07 - 36 0.0 0:00.00 0:00.02 - 37 0.0 0:00.01 0:00.05 - 38 0.0 0:00.00 0:00.03 - 39 0.0 0:00.00 0:00.02 - 40 0.0 0:00.00 0:00.06 - 41 0.0 0:00.02 0:00.02 - 42 0.0 0:00.00 0:00.03 - 43 0.0 0:00.00 0:00.05 - 44 0.0 0:00.00 0:00.07 - 45 0.0 0:00.00 0:00.02 - 46 0.0 0:00.00 0:00.02 - 47 0.0 0:00.00 0:00.04 - 48 0.0 0:00.00 0:00.03 - 49 0.0 0:00.00 0:00.03 - 50 0.0 0:00.00 0:00.05 - 51 0.0 0:00.00 0:00.05 - 52 0.0 0:00.00 0:00.04 - 53 0.0 0:00.00 0:00.04 - 54 0.0 0:00.00 0:00.02 - 55 0.0 0:00.00 0:00.03 - 56 0.0 0:00.01 0:00.01 - 57 0.0 0:00.03 0:00.01 - 58 0.0 0:00.01 0:00.00 - 59 0.0 0:00.00 0:00.00 - 60 0.0 0:00.00 0:00.00 - 61 0.0 0:00.00 0:00.03 - 62 0.0 0:00.00 0:00.00 - 63 0.0 0:00.00 0:00.08 - 64 0.0 0:00.00 0:00.06 - 65 0.0 0:00.01 0:00.00 - 66 0.0 0:00.00 0:00.07 - 67 0.0 0:00.00 0:00.01 - 68 0.0 0:00.02 0:00.02 - 69 0.0 0:00.01 0:00.02 - 70 0.0 0:00.01 0:00.01 - 71 0.0 0:00.01 0:00.04 - 72 0.0 0:00.00 0:00.01 - 73 0.0 0:00.01 0:00.00 - 74 0.0 0:00.00 0:00.06 - 75 0.0 0:00.00 0:00.04 - 76 0.0 0:00.02 0:00.05 - 77 0.0 0:00.00 0:00.03 - 78 0.0 0:00.00 0:00.02 - 79 0.0 0:00.00 0:00.05 - 80 0.0 0:00.01 0:00.00 - 81 0.0 0:00.00 0:00.02 - 82 0.0 0:00.00 0:00.03 - 83 0.0 0:00.00 0:00.00 - 84 0.0 0:00.00 0:00.00 - 85 0.0 0:00.00 0:00.04 - 86 0.0 0:00.00 0:00.04 - 87 0.0 0:00.00 0:00.02 - 88 0.0 0:00.01 0:00.00 - 89 0.0 0:00.00 0:00.04 - 90 0.0 0:00.00 0:00.04 - 91 0.0 0:00.00 0:00.05 - 92 0.0 0:00.00 0:00.02 - 93 0.0 0:00.00 0:00.03 - 94 0.0 0:00.00 0:00.02 - 95 0.0 0:00.00 0:00.01 - 96 0.0 0:00.00 0:00.02 - 97 0.0 0:00.00 0:00.03 - 98 0.0 0:00.00 0:00.05 - 99 0.0 0:00.00 0:00.04 - 100 0.0 0:00.00 0:00.03 - 101 0.0 0:00.00 0:00.01 - 102 0.0 0:00.00 0:00.01 - 103 0.0 0:00.00 0:00.05 - 104 0.0 0:00.00 0:00.06 - 105 0.0 0:00.01 0:00.04 - 106 0.0 0:00.00 0:00.00 - 107 0.0 0:00.01 0:00.02 - 108 0.0 0:00.00 0:00.00 - 109 0.0 0:00.00 0:00.02 - 110 0.0 0:00.00 0:00.01 - 111 0.0 0:00.00 0:00.02 - 112 0.0 0:00.01 0:00.04 - 113 0.0 0:00.01 0:00.01 - 114 0.0 0:00.00 0:00.02 - 115 0.0 0:00.01 0:00.02 - 116 0.0 0:00.01 0:00.03 - 117 0.0 0:00.00 0:00.03 - 118 0.0 0:00.01 0:00.01 - 119 0.0 0:00.00 0:00.01 - 120 0.0 0:00.00 0:00.05 - 121 0.0 0:00.00 0:00.02 - 122 0.0 0:00.00 0:00.02 - 123 0.0 0:00.00 0:00.04 - 124 0.0 0:00.00 0:00.04 - 125 0.0 0:00.00 0:00.02 - 126 0.0 0:00.00 0:00.02 - 127 0.0 0:00.01 0:00.01 - 128 0.0 0:00.00 0:00.01 - 129 0.0 0:00.01 0:00.03 - 130 0.0 0:00.01 0:00.05 - 131 0.0 0:00.00 0:00.02 - 132 0.0 0:00.00 0:00.03 - 133 0.0 0:00.00 0:00.03 - 134 0.0 0:00.00 0:00.02 - 135 0.0 0:00.00 0:00.00 - 136 0.0 0:00.00 0:00.01 - 137 0.0 0:00.01 0:00.03 - 138 0.0 0:00.00 0:00.03 - 139 0.0 0:00.00 0:00.02 - 140 0.0 0:00.01 0:00.01 - 141 0.0 0:00.01 0:00.02 - 142 0.0 0:00.00 0:00.00 - 143 0.0 0:00.00 0:00.02 - 144 0.0 0:00.01 0:00.00 - 145 0.0 0:00.00 0:00.01 - 146 0.0 0:00.00 0:00.00 - 147 0.0 0:00.00 0:00.00 - 148 0.0 0:00.00 0:00.03 - 149 0.0 0:00.00 0:00.00 - 150 0.0 0:00.00 0:00.01 - 151 0.0 0:00.00 0:00.00 - 152 0.0 0:00.00 0:00.01 - 153 0.0 0:00.00 0:00.00 - 154 0.0 0:00.00 0:00.00 - 155 0.0 0:00.00 0:00.00 - 156 0.0 0:00.00 0:00.00 - 157 0.0 0:00.00 0:00.01 - 158 0.0 0:00.00 0:00.00 - 159 0.0 0:00.00 0:00.01 - 160 0.0 0:00.00 0:00.01 - 161 0.0 0:00.00 0:00.00 - 162 0.0 0:00.00 0:00.00 - 163 0.0 0:00.00 0:00.00 - 164 0.0 0:00.00 0:00.01 - 165 0.0 0:00.00 0:00.00 - 166 0.0 0:00.00 0:00.00 - 167 0.0 0:00.00 0:00.00 - 168 0.0 0:00.00 0:00.00 - 169 0.0 0:00.00 0:00.00 - 170 0.0 0:00.00 0:00.00 - 171 0.0 0:00.00 0:00.00 - 172 0.0 0:00.00 0:00.00 - 4 0 3 1 1 6 131M 1.32M 0.0 0:02.20 0:26.26 /hurd/exec - 0 0.0 0:00.43 0:05.32 - 1 0.0 0:00.41 0:05.54 - 2 0.0 0:00.44 0:05.38 - 3 0.0 0:00.00 0:00.00 - 4 0.0 0:00.45 0:05.05 - 5 0.0 0:00.44 0:04.95 - 5 0 1 1 1 6 130M 580K 0.0 0:01.17 0:14.92 /hurd/auth - 0 0.0 0:00.20 0:02.99 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.24 0:03.03 - 3 0.0 0:00.18 0:02.86 - 4 0.0 0:00.22 0:03.01 - 5 0.0 0:00.31 0:03.01 - 6 0 1 6 6 2 147M 1.09M 0.0 0:00.01 0:00.13 /bin/bash /libexec/runsystem root=device:hd0 - 0 0.0 0:00.01 0:00.13 - 1 0.0 0:00.00 0:00.00 - 7 0 3 1 1 7 130M 880K 0.1 0:00.35 0:10.10 /hurd/term /dev/console device console - 0 0.0 0:00.07 0:01.15 - 1 0.0 0:00.00 0:00.01 - 2 0.0 0:00.14 0:03.10 - 3 0.1 0:00.10 0:01.87 - 4 0.0 0:00.01 0:00.50 - 5 0.0 0:00.00 0:01.54 - 6 0.0 0:00.02 0:01.91 - 9 0 3 1 1 19 131M 1.13M 0.0 0:05.41 1:17.29 /hurd/pflocal - 0 0.0 0:00.06 0:00.48 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.05 0:00.48 - 3 0.0 0:00.78 0:09.10 - 4 0.0 0:00.49 0:06.13 - 5 0.0 0:00.56 0:07.07 - 6 0.0 0:00.30 0:03.41 - 7 0.0 0:00.47 0:05.58 - 8 0.0 0:00.27 0:06.00 - 9 0.0 0:00.04 0:00.47 - 10 0.0 0:00.43 0:06.17 - 11 0.0 0:00.70 0:09.21 - 12 0.0 0:00.00 0:00.04 - 13 0.0 0:00.59 0:10.75 - 14 0.0 0:00.14 0:01.86 - 15 0.0 0:00.04 0:01.49 - 16 0.0 0:00.02 0:00.76 - 17 0.0 0:00.22 0:05.59 - 18 0.0 0:00.16 0:02.62 - 12 0 1 12 12 6 129M 1.2M 0.0 0:00.00 0:00.06 /hurd/mach-defpager - 0 0.0 0:00.00 0:00.06 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.00 0:00.00 - 3 0.0 0:00.00 0:00.00 - 4 0.0 0:00.00 0:00.00 - 5 0.0 0:00.00 0:00.00 - 14 0 3 1 1 3 131M 504K 0.0 0:00.00 0:00.05 /hurd/storeio hd1 - 0 0.0 0:00.00 0:00.05 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.00 0:00.00 - 18 0 3 1 1 3 131M 512K 0.0 0:00.39 0:06.71 /hurd/storeio hd0 - 0 0.0 0:00.13 0:01.66 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.25 0:05.04 - 19 0 3 1 1 3 131M 656K 0.0 0:00.27 0:04.89 /hurd/storeio hd2 - 0 0.0 0:00.10 0:01.48 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.16 0:03.41 - 21 0 3 1 1 4 130M 648K 0.0 0:00.55 0:06.94 /hurd/null - 0 0.0 0:00.24 0:02.09 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.08 0:02.16 - 3 0.0 0:00.22 0:02.68 - 22 0 3 1 1 4 130M 820K 0.0 0:00.00 0:00.05 /hurd/procfs - 0 0.0 0:00.00 0:00.04 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.00 0:00.00 - 3 0.0 0:00.00 0:00.00 - 71 1 1 71 71 2 146M 728K 0.0 0:00.00 0:00.03 /usr/sbin/atd - 0 0.0 0:00.00 0:00.02 - 1 0.0 0:00.00 0:00.00 - 77 0 3 1 1 4 130M 896K 0.0 0:00.00 0:00.02 /hurd/streamio kmsg - 0 0.0 0:00.00 0:00.02 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.00 0:00.00 - 3 0.0 0:00.00 0:00.00 - 117 0 1 117 117 2 146M 1.02M 0.0 0:00.00 0:00.04 /usr/sbin/cron - 0 0.0 0:00.00 0:00.04 - 1 0.0 0:00.00 0:00.00 - 122 101 1 122 122 2 7.75M 1.07M 0.0 0:00.00 0:00.05 /usr/bin/dbus-daemon --system - 0 0.0 0:00.00 0:00.05 - 1 0.0 0:00.00 0:00.00 - 128 0 3 1 1 4 130M 908K 0.0 0:00.00 0:00.02 /hurd/fifo - 0 0.0 0:00.00 0:00.02 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.00 0:00.00 - 3 0.0 0:00.00 0:00.00 - 131 8 1 6 6 2 147M 880K 0.0 0:00.01 0:00.07 /usr/sbin/nullmailer-send -d - 0 0.0 0:00.01 0:00.07 - 1 0.0 0:00.00 0:00.00 - 139 0 3 1 1 19 133M 2.19M 0.3 0:18.66 1:17.98 /hurd/pfinet -i /dev/eth0 -a 192.168.10.63 -g 192.168.10.1 -m 255.255.255.0 - 0 0.0 0:00.01 0:00.03 - 1 0.0 0:00.00 0:00.00 - 2 0.1 0:12.72 0:14.56 - 3 0.2 0:01.65 0:12.23 - 4 0.0 0:01.67 0:18.56 - 5 0.0 0:00.50 0:05.93 - 6 0.0 0:00.40 0:06.16 - 7 0.0 0:00.57 0:05.95 - 8 0.0 0:00.30 0:04.15 - 9 0.0 0:00.15 0:01.92 - 10 0.0 0:00.13 0:01.45 - 11 0.0 0:00.14 0:01.47 - 12 0.0 0:00.07 0:01.06 - 13 0.0 0:00.08 0:01.23 - 14 0.0 0:00.08 0:00.92 - 15 0.0 0:00.03 0:00.63 - 16 0.0 0:00.03 0:00.45 - 17 0.0 0:00.05 0:00.72 - 18 0.0 0:00.03 0:00.49 - 140 0 3 1 1 3 131M 1.16M 0.0 0:00.00 0:00.05 /hurd/storeio --no-cache time - 0 0.0 0:00.00 0:00.05 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.00 0:00.00 - 142 0 1 142 142 2 10.5M 1.23M 0.0 0:00.00 0:00.05 /usr/sbin/sshd - 0 0.0 0:00.00 0:00.05 - 1 0.0 0:00.00 0:00.00 - 157 0 3 1 1 6 130M 1M 0.0 0:00.02 0:00.01 /hurd/term /dev/tty1 hurdio /dev/vcs/1/console - 0 0.0 0:00.00 0:00.00 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.00 0:00.00 - 3 0.0 0:00.00 0:00.00 - 4 0.0 0:00.00 0:00.01 - 5 0.0 0:00.01 0:00.00 - 158 0 6 158 158 2 146M 824K 0.0 0:00.00 0:00.01 /libexec/runttys - 0 0.0 0:00.00 0:00.01 - 1 0.0 0:00.00 0:00.00 - 159 0 3 1 1 15 133M 1.67M 0.0 0:00.01 0:00.06 /hurd/console - 0 0.0 0:00.01 0:00.02 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.00 0:00.00 - 3 0.0 0:00.00 0:00.00 - 4 0.0 0:00.00 0:00.01 - 5 0.0 0:00.00 0:00.00 - 6 0.0 0:00.00 0:00.00 - 7 0.0 0:00.00 0:00.02 - 8 0.0 0:00.00 0:00.00 - 9 0.0 0:00.00 0:00.00 - 10 0.0 0:00.00 0:00.00 - 11 0.0 0:00.00 0:00.00 - 12 0.0 0:00.00 0:00.01 - 13 0.0 0:00.00 0:00.00 - 14 0.0 0:00.00 0:00.00 - 160 - 158 160 160 2 147M 1.82M 0.0 0:00.02 0:00.16 -login prompt (bash) - 0 0.0 0:00.02 0:00.14 - 1 0.0 0:00.00 0:00.02 - 161 - 158 161 161 2 147M 1.78M 0.0 0:00.00 0:00.07 -login prompt (bash) - 0 0.0 0:00.00 0:00.07 - 1 0.0 0:00.00 0:00.00 - 162 - 158 162 162 2 147M 1.78M 0.0 0:00.01 0:00.07 -login prompt (bash) - 0 0.0 0:00.01 0:00.07 - 1 0.0 0:00.00 0:00.00 - 163 - 158 163 163 2 147M 1.78M 0.0 0:00.00 0:00.03 -login prompt (bash) - 0 0.0 0:00.00 0:00.03 - 1 0.0 0:00.00 0:00.00 - 164 - 158 164 164 2 147M 1.78M 0.0 0:00.02 0:00.03 -login prompt (bash) - 0 0.0 0:00.02 0:00.03 - 1 0.0 0:00.00 0:00.00 - 165 - 158 165 165 2 147M 1.78M 0.0 0:00.00 0:00.08 -login prompt (bash) - 0 0.0 0:00.00 0:00.08 - 1 0.0 0:00.00 0:00.00 - 166 - 158 166 166 2 147M 1.78M 0.0 0:00.01 0:00.01 -login prompt (bash) - 0 0.0 0:00.01 0:00.01 - 1 0.0 0:00.00 0:00.00 - 167 0 3 1 1 6 130M 1016K 0.0 0:00.01 0:00.11 /hurd/term /dev/tty2 hurdio /dev/vcs/2/console - 0 0.0 0:00.01 0:00.06 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.00 0:00.00 - 3 0.0 0:00.00 0:00.01 - 4 0.0 0:00.00 0:00.03 - 5 0.0 0:00.00 0:00.00 - 168 0 3 1 1 6 130M 1016K 0.0 0:00.00 0:00.04 /hurd/term /dev/tty3 hurdio /dev/vcs/3/console - 0 0.0 0:00.00 0:00.02 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.00 0:00.00 - 3 0.0 0:00.00 0:00.01 - 4 0.0 0:00.00 0:00.00 - 5 0.0 0:00.00 0:00.01 - 169 0 3 1 1 6 130M 1016K 0.0 0:00.00 0:00.04 /hurd/term /dev/tty5 hurdio /dev/vcs/5/console - 0 0.0 0:00.00 0:00.00 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.00 0:00.00 - 3 0.0 0:00.00 0:00.00 - 4 0.0 0:00.00 0:00.04 - 5 0.0 0:00.00 0:00.00 - 170 0 3 1 1 6 130M 1016K 0.0 0:00.00 0:00.05 /hurd/term /dev/tty4 hurdio /dev/vcs/4/console - 0 0.0 0:00.00 0:00.04 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.00 0:00.00 - 3 0.0 0:00.00 0:00.00 - 4 0.0 0:00.00 0:00.01 - 5 0.0 0:00.00 0:00.00 - 171 0 3 1 1 6 130M 1016K 0.0 0:00.00 0:00.01 /hurd/term /dev/tty6 hurdio /dev/vcs/6/console - 0 0.0 0:00.00 0:00.01 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.00 0:00.00 - 3 0.0 0:00.00 0:00.00 - 4 0.0 0:00.00 0:00.00 - 5 0.0 0:00.00 0:00.00 - 172 0 3 1 1 4 130M 892K 0.0 0:00.00 0:00.01 /hurd/password - 0 0.0 0:00.00 0:00.01 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.00 0:00.00 - 3 0.0 0:00.00 0:00.00 - 173 0 142 173 173 3 10.7M 3.09M 0.0 0:02.09 0:12.63 /usr/sbin/sshd -R - 0 0.0 0:02.09 0:12.63 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.00 0:00.00 - 174 0 3 1 1 632 2.99G 27.6M 100.3 16:43.18 52:54.41 /hurd/ext2fs /dev/hd2 - 0 0.0 0:00.01 0:00.03 - 1 0.0 0:00.00 0:00.00 - 2 0.0 1:34.24 6:26.66 - 3 0.0 0:00.04 0:00.31 - 4 0.0 0:00.13 0:00.47 - 5 0.0 0:00.05 0:00.57 - 6 0.0 1:36.91 6:26.41 - 7 0.0 0:12.98 0:34.83 - 8 0.0 1:37.85 6:26.20 - 9 0.0 1:35.07 6:17.07 - 10 0.0 0:00.05 0:00.50 - 11 0.0 0:00.04 0:00.48 - 12 0.0 0:00.07 0:00.55 - 13 0.0 0:00.03 0:00.46 - 14 0.0 0:00.03 0:00.42 - 15 0.0 0:00.06 0:00.32 - 16 0.0 0:00.05 0:00.56 - 17 0.0 0:00.05 0:00.50 - 18 0.0 0:00.05 0:00.48 - 19 0.0 0:00.03 0:00.37 - 20 0.0 0:00.08 0:00.48 - 21 0.0 0:00.01 0:00.52 - 22 0.0 0:00.02 0:00.44 - 23 0.0 0:00.02 0:00.44 - 24 0.0 0:00.03 0:00.31 - 25 0.0 0:00.05 0:00.32 - 26 0.0 0:00.04 0:00.37 - 27 0.0 0:00.00 0:00.31 - 28 0.0 0:00.03 0:00.23 - 29 0.0 0:00.05 0:00.33 - 30 0.0 0:00.04 0:00.31 - 31 0.0 0:00.01 0:00.29 - 32 0.0 0:00.07 0:00.27 - 33 0.0 0:00.05 0:00.28 - 34 0.0 0:00.04 0:00.23 - 35 0.0 0:00.04 0:00.46 - 36 0.0 0:00.02 0:00.31 - 37 0.0 0:00.02 0:00.38 - 38 0.0 0:00.06 0:00.29 - 39 0.0 0:00.03 0:00.22 - 40 0.0 0:00.02 0:00.28 - 41 0.0 0:00.03 0:00.26 - 42 0.0 0:00.05 0:00.39 - 43 0.0 0:00.06 0:00.37 - 44 0.0 0:00.03 0:00.36 - 45 0.0 0:00.04 0:00.20 - 46 0.0 0:00.02 0:00.28 - 47 0.0 0:00.01 0:00.29 - 48 0.0 0:00.03 0:00.23 - 49 0.0 0:00.04 0:00.22 - 50 0.0 0:00.07 0:00.25 - 51 0.0 0:00.00 0:00.33 - 52 0.0 0:00.05 0:00.49 - 53 0.0 0:00.02 0:00.31 - 54 0.0 0:00.00 0:00.27 - 55 0.0 0:00.06 0:00.25 - 56 0.0 0:00.05 0:00.35 - 57 0.0 0:00.01 0:00.28 - 58 0.0 0:00.06 0:00.25 - 59 0.0 0:00.05 0:00.30 - 60 0.0 0:00.03 0:00.36 - 61 0.0 0:00.04 0:00.31 - 62 0.0 0:00.05 0:00.18 - 63 0.0 0:00.02 0:00.31 - 64 0.0 0:00.00 0:00.27 - 65 0.0 0:00.02 0:00.26 - 66 0.0 0:00.00 0:00.31 - 67 0.0 0:00.00 0:00.15 - 68 0.0 0:00.04 0:00.32 - 69 0.0 0:00.04 0:00.21 - 70 0.0 0:00.01 0:00.31 - 71 0.0 0:00.05 0:00.22 - 72 0.0 0:00.01 0:00.28 - 73 0.0 0:00.04 0:00.31 - 74 0.0 0:00.06 0:00.20 - 75 0.0 0:00.04 0:00.38 - 76 0.0 0:00.03 0:00.37 - 77 0.0 0:00.06 0:00.32 - 78 0.0 0:00.04 0:00.22 - 79 0.0 0:00.04 0:00.25 - 80 0.0 0:00.04 0:00.29 - 81 0.0 0:00.07 0:00.31 - 82 0.0 0:00.04 0:00.27 - 83 0.0 0:00.04 0:00.23 - 84 0.0 0:00.02 0:00.37 - 85 0.0 0:00.03 0:00.24 - 86 0.0 0:00.01 0:00.29 - 87 0.0 0:00.03 0:00.24 - 88 0.0 0:00.01 0:00.31 - 89 0.0 0:00.03 0:00.39 - 90 0.0 0:00.00 0:00.30 - 91 0.0 0:00.03 0:00.32 - 92 0.0 0:00.00 0:00.24 - 93 0.0 0:00.03 0:00.32 - 94 0.0 0:00.04 0:00.30 - 95 0.0 0:00.00 0:00.33 - 96 0.0 0:00.02 0:00.24 - 97 0.0 0:00.01 0:00.26 - 98 0.0 0:00.04 0:00.33 - 99 0.0 0:00.03 0:00.26 - 100 0.0 0:00.05 0:00.29 - 101 0.0 0:00.05 0:00.34 - 102 0.0 0:00.04 0:00.38 - 103 0.0 0:00.00 0:00.22 - 104 0.0 0:00.03 0:00.38 - 105 0.0 0:00.01 0:00.43 - 106 0.0 0:00.03 0:00.37 - 107 0.0 0:00.05 0:00.31 - 108 0.0 0:00.02 0:00.31 - 109 0.0 0:00.00 0:00.26 - 110 0.0 0:00.03 0:00.27 - 111 0.0 0:00.03 0:00.25 - 112 0.0 0:00.02 0:00.30 - 113 0.0 0:00.05 0:00.23 - 114 0.0 0:00.02 0:00.32 - 115 0.0 0:00.02 0:00.29 - 116 0.0 0:00.04 0:00.22 - 117 0.0 0:00.04 0:00.26 - 118 0.0 0:00.02 0:00.36 - 119 0.0 0:00.03 0:00.31 - 120 0.0 0:00.04 0:00.26 - 121 0.0 0:00.05 0:00.28 - 122 0.0 0:00.01 0:00.27 - 123 0.0 0:00.03 0:00.34 - 124 0.0 0:00.03 0:00.36 - 125 0.0 0:00.02 0:00.33 - 126 0.0 0:00.04 0:00.36 - 127 0.0 0:00.00 0:00.41 - 128 0.0 0:00.02 0:00.33 - 129 0.0 0:00.07 0:00.32 - 130 0.0 0:00.03 0:00.29 - 131 0.0 0:00.00 0:00.34 - 132 0.0 0:00.04 0:00.28 - 133 0.0 0:00.04 0:00.24 - 134 0.0 0:00.03 0:00.35 - 135 0.0 0:00.04 0:00.38 - 136 0.0 0:00.04 0:00.37 - 137 0.0 0:00.04 0:00.26 - 138 0.0 0:00.00 0:00.26 - 139 0.0 0:00.06 0:00.40 - 140 0.0 1:23.58 6:28.86 - 141 0.0 0:25.74 1:55.97 - 142 0.0 0:00.00 0:00.00 - 143 0.0 0:00.00 0:00.00 - 144 0.0 0:00.00 0:00.00 - 145 0.0 0:00.00 0:00.00 - 146 0.0 0:00.00 0:00.00 - 147 0.0 0:00.00 0:00.00 - 148 0.0 0:00.00 0:00.00 - 149 0.0 0:00.00 0:00.00 - 150 0.0 0:00.00 0:00.00 - 151 0.0 0:00.00 0:00.00 - 152 0.0 0:00.00 0:00.00 - 153 0.0 0:00.00 0:00.00 - 154 0.0 0:00.00 0:00.00 - 155 0.0 0:00.00 0:00.00 - 156 0.0 0:00.00 0:00.00 - 157 0.0 0:00.00 0:00.00 - 158 0.0 0:00.00 0:00.00 - 159 0.0 0:00.00 0:00.00 - 160 0.0 0:00.00 0:00.00 - 161 0.0 0:00.00 0:00.00 - 162 0.0 0:00.00 0:00.00 - 163 0.0 0:00.00 0:00.00 - 164 0.0 0:00.00 0:00.00 - 165 0.0 0:00.00 0:00.00 - 166 0.0 0:00.00 0:00.00 - 167 0.0 0:00.00 0:00.00 - 168 0.0 0:00.00 0:00.00 - 169 0.0 0:00.00 0:00.00 - 170 0.0 0:00.00 0:00.00 - 171 0.0 0:00.00 0:00.00 - 172 0.0 0:00.00 0:00.00 - 173 0.0 0:00.00 0:00.00 - 174 0.0 0:00.00 0:00.00 - 175 0.0 0:00.00 0:00.00 - 176 0.0 0:00.00 0:00.00 - 177 0.0 0:00.00 0:00.00 - 178 0.0 0:00.00 0:00.00 - 179 0.0 0:00.00 0:00.00 - 180 0.0 0:00.00 0:00.00 - 181 0.0 0:00.00 0:00.00 - 182 0.0 0:00.00 0:00.00 - 183 0.0 0:00.00 0:00.00 - 184 0.0 0:00.00 0:00.00 - 185 0.0 0:00.00 0:00.00 - 186 0.0 0:00.00 0:00.00 - 187 0.0 0:00.00 0:00.00 - 188 0.0 0:00.00 0:00.00 - 189 0.0 0:00.00 0:00.00 - 190 0.0 0:00.00 0:00.00 - 191 0.0 0:00.00 0:00.00 - 192 0.0 0:00.00 0:00.00 - 193 0.0 0:00.00 0:00.00 - 194 0.0 0:00.00 0:00.00 - 195 0.0 0:00.00 0:00.00 - 196 0.0 0:00.00 0:00.00 - 197 0.0 0:00.00 0:00.00 - 198 0.0 0:00.00 0:00.00 - 199 0.0 0:00.00 0:00.00 - 200 0.0 0:00.00 0:00.00 - 201 0.0 0:00.00 0:00.00 - 202 0.0 0:00.00 0:00.00 - 203 0.0 0:00.00 0:00.00 - 204 0.0 0:00.00 0:00.00 - 205 0.0 0:00.00 0:00.00 - 206 0.0 0:00.00 0:00.00 - 207 0.0 0:00.00 0:00.00 - 208 0.0 0:00.00 0:00.00 - 209 0.0 0:00.00 0:00.00 - 210 0.0 0:00.00 0:00.00 - 211 0.0 0:00.00 0:00.00 - 212 0.0 0:00.00 0:00.00 - 213 0.0 0:00.00 0:00.00 - 214 0.0 0:00.00 0:00.00 - 215 0.0 0:00.00 0:00.00 - 216 0.0 0:00.00 0:00.00 - 217 0.0 0:00.00 0:00.00 - 218 0.0 0:00.00 0:00.00 - 219 0.0 0:00.00 0:00.00 - 220 0.0 0:00.00 0:00.00 - 221 0.0 0:00.00 0:00.00 - 222 0.0 0:00.00 0:00.00 - 223 0.0 0:00.00 0:00.00 - 224 0.0 0:00.00 0:00.00 - 225 0.0 0:00.00 0:00.00 - 226 0.0 0:00.00 0:00.00 - 227 0.0 0:00.00 0:00.00 - 228 0.0 0:00.00 0:00.00 - 229 0.0 0:00.00 0:00.00 - 230 0.0 0:00.00 0:00.00 - 231 0.0 0:00.00 0:00.00 - 232 0.0 0:00.00 0:00.00 - 233 0.0 0:00.00 0:00.00 - 234 0.0 0:00.00 0:00.00 - 235 0.0 0:00.00 0:00.00 - 236 0.0 0:00.00 0:00.00 - 237 0.0 0:00.00 0:00.00 - 238 0.0 0:00.00 0:00.00 - 239 0.0 0:00.00 0:00.00 - 240 0.0 0:00.00 0:00.00 - 241 0.0 0:00.00 0:00.00 - 242 0.0 0:00.00 0:00.00 - 243 0.0 0:00.00 0:00.00 - 244 0.0 0:00.00 0:00.00 - 245 0.0 0:00.00 0:00.00 - 246 0.0 0:00.00 0:00.00 - 247 0.0 0:00.00 0:00.00 - 248 0.0 0:00.00 0:00.00 - 249 0.0 0:00.00 0:00.00 - 250 0.0 0:00.00 0:00.00 - 251 0.0 0:00.00 0:00.00 - 252 0.0 0:00.00 0:00.00 - 253 0.0 0:00.00 0:00.00 - 254 0.0 0:00.00 0:00.00 - 255 0.0 0:00.00 0:00.00 - 256 0.0 0:00.00 0:00.00 - 257 0.0 0:00.00 0:00.00 - 258 0.0 0:00.00 0:00.00 - 259 0.0 0:00.00 0:00.00 - 260 0.0 0:00.00 0:00.00 - 261 0.0 0:00.00 0:00.00 - 262 0.0 0:00.00 0:00.00 - 263 0.0 0:00.00 0:00.00 - 264 0.0 0:00.00 0:00.00 - 265 0.0 0:00.00 0:00.00 - 266 0.0 0:00.00 0:00.00 - 267 0.0 0:00.00 0:00.00 - 268 0.0 0:00.00 0:00.00 - 269 0.0 0:00.00 0:00.00 - 270 0.0 0:00.00 0:00.00 - 271 0.0 0:00.00 0:00.00 - 272 0.0 0:00.00 0:00.00 - 273 0.0 0:00.00 0:00.00 - 274 0.0 0:00.00 0:00.00 - 275 0.0 0:00.00 0:00.00 - 276 0.0 0:00.00 0:00.00 - 277 0.0 0:00.00 0:00.00 - 278 0.0 0:00.00 0:00.00 - 279 0.0 0:00.00 0:00.00 - 280 0.0 0:00.00 0:00.00 - 281 0.0 0:00.00 0:00.00 - 282 0.0 0:00.00 0:00.00 - 283 0.0 0:00.00 0:00.00 - 284 0.0 0:00.00 0:00.00 - 285 0.0 0:00.00 0:00.00 - 286 0.0 0:00.00 0:00.00 - 287 0.0 0:00.00 0:00.00 - 288 0.0 0:00.00 0:00.00 - 289 0.0 0:00.00 0:00.00 - 290 0.0 0:00.00 0:00.00 - 291 0.0 0:00.00 0:00.00 - 292 0.0 0:00.00 0:00.00 - 293 0.0 0:00.00 0:00.00 - 294 0.0 0:00.00 0:00.00 - 295 0.0 0:00.00 0:00.00 - 296 0.0 0:00.00 0:00.00 - 297 0.0 0:00.00 0:00.00 - 298 0.0 0:00.00 0:00.00 - 299 0.0 0:00.00 0:00.00 - 300 0.0 0:00.00 0:00.00 - 301 0.0 0:00.00 0:00.00 - 302 0.0 0:00.00 0:00.00 - 303 0.0 0:00.00 0:00.00 - 304 0.0 0:00.00 0:00.00 - 305 0.0 0:00.00 0:00.00 - 306 0.0 0:00.00 0:00.00 - 307 0.0 0:00.00 0:00.00 - 308 0.0 0:00.00 0:00.00 - 309 0.0 0:00.00 0:00.00 - 310 0.0 0:00.00 0:00.00 - 311 0.0 0:00.00 0:00.00 - 312 0.0 0:00.00 0:00.00 - 313 0.0 0:00.00 0:00.00 - 314 0.0 0:00.00 0:00.00 - 315 0.0 0:00.00 0:00.00 - 316 0.0 0:00.00 0:00.00 - 317 0.0 0:00.00 0:00.00 - 318 0.0 0:00.00 0:00.00 - 319 0.0 0:00.00 0:00.00 - 320 0.0 0:00.00 0:00.00 - 321 0.0 0:00.00 0:00.00 - 322 0.0 0:00.00 0:00.00 - 323 0.0 0:00.00 0:00.00 - 324 0.0 0:00.00 0:00.00 - 325 0.0 0:00.00 0:00.00 - 326 0.0 0:00.00 0:00.00 - 327 0.0 0:00.00 0:00.00 - 328 0.0 0:00.00 0:00.00 - 329 0.0 0:00.00 0:00.00 - 330 0.0 0:00.00 0:00.00 - 331 0.0 0:00.00 0:00.00 - 332 0.0 0:00.00 0:00.00 - 333 0.0 0:00.00 0:00.00 - 334 0.0 0:00.00 0:00.00 - 335 0.0 0:00.00 0:00.00 - 336 0.0 0:00.00 0:00.00 - 337 0.0 0:00.00 0:00.00 - 338 0.0 0:00.00 0:00.00 - 339 0.0 0:00.00 0:00.00 - 340 0.0 0:00.00 0:00.00 - 341 0.0 0:00.00 0:00.00 - 342 0.0 0:00.00 0:00.00 - 343 0.0 0:00.00 0:00.00 - 344 0.0 0:00.00 0:00.00 - 345 0.0 0:00.00 0:00.00 - 346 0.0 0:00.00 0:00.00 - 347 0.0 0:00.00 0:00.00 - 348 0.0 0:00.00 0:00.00 - 349 0.0 0:00.00 0:00.00 - 350 0.0 0:00.00 0:00.00 - 351 0.0 0:00.00 0:00.00 - 352 0.0 0:00.00 0:00.00 - 353 0.0 0:00.00 0:00.00 - 354 0.0 0:00.00 0:00.00 - 355 0.0 0:00.00 0:00.00 - 356 0.0 0:00.00 0:00.00 - 357 0.0 0:00.00 0:00.00 - 358 0.0 0:00.00 0:00.00 - 359 0.0 0:00.00 0:00.00 - 360 0.0 0:00.00 0:00.00 - 361 0.0 0:00.00 0:00.00 - 362 0.0 0:00.00 0:00.00 - 363 0.0 0:00.00 0:00.00 - 364 0.0 0:00.00 0:00.00 - 365 0.0 0:00.00 0:00.00 - 366 0.0 0:00.00 0:00.00 - 367 0.0 0:00.00 0:00.00 - 368 0.0 0:00.00 0:00.00 - 369 0.0 0:00.00 0:00.00 - 370 0.0 0:00.00 0:00.00 - 371 0.0 0:00.00 0:00.03 - 372 0.0 0:00.00 0:00.00 - 373 0.0 0:00.00 0:00.00 - 374 0.0 0:00.00 0:00.00 - 375 0.0 0:00.00 0:00.00 - 376 0.0 0:00.00 0:00.00 - 377 0.0 0:00.00 0:00.00 - 378 0.0 0:00.00 0:00.00 - 379 0.0 0:00.00 0:00.00 - 380 0.0 0:00.00 0:00.00 - 381 0.0 0:00.00 0:00.00 - 382 0.0 0:00.00 0:00.00 - 383 0.0 0:00.00 0:00.00 - 384 0.0 0:00.00 0:00.00 - 385 0.0 0:00.00 0:00.00 - 386 0.0 0:00.00 0:00.00 - 387 0.0 0:00.00 0:00.00 - 388 0.0 0:00.00 0:00.00 - 389 0.0 0:00.00 0:00.00 - 390 0.0 0:00.00 0:00.00 - 391 0.0 0:00.00 0:00.00 - 392 0.0 0:00.00 0:00.00 - 393 0.0 0:00.00 0:00.00 - 394 0.0 0:00.00 0:00.00 - 395 0.0 0:00.00 0:00.00 - 396 0.0 0:00.00 0:00.00 - 397 0.0 0:00.00 0:00.00 - 398 0.0 0:00.00 0:00.00 - 399 0.0 0:00.00 0:00.00 - 400 0.0 0:00.00 0:00.00 - 401 0.0 0:00.00 0:00.00 - 402 0.0 0:00.00 0:00.00 - 403 0.0 0:00.00 0:00.00 - 404 0.0 0:00.00 0:00.00 - 405 0.0 0:00.00 0:00.00 - 406 0.0 0:00.00 0:00.00 - 407 0.0 0:00.00 0:00.00 - 408 0.0 0:00.00 0:00.00 - 409 0.0 0:00.00 0:00.00 - 410 0.0 0:00.00 0:00.00 - 411 0.0 0:00.00 0:00.00 - 412 0.0 0:00.00 0:00.00 - 413 0.0 0:00.00 0:00.00 - 414 0.0 0:00.00 0:00.00 - 415 0.0 0:00.00 0:00.00 - 416 0.0 0:00.00 0:00.00 - 417 0.0 0:00.00 0:00.00 - 418 0.0 0:00.00 0:00.00 - 419 0.0 0:00.00 0:00.00 - 420 0.0 0:00.00 0:00.00 - 421 0.0 0:00.00 0:00.00 - 422 0.0 0:00.00 0:00.00 - 423 0.0 0:00.00 0:00.00 - 424 0.0 0:00.00 0:00.00 - 425 0.0 0:00.00 0:00.00 - 426 0.0 0:00.00 0:00.00 - 427 0.0 0:00.00 0:00.00 - 428 0.0 0:00.00 0:00.00 - 429 0.0 0:00.00 0:00.00 - 430 0.0 0:00.00 0:00.00 - 431 0.0 0:00.00 0:00.00 - 432 0.0 0:00.00 0:00.00 - 433 0.0 0:00.00 0:00.00 - 434 0.0 0:00.00 0:00.00 - 435 0.0 0:00.00 0:00.00 - 436 0.0 0:00.00 0:00.00 - 437 0.0 0:00.00 0:00.00 - 438 0.0 0:00.00 0:00.00 - 439 0.0 0:00.00 0:00.00 - 440 0.0 0:00.00 0:00.00 - 441 0.0 0:00.00 0:00.00 - 442 0.0 0:00.00 0:00.00 - 443 0.0 0:00.00 0:00.00 - 444 0.0 0:00.00 0:00.00 - 445 0.0 0:00.00 0:00.00 - 446 0.0 0:00.00 0:00.00 - 447 0.0 0:00.00 0:00.00 - 448 0.0 0:00.00 0:00.00 - 449 0.0 0:00.00 0:00.00 - 450 0.0 0:00.00 0:00.00 - 451 0.0 0:00.00 0:00.00 - 452 0.0 0:00.00 0:00.00 - 453 0.0 0:00.00 0:00.00 - 454 0.0 0:00.00 0:00.00 - 455 0.0 0:00.00 0:00.00 - 456 0.0 0:00.00 0:00.00 - 457 0.0 0:00.00 0:00.00 - 458 0.0 0:00.00 0:00.00 - 459 0.0 0:00.00 0:00.00 - 460 0.0 0:00.00 0:00.00 - 461 0.0 0:00.00 0:00.00 - 462 0.0 0:00.00 0:00.00 - 463 0.0 0:00.00 0:00.00 - 464 0.0 0:00.00 0:00.00 - 465 0.0 0:00.00 0:00.00 - 466 0.0 0:00.00 0:00.00 - 467 0.0 0:00.00 0:00.00 - 468 0.0 0:00.00 0:00.00 - 469 0.0 0:00.00 0:00.00 - 470 0.0 0:00.00 0:00.00 - 471 0.0 0:00.00 0:00.00 - 472 0.0 0:00.00 0:00.00 - 473 0.0 0:00.00 0:00.00 - 474 0.0 0:00.00 0:00.00 - 475 0.0 0:00.00 0:00.00 - 476 0.0 0:00.00 0:00.00 - 477 0.0 0:00.00 0:00.00 - 478 0.0 0:00.00 0:00.00 - 479 0.0 0:00.00 0:00.00 - 480 0.0 0:00.00 0:00.00 - 481 0.0 0:00.00 0:00.00 - 482 0.0 0:00.00 0:00.00 - 483 0.0 0:00.00 0:00.00 - 484 0.0 0:00.00 0:00.00 - 485 0.0 0:00.00 0:00.00 - 486 0.0 0:00.00 0:00.00 - 487 0.0 0:00.00 0:00.00 - 488 0.0 0:00.00 0:00.00 - 489 0.0 0:00.00 0:00.00 - 490 0.0 0:00.00 0:00.00 - 491 0.0 0:00.00 0:00.00 - 492 0.0 0:00.00 0:00.00 - 493 0.0 0:00.00 0:00.00 - 494 0.0 0:00.00 0:00.00 - 495 0.0 0:00.00 0:00.00 - 496 0.0 0:00.00 0:00.00 - 497 0.0 0:00.00 0:00.00 - 498 0.0 0:00.00 0:00.00 - 499 0.0 0:00.00 0:00.00 - 500 0.0 0:00.00 0:00.00 - 501 0.0 0:00.00 0:00.00 - 502 0.0 0:00.00 0:00.00 - 503 0.0 0:00.00 0:00.00 - 504 0.0 0:00.00 0:00.00 - 505 0.0 0:00.00 0:00.00 - 506 0.0 0:00.00 0:00.00 - 507 0.0 0:00.00 0:00.00 - 508 0.0 0:00.00 0:00.00 - 509 0.0 0:00.00 0:00.00 - 510 0.0 0:00.00 0:00.00 - 511 0.0 0:00.00 0:00.00 - 512 0.0 0:00.00 0:00.00 - 513 0.0 0:00.00 0:00.00 - 514 0.0 0:00.00 0:00.00 - 515 0.0 0:00.00 0:00.00 - 516 0.0 0:00.00 0:00.00 - 517 0.0 0:00.00 0:00.00 - 518 0.0 0:00.00 0:00.00 - 519 0.0 0:00.00 0:00.00 - 520 0.0 0:00.00 0:00.00 - 521 0.0 0:00.00 0:00.00 - 522 0.0 0:00.00 0:00.00 - 523 0.0 0:00.00 0:00.00 - 524 0.0 0:00.00 0:00.00 - 525 0.0 0:00.00 0:00.00 - 526 0.0 0:00.00 0:00.00 - 527 0.0 0:00.00 0:00.00 - 528 0.0 0:00.00 0:00.00 - 529 0.0 0:00.00 0:00.00 - 530 0.0 0:00.00 0:00.00 - 531 0.0 0:00.00 0:00.00 - 532 0.0 0:00.00 0:00.00 - 533 0.0 0:00.00 0:00.00 - 534 0.0 0:00.00 0:00.00 - 535 0.0 0:00.00 0:00.00 - 536 0.0 0:00.00 0:00.00 - 537 0.0 0:00.00 0:00.00 - 538 0.0 0:00.00 0:00.00 - 539 0.0 0:00.00 0:00.00 - 540 0.0 0:00.00 0:00.00 - 541 0.0 0:00.00 0:00.00 - 542 0.0 0:00.00 0:00.00 - 543 0.0 0:00.00 0:00.00 - 544 0.0 0:00.00 0:00.00 - 545 0.0 0:00.00 0:00.00 - 546 0.0 0:00.00 0:00.00 - 547 0.0 0:00.00 0:00.00 - 548 0.0 0:00.00 0:00.00 - 549 0.0 0:00.00 0:00.00 - 550 0.0 0:00.00 0:00.00 - 551 0.0 0:00.00 0:00.00 - 552 0.0 0:00.00 0:00.00 - 553 0.0 0:00.00 0:00.00 - 554 0.0 0:00.00 0:00.00 - 555 0.0 0:00.00 0:00.00 - 556 0.0 0:00.00 0:00.00 - 557 0.0 0:00.00 0:00.00 - 558 0.0 0:00.00 0:00.00 - 559 0.0 0:00.00 0:00.00 - 560 0.0 0:00.00 0:00.00 - 561 0.0 0:00.00 0:00.00 - 562 0.0 0:00.00 0:00.00 - 563 0.0 0:00.00 0:00.00 - 564 0.0 0:00.00 0:00.00 - 565 0.0 0:00.00 0:00.00 - 566 0.0 0:00.00 0:00.00 - 567 0.0 0:00.00 0:00.00 - 568 0.0 0:00.00 0:00.00 - 569 0.0 0:00.00 0:00.00 - 570 0.0 0:00.00 0:00.00 - 571 0.0 0:00.00 0:00.00 - 572 0.0 0:00.00 0:00.00 - 573 0.0 0:00.00 0:00.00 - 574 0.0 0:00.00 0:00.00 - 575 0.0 0:00.00 0:00.00 - 576 0.0 0:00.00 0:00.00 - 577 0.0 0:00.00 0:00.00 - 578 0.0 0:00.00 0:00.00 - 579 0.0 0:00.00 0:00.00 - 580 0.0 0:00.00 0:00.00 - 581 0.0 0:00.00 0:00.00 - 582 0.0 0:00.00 0:00.00 - 583 0.0 0:00.00 0:00.00 - 584 0.0 0:00.00 0:00.00 - 585 0.0 0:00.00 0:00.00 - 586 0.0 0:00.00 0:00.00 - 587 0.0 0:00.00 0:00.00 - 588 0.0 0:00.00 0:00.00 - 589 0.0 0:00.00 0:00.00 - 590 0.0 0:00.00 0:00.00 - 591 0.0 0:00.00 0:00.00 - 592 0.0 0:00.00 0:00.00 - 593 0.0 0:00.00 0:00.00 - 594 0.0 0:00.00 0:00.00 - 595 0.0 0:00.00 0:00.00 - 596 0.0 0:00.00 0:00.00 - 597 0.0 0:00.00 0:00.00 - 598 0.0 0:00.00 0:00.00 - 599 0.0 0:00.00 0:00.00 - 600 0.0 0:00.00 0:00.00 - 601 0.0 0:00.00 0:00.00 - 602 0.0 0:00.00 0:00.00 - 603 0.0 0:00.00 0:00.00 - 604 0.0 0:00.00 0:00.00 - 605 0.0 0:00.00 0:00.00 - 606 0.0 0:00.00 0:00.00 - 607 0.0 0:00.00 0:00.00 - 608 0.0 0:00.00 0:00.00 - 609 0.0 0:00.00 0:00.00 - 610 0.0 0:00.00 0:00.00 - 611 0.0 0:00.00 0:00.00 - 612 0.0 0:00.00 0:00.00 - 613 0.0 0:00.00 0:00.00 - 614 0.0 0:00.00 0:00.00 - 615 0.0 0:00.00 0:00.00 - 616 0.0 0:00.00 0:00.00 - 617 0.0 0:00.00 0:00.00 - 618 0.0 0:00.00 0:00.00 - 619 0.0 0:00.00 0:00.00 - 620 0.0 0:00.00 0:00.00 - 621 0.0 0:00.00 0:00.00 - 622 0.0 0:00.00 0:00.00 - 623 0.0 0:00.00 0:00.00 - 624 0.0 0:00.00 0:00.00 - 625 0.0 0:00.00 0:00.00 - 626 0.0 0:00.00 0:00.00 - 627 0.0 0:00.00 0:00.00 - 628 0.0 0:00.00 0:00.00 - 629 0.0 0:00.00 0:00.00 - 630 0.0 0:00.00 0:00.00 - 631 100.3 8:11.86 17:35.07 - 175 0 3 1 1 6 130M 1.08M 0.0 0:03.06 0:33.84 /hurd/term /dev/ptyp0 pty-master /dev/ttyp0 - 0 0.0 0:00.80 0:07.55 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.56 0:05.97 - 3 0.0 0:00.50 0:06.99 - 4 0.0 0:00.56 0:06.99 - 5 0.0 0:00.62 0:06.32 - 176 1000 173 176 176 2 148M 2.19M 0.0 0:00.08 0:00.54 -bash - 0 0.0 0:00.08 0:00.47 - 1 0.0 0:00.00 0:00.07 - 284 1000 1 284 284 2 20.5M 700K 0.0 0:00.00 0:00.00 ssh-agent - 0 0.0 0:00.00 0:00.00 - 1 0.0 0:00.00 0:00.00 - 302 1000 176 302 176 3 148M 1.37M 0.0 0:00.03 0:00.14 screen -S S_main - 0 0.0 0:00.02 0:00.07 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.01 0:00.06 - 304 1000 302 304 304 3 148M 2.45M 0.0 0:02.86 0:13.03 SCREEN -S S_main - 0 0.0 0:02.86 0:12.97 - 1 0.0 0:00.00 0:00.03 - 2 0.0 0:00.00 0:00.02 - 305 1000 3 1 1 5 130M 960K 0.0 0:01.57 0:15.62 /hurd/fifo - 0 0.0 0:00.31 0:04.04 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.31 0:03.95 - 3 0.0 0:00.45 0:03.78 - 4 0.0 0:00.49 0:03.84 - 306 0 3 1 1 5 130M 1.02M 0.0 0:01.42 0:16.72 /hurd/term /dev/ptyp1 pty-master /dev/ttyp1 - 0 0.0 0:00.43 0:06.13 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.40 0:04.77 - 3 0.0 0:00.00 0:00.14 - 4 0.0 0:00.59 0:05.67 - 309 1000 304 309 309 2 148M 2.12M 0.0 0:00.02 0:00.09 /bin/bash - 0 0.0 0:00.02 0:00.09 - 1 0.0 0:00.00 0:00.00 - 319 1000 309 319 309 2 153M 7.29M 0.0 0:00.33 0:00.74 emacs - 0 0.0 0:00.33 0:00.74 - 1 0.0 0:00.00 0:00.00 - 320 0 3 1 1 6 130M 1.48M 0.0 0:03.25 0:38.79 /hurd/term /dev/ptyp2 pty-master /dev/ttyp2 - 0 0.0 0:00.60 0:07.07 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.69 0:08.43 - 3 0.0 0:00.78 0:07.78 - 4 0.0 0:00.55 0:07.98 - 5 0.0 0:00.60 0:07.52 - 323 1000 304 323 323 2 148M 2.19M 0.0 0:00.12 0:00.60 /bin/bash - 0 0.0 0:00.12 0:00.54 - 1 0.0 0:00.00 0:00.06 - 411 0 3 1 1 5 130M 1.02M 0.0 0:01.17 0:16.40 /hurd/term /dev/ptyp3 pty-master /dev/ttyp3 - 0 0.0 0:00.42 0:03.74 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.15 0:02.70 - 3 0.0 0:00.24 0:05.48 - 4 0.0 0:00.33 0:04.45 - 414 1000 304 414 414 2 148M 2.13M 0.0 0:00.05 0:00.23 /bin/bash - 0 0.0 0:00.04 0:00.21 - 1 0.0 0:00.00 0:00.02 - 425 0 3 1 1 3 130M 872K 0.0 0:00.02 0:00.05 /hurd/proxy-defpager - 0 0.0 0:00.02 0:00.04 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.00 0:00.01 - 3087 0 3 1 1 5 130M 1.02M 0.0 0:00.23 0:01.39 /hurd/term /dev/ptyp4 pty-master /dev/ttyp4 - 0 0.0 0:00.05 0:00.39 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.07 0:00.43 - 3 0.0 0:00.07 0:00.31 - 4 0.0 0:00.04 0:00.26 - 3648 0 3 1 1 3 130M 876K 0.0 0:00.00 0:00.05 /hurd/crash --kill - 0 0.0 0:00.00 0:00.05 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.00 0:00.00 - 5512 0 3 1 1 5 130M 1.01M 0.0 0:00.05 0:00.70 /hurd/term /dev/ptyp5 pty-master /dev/ttyp5 - 0 0.0 0:00.00 0:00.26 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.03 0:00.16 - 3 0.0 0:00.02 0:00.14 - 4 0.0 0:00.00 0:00.14 - 10286 1000 323 10286 323 2 135M 1.28M 0.0 0:00.06 0:00.20 make - 0 0.0 0:00.06 0:00.20 - 1 0.0 0:00.00 0:00.00 - 10287 1000 323 10286 323 2 147M 884K 0.0 0:00.00 0:00.33 tee standard output L_ LC_PAPER=en_US.utf8 LC_ADDRESS=en_US.utf8 SSH_AGENT_PID=284 LC_MONETARY= - [165CM=en_US.utf8 SP_REPLACE_LINKS=n SHELL=/bin/bash TERM=screen SP_STOP_AFTER=build HISTSIZE=10000 SSH_CLIENT=192.168.10.60 55972 22 LC_NUMERIC=en_US.utf8 OLDPWD=/home/tsch - [165CMhwinge SSH_TTY=/dev/ttyp0 USER=tschwinge HISTFILESIZE=10000 LD_LIBRARY_PATH= LC_TELEPHONE=en_US.utf8 SP_COMPAT=n LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01; - [165CM;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=0 - [165CM01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lz=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31: - [165CM:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35 - [165CM5:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=0 - [165CM01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm - [165CMm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.an - [165CMnx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*. - [165CM.axa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36: SSH_AUTH_SOCK=/home/tschwinge/.ssh/auth_sock.grubber.bddebian.com TERMCAP=SC|screen|VT 100/ANSI X3.64 virtual terminal - [165CMl:\^K^J:DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:bs:bt=\E[Z:\^K^J:cd=\E[J:ce=\E[K:cl=\E[H\E[J:cm=\E[%i%d;%dH:ct=\E[3g:\^K^J:do=^J:nd=\E[C:pt:rc=\E8:rs=\Ec:sc=\E7:st=\EH - [165CMH:up=\EM:\^K^J:le=^H:bl=^G:cr=^M:it#8:ho=\E[H:nw=\EE:ta=^I:is=\E)0:\^K^J:li#50:co#166:am:xn:xv:LP:sr=\EM:al=\E[L:AL=\E[%dL:\^K^J:cs=\E[%i%d;%dr:dl=\E[M:DL=\E[%dM:dc=\E - [165CME[P:DC=\E[%dP:\^K^J:im=\E[4h:ei=\E[4l:mi:IC=\E[%d@:ks=\E[?1h\E=:\^K^J:ke=\E[?1l\E>:vi=\E[?25l:ve=\E[34h\E[?25h:vs=\E[34l:\^K^J:ti=\E[?1049h:te=\E[?1049l:us=\E[4m:ue=\E - [165CME[24m:so=\E[3m:\^K^J:se=\E[23m:mb=\E[5m:md=\E[1m:mr=\E[7m:me=\E[m:ms:\^K^J:Co#8:pa#64:AF=\E[3%dm:AB=\E[4%dm:op=\E[39;49m:AX:\^K^J:vb=\Eg:G0:as=\E(0:ae=\E(B:\^K^J:ac=\1 - [165CM140\140aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~..--++,,hhII00:\^K^J:po=\E[5i:pf=\E[4i:k0=\E[10~:k1=\EOP:k2=\EOQ:k3=\EOR:\^K^J:k4=\EOS:k5=\E[15~:k6=\E[17~:k7=\E - [165CME[18~:k8=\E[19~:\^K^J:k9=\E[20~:k;=\E[21~:F1=\E[23~:F2=\E[24~:F3=\E[1;2P:\^K^J:F4=\E[1;2Q:F5=\E[1;2R:F6=\E[1;2S:F7=\E[15;2~:\^K^J:F8=\E[17;2~:F9=\E[18;2~:FA=\E[19;2~:k - [165CMkb=\177:K2=\EOE:\^K^J:kB=\E[Z:kF=\E[1;2B:kR=\E[1;2A:*4=\E[3;2~:*7=\E[1;2F:\^K^J:#2=\E[1;2H:#3=\E[2;2~:#4=\E[1;2D:%c=\E[6;2~:%e=\E[5;2~:\^K^J:%i=\E[1;2C:kh=\E[1~:@1=\E[ - [165CM[1~:kH=\E[4~:@7=\E[4~:\^K^J:kN=\E[6~:kP=\E[5~:kI=\E[2~:kD=\E[3~:ku=\EOA:kd=\EOB:\^K^J:kr=\EOC:kl=\EOD:km: have_bash_profile=y SPF_SOURCE_DEBUG=y PATH=/home/tschwinge/c - [165CMcommand:/home/tschwinge/shared/command:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games MAIL=/var/mail/tschwinge LC_MESSAGES=en_US.utf8 SP_TARDIR=/ - [165CM/home/tschwinge/tmp/source/package STY=304.S_main LC_COLLATE=C LC_IDENTIFICATION=en_US.utf8 SP_FOREIGN_DIR=/home/tschwinge/shared.old/package/host/schwinge.homeip.net/ - [165CM/sp-foreign-snippets/snippets PWD=/home/tschwinge/tmp/emacs/trunk.build _LD_LIBRARY_PATH= EDITOR=emacsclient LANG=en_US.utf8 TZ=Europe/Berlin LC_MEASUREMENT=en_US.utf - [165CMf8 KRB5CCNAME=/tmp/krb5cc.tschwinge HISTCONTROL=ignoreboth HOME=/home/tschwinge SHLVL=2 SPF_COMPAT=n LOGNAME=tschwinge LESS=-M -R CVS_RSH=ssh WINDOW=1 SSH_CONNECTION=1 - [165CM192.168.10.60 55972 192.168.10.63 22 LC_CTYPE=en_US.utf8 LESSOPEN=| /usr/bin/lesspipe %s EMAIL=thomas@schwinge.name ALTERNATE_EDITOR=joe LC_TIME=en_US.utf8 LESSCLOSE=/ - [165CM/usr/bin/lesspipe %s %s SPF_SOURCE_DATA_DIR=/home/tschwinge/shared.old/source/package/misc/spf LC_NAME=en_US.utf8 _=/usr/bin/tee - 0 0.0 0:00.00 0:00.33 - 1 0.0 0:00.00 0:00.00 - 10377 1000 10286 10286 323 2 146M 828K 0.0 0:00.00 0:00.00 /bin/sh -c boot=bootstrap-emacs; \^Kif [ ! -x "src/$boot" ]; then - [165CM \^K cd src; make all \^K CC='gcc' CFLAGS='-g' CPPFLAGS='-DXASSERTS=1' \^K LDFLA - [165CMAGS='-Wl,-znocombreloc ' MAKE='make' BOOTSTRAPEMACS="$boot"; \^Kfi; - 0 0.0 0:00.00 0:00.00 - 1 0.0 0:00.00 0:00.00 - 10378 1000 10377 10286 323 2 135M 1.65M 0.0 0:00.71 0:02.12 make all CC=gcc CFLAGS=-g CPPFLAGS=-DXASSERTS=1 LDFLAGS=-Wl,-znocombreloc MAKE=make BOOTSTRAPE - [165CMEMACS=bootstrap-emacs - 0 0.0 0:00.71 0:01.92 - 1 0.0 0:00.00 0:00.19 - 10770 1000 10378 10286 323 2 146M 852K 0.0 0:00.00 0:00.03 /bin/sh -c if test "no" = "yes"; then \^K ln -f temacs bootstrap-emacs; \^Kelse \^K `/bin/pwd - [165CMd`/temacs --batch --load loadup bootstrap || exit 1; \^K mv -f emacs bootstrap-emacs; \^Kfi - 0 0.0 0:00.00 0:00.03 - 1 0.0 0:00.00 0:00.00 - 10772 1000 10770 10286 323 3 180M 38.8M 0.0 1:16.35 0:05.27 /media/data/home/tschwinge/tmp/emacs/trunk.build/src/temacs --batch --load loadup bootstrap - 0 0.0 1:16.35 0:05.27 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.00 0:00.00 - 10778 1000 304 304 304 2 148M 396K 0.0 0:00.00 0:00.00 SCREEN -S S_main - 0 0.0 0:00.00 0:00.00 - 1 0.0 0:00.00 0:00.00 - 10784 - 160 10784 160 2 146M 672K 0.0 0:00.00 0:00.01 syncfs -s - 0 0.0 0:00.00 0:00.01 - 1 0.0 0:00.00 0:00.00 - 10785 - 160 10785 160 2 146M 672K 0.0 0:00.00 0:00.02 syncfs -s -c /media/data/ - 0 0.0 0:00.00 0:00.02 - 1 0.0 0:00.00 0:00.00 - 10787 0 160 10787 160 2 146M 876K 0.0 0:00.00 0:00.06 ps -Af - 0 0.0 0:00.00 0:00.06 - 1 0.0 0:00.00 0:00.00 - 10795 8 131 6 6 2 147M 1.38M 0.1 0:00.02 0:00.04 /usr/lib/nullmailer/qmqp -d -s mail.schwinge.homeip.net - 0 0.1 0:00.02 0:00.04 - 1 0.0 0:00.00 0:00.00 - 10796 0 160 10796 160 2 146M 1.23M 0.0 0:00.00 0:00.08 ps -F hurd-long -T -M -w -A - 0 0.0 0:00.00 0:00.03 - 1 0.0 0:00.00 0:00.00 - - [4]+ Done ps -F hurd-long -T -M -w -A - login> - -TH# 631 of PID 174 (which is indeed ext2fs for /media/data) looks very -suspicious, likely together in combination with TH# 1 of PID 2 (GNU Mach), so -likely some IPC ping-pong? - - PID TH# UID PPID PGrp Sess TH Vmem RSS %CPU User System Args - 0 0 1 1 1 16 132M 1M 0.0 0:04.84 0:54.84 /hurd/proc - [...] - 2 - 1 1 1 7 418M 19.5M 0.0 0:00.00 0:12.16 root=device:hd0 - 0 0.0 0:00.00 0:00.00 - 1 92.6 0:00.00 46:33.66 - 2 0.0 0:00.00 0:12.07 - 3 0.0 0:00.00 0:00.05 - 4 0.0 0:00.00 0:00.02 - 5 0.0 0:00.00 0:00.00 - 6 0.0 0:00.00 0:00.01 - [...] - 174 0 3 1 1 632 2.99G 27.6M 100.3 16:43.18 52:54.41 /hurd/ext2fs /dev/hd2 - 0 0.0 0:00.01 0:00.03 - 1 0.0 0:00.00 0:00.00 - 2 0.0 1:34.24 6:26.66 - 3 0.0 0:00.04 0:00.31 - [...] - 630 0.0 0:00.00 0:00.00 - 631 100.3 8:11.86 17:35.07 - [...] - -Attaching GDB hangs. Should have used noninvasive mode... - -Having a look again after an hour or two, GNU Mach's thread 1's (system) time -count has gone up to nearly 120 minutes, and ext2fs' thread 631's is up to 12 -minutes user and 26 minutes system time. - -I was able to get another root shell via plain `ssh root@grubber`, and I'm able -to attach GDB in noninvasive mode. Hopefully the first unsuccessful (but still -running) GDB didn't cause any interference. - -Due to differences in [[thread_numbering_of_ps_and_gdb]], GDB's thread 632 -(which is the last one anyways) should be the offending one. GDB's thread 631 -and earlier ones (manually checked down to 600) are sitting in `mach_msg_trap`. - - (gdb) thread apply 632 bt - - Thread 632 (Thread 174.632): - #0 0x010e408c in syscall_vm_allocate () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/syscall_vm_allocate.S:2 - #1 0x010e423a in __vm_allocate (target_task=1, address=0xbfffbde0, size=65536, anywhere=0) - at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/vm_allocate.c:54 - #2 0x010b023a in alloc_stack (p=0x83774a8) at /home/sthibaul-guest/hurd-debian/./libthreads/stack.c:397 - #3 0x010ae9b3 in cproc_create () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:724 - #4 0x010afe5a in cthread_fork (func=0x133ff42, arg=0x0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:341 - #5 0x010b505d in internal_demuxer (inp=0xbfffdf20, outheadp=0xbfffbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:72 - #6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109 - #7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 - #8 0x010b0058 in cthread_body (self=0x8376c50) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 - #9 0x00000000 in ?? () - - (gdb) thread apply 632 bt full - - Thread 632 (Thread 174.632): - #0 0x010e408c in syscall_vm_allocate () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/syscall_vm_allocate.S:2 - No locals. - #1 0x010e423a in __vm_allocate (target_task=1, address=0xbfffbde0, size=65536, anywhere=0) - at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/vm_allocate.c:54 - err = <value optimized out> - #2 0x010b023a in alloc_stack (p=0x83774a8) at /home/sthibaul-guest/hurd-debian/./libthreads/stack.c:397 - base = 321454080 - #3 0x010ae9b3 in cproc_create () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:724 - child = 0x83774a8 - n = <value optimized out> - #4 0x010afe5a in cthread_fork (func=0x133ff42, arg=0x0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:341 - t = 0x8377430 - #5 0x010b505d in internal_demuxer (inp=0xbfffdf20, outheadp=0xbfffbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:72 - status = <value optimized out> - pi = 0x0 - link = {thread = 2050, next = 0x0, prevp = 0x2000, notifies = 0x12, interrupted_next = 0x0} - __PRETTY_FUNCTION__ = "internal_demuxer" - lock = -1073758644 - nreqthreads = -1073750240 - totalthreads = 137852072 - bucket = 0x10b1c64 - demuxer = 0x10b01eb <alloc_stack+11> - #6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109 - request = 0xbfffdf20 - reply = 0xbfffbf10 - mr = 3 - __PRETTY_FUNCTION__ = "__mach_msg_server_timeout" - #7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 - timeout = 0 - err = <value optimized out> - hook = 0 - global_timeout = 0 - thread_timeout = 0 - bucket = 0x805f6c0 - lock = 0 - totalthreads = 497 - nreqthreads = 1 - #8 0x010b0058 in cthread_body (self=0x8376c50) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 - t = 0x8376bd8 - #9 0x00000000 in ?? () - No symbol table info available. - -May this simply be an out-of-memory situation where Mach won't / can't satisfy -libports / libthreads demand? (Looks like the latter library is currently -creating a new thread.) If yes, should the code be prepared for that? Is it -perhaps prepared (I did not yet have a look), and re-tries again and again? -Why doesn't Mach page out some pages to make memory available? +# 2024-01-14 -This is stock GNU Mach from Git, no patches, configured for Xen domU usage. +Emacs version 29.1 runs on Debian GNU/Hurd. Joshua Branson uses it in +X without issue. He use org-mode, gnus, erc, calc, markdown-mode, etc. +In fact he, edits this wiki via Debian GNU/Hurd (running on a T43) +using Emacs. He is able to make changes to the wiki, render the wiki, +look at the resulting webpage with the +[[netsurf|https://www.netsurf-browser.org/]] web browser, commit the +changes, and send a patch to `bug-hurd@gnu.org`, all while using the +Hurd. :) +Also since the Hurd ported rust, you can now use +[[treesitter|https://www.masteringemacs.org/article/how-to-get-started-tree-sitter]] +with Emacs! Joshua got +[[html-ts-mode|https://github.com/mickeynp/html-ts-mode]] working. -# IRC, freenode, #hurd, 2013-10-04 - <pinotree> given you are an emacs user: could you please pick the build - patch from deb#725099, recompile emacs24 and test it with your daily - work? +You can easily install many Emacs packages with apt: + # apt install elpa-zenburn-theme -## IRC, freenode, #hurd, 2013-10-07 +Or you can use `use-package`. - <gnu_srs> Wow! emacs24 runs in X:-D - <gnu_srs> pinotree: I've now built and installed emacs 24.3. So far so good - ^ - <pinotree> good, keep testing and stressing diff --git a/open_issues/exec.mdwn b/open_issues/exec.mdwn deleted file mode 100644 index 05deaa7a..00000000 --- a/open_issues/exec.mdwn +++ /dev/null @@ -1,84 +0,0 @@ -[[!meta copyright="Copyright © 2010, 2013 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled [[GNU Free Documentation -License|/fdl]]."]]"""]] - -[[!tag open_issue_hurd]] - -[[!toc]] - - -# IRC, unknown channel, unknown date. - - <youpi> oh my, disabling gzip/bzip2 support makes apt preconfigure hang - <youpi> support in exec* I meant - - <youpi> now a funny bug: if I disable gzip/bzip2 support from exec - <youpi> trying to run a zero-byte file hangs - -Justus: This doesn't seem to be an issue anymore (2013-09-08): - - % touch empty - % chmod +x empty - % ./empty - zsh: exec format error: ./empty - % bash - $ ./empty - $ - -Also I've never encountered a problem with apt. - - -## IRC, freenode, #hurd, 2013-08-01 - - <teythoon> uh, all the non trivial exec server code has #ifdef'd BFD code - all over it and it looks like that isn't even used anymore - <teythoon> that's too bad actually, I figured out how to get the values - from BFD, not so for the other elf parser that is used instead - - -## IRC, freenode, #hurd, 2013-08-05 - - <teythoon> btw, there is a Debian bug concerning zipped executables. now - I'm not sure if I understood the problem, but gziped and bzip2ed - executables work for me - <teythoon> (not that I'm a big fan of that particular feature) - <youpi> iirc these somehow got fixed yes - <youpi> something like a previous out of bound access - <teythoon> the exec server contains lot's of code that is unused and - probably bit rot (#ifdef BFD) or otherwise ignored (#if 0) - <youpi> yes :/ - <teythoon> and there's gunzipping and bunzip2ing, which we probably don't - want anyway - <pinotree> why not? - <teythoon> we should strip all that from exec and start adding features - <teythoon> pinotree: b/c it's slow and the gain is questionable - <teythoon> it breaks mmapping the code in - <teythoon> exec/exec.c is huge (~2300 lines) and complex and it is an - essential server - <teythoon> and I wonder if the unzipping is done securely, e. g. if it's - not possible to crash exec with an maliciously compressed executable - - -## IRC, freenode, #hurd, 2013-09-12 - - <rekado> The zip code in hurd/exec/ looks really complicated; does it - really just unpack zipped files in memory (which could be replaced by - library calls) or is there something else going on? - <braunr> rekado: - http://lists.gnu.org/archive/html/bug-hurd/2013-08/msg00049.html - <rekado> braunr: interesting. Thanks. - <rekado> Does this mean that the "small hack entry" on the contributing - page to use libz and libbz2 in exec is no longer valid? - <braunr> probably - ---- - -May want to have a look at using BFD / libiberty/simpleobject. - -Justus: The BFD code has been removed from the exec server. diff --git a/open_issues/exec_memory_leaks.mdwn b/open_issues/exec_memory_leaks.mdwn deleted file mode 100644 index 1fc5a928..00000000 --- a/open_issues/exec_memory_leaks.mdwn +++ /dev/null @@ -1,121 +0,0 @@ -[[!meta copyright="Copyright © 2012, 2013 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled [[GNU Free Documentation -License|/fdl]]."]]"""]] - -[[!tag open_issue_hurd]] - -There are is some memory leak in [[`exec`|hurd/translator/exec]]. - -[[!toc]] - - -# IRC, freenode, #hurd, 2012-08-11 - - <braunr> the exec servers seems to leak a lot - <braunr> server* - <braunr> exec now uses 109M on darnassus - <braunr> it really leaks a lot - <pinotree> only 109mb? few months ago, exec on exodar was taking more than - 200mb after few days of uptime with builds done - <braunr> i wonder how much it takes on the buildds - - -## IRC, freenode, #hurd, 2012-08-17 - - <braunr> the exec leak is tricky - <braunr> bddebian: btw, look at the TODO file in the hurd source code - <braunr> bddebian: there is a not from thomas bushnell about that - <braunr> "*** Handle dead name notifications on execserver ports. ! - <braunr> not sure it's still a todo item, but it might be worth checking - <bddebian> braunr: diskfs_execboot_class = ports_create_class (0, 0); - This is what would need to change right? It should call some cleanup - routine in the first argument? - <bddebian> Would be ideal if it could just use deadboot() from exec. - <braunr> bddebian: possible - <braunr> bddebian: hum execboot, i'm not so sure - <bddebian> Execboot is the exec task, no? - <braunr> i don't know what execboot is - <bddebian> It's from libdiskfs - <braunr> but "diskfs_execboot_class" looks like a class of ports used at - startup only - <braunr> ah - <braunr> then it's something run in the diskfs users ? - <bddebian> yes - <braunr> the leak is in exec - <braunr> if clients misbehave, it shouldn't affect that server - <bddebian> That's a different issue, this was about the TODO thing - <braunr> ah - <braunr> i don't know - <bddebian> Me either :) - <bddebian> For the leak I'm still focusing on do-bunzip2 but I am baffled - at my results.. - <braunr> ? - <bddebian> Where my counters are zero if I always increment on different - vars but wild freaking numbers if I increment on malloc and decrement on - free - - -# 2012-11-25 - -After twelve hours worth of `fork/exec` ([[GCC]]'s `check-c` part of the -testsuite), we got: - - PID UID PPID PGrp Sess TH Vmem RSS %CPU User System Args - 4 0 3 1 1 10 392M 262M 0.0 2:18.29 2hrs /hurd/exec - -The *RSS* seems a tad high. Also the system part of CPU time consumption is -quite noticeable. In comparison: - - 0 0 1 1 1 19 131M 1.14M 0.0 3:30.25 9:17.79 /hurd/proc - 3 0 1 1 1 224 405M 12.6M 0.2 42:20.25 67min ext2fs --readonly --multiboot-command-line=root=device:hd0s6 --host-priv-port=1 --device-master-port=2 --exec-server-task=3 -T typed device:hd0s6 - 276 0 3 1 1 344 442M 28.2M 0.6 48:09.36 91min /hurd/ext2fs /dev/hd2s5 - - -# 2012-12-20 - -After running the libtool testsuite for some time: - - PID TH# UID PPID PGrp Sess TH Vmem RSS %CPU User System Args - 4 0 3 1 1 11 334M 203M 60.8 3:19.73 4hrs /hurd/exec - 0 0.0 0:20.33 27:02.47 - 1 0.0 0:31.10 32:21.13 - 2 0.0 0:25.68 27:42.33 - 3 0.0 0:00.00 0:00.00 - 4 5.1 0:34.93 34:07.59 - 5 0.0 0:19.56 28:44.15 - 6 3.4 0:18.73 28:17.89 - 7 0.0 0:20.47 34:42.51 - 8 39.5 0:15.60 28:48.57 - 9 0.0 0:04.49 10:24.12 - 10 12.8 0:08.84 19:34.45 - - -# IRC, freenode, #hurd, 2013-10-08 - - * braunr hunting the exec leak - <braunr> and i think i found it - <braunr> yes :> - <braunr> testing a bit more and committing the fix later tonight - <braunr> pinotree: i've been building glibc for 40 mins and exec is still - consuming around 1m memory - <pinotree> wow nice - <pinotree> i've been noticing exec leaking quite some time ago, then forgot - to pay more attention to that - <braunr> it's been more annoying since darnassus provides web access to - cgis - <braunr> automated tools make requests every seconds - <braunr> the leak occurred when starting a shell script or using system() - <braunr> youpi: not sure you saw it, i fixed the exec leak - - -## IRC, freenode, #hurd, 2013-10-10 - - <gg0> braunr: http://postimg.org/image/jd764wfpp/ - <braunr> exec 797M - <braunr> this should be fixed with the release of the next hurd packages diff --git a/open_issues/faccessat/faccessat.c b/open_issues/faccessat/faccessat.c deleted file mode 100644 index 24b1233c..00000000 --- a/open_issues/faccessat/faccessat.c +++ /dev/null @@ -1,26 +0,0 @@ -#include <fcntl.h> -#include <unistd.h> -#include <stdio.h> -#include <errno.h> -#include <string.h> -#include <stdlib.h> - -#define TESTFN "faccessat-test-file" - -int main() -{ - int fd; - int ret; - - system("touch " TESTFN ); - fd = open(".", O_RDONLY); - printf("> open: %d\n", fd); - - errno = 0; - ret = faccessat(fd, TESTFN, R_OK, 0); - printf("> faccessat: %d, %d (%s)\n", ret, errno, strerror(errno)); - - close(fd); - - return 0; -} diff --git a/open_issues/glibc/mremap.mdwn b/open_issues/glibc/mremap.mdwn deleted file mode 100644 index c17506d7..00000000 --- a/open_issues/glibc/mremap.mdwn +++ /dev/null @@ -1,70 +0,0 @@ -[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled [[GNU Free Documentation -License|/fdl]]."]]"""]] - -[[!tag open_issue_glibc]] - -The Hurd does not currently support the `mremap` function. - -For the `MREMAP_MAYMOVE` case it is easy to work around; see -`[binutils]/gold/mremap.c`, for example. - -Also see the discussion of [[glibc/mmap]]. - -[[!toc]] - - -# IRC, freenode, #hurd, 2011-01-12 - - <antrik> maybe it would be easiest actually to implement mremap()?... - <braunr> antrik: i'm nto sure - <braunr> antrik: implementing mremap could be relatively easy to do - actually - <braunr> antrik: IIRC, vm_map() supports overlapping - <antrik> braunr: yes, I think so too - <antrik> braunr: haven't checked, but I have a vague recollection that the - fundamentals are pretty much there - -[[!taglink open_issue_glibc]]: check if it is possible to implement `mremap`. -[[I|tschwinge]] remember some discussion about this, but have not yet worked on -locating it. [[Talk to me|tschwinge]] if you'd like to have a look at this. - - -# IRC, OFTC, #debian-hurd, 2012-06-19 - - <bdefreese> OK, how the heck do you get an undefined reference to mremap? - <youpi> simply because we don't have it - <pinotree> mremap exists only on linux - <bdefreese> It's in sys/mman.h - <pinotree> on linux? - <bdefreese> No, on GNU/Hurd - <bdefreese> /usr/include/i386-gnu/sys/mman.h - <youpi> that's just the common file with linux - <youpi> containing just the prototype - <youpi> that doesn't mean there's an implementation behind - <pinotree> youpi: hm no, linux has an own version - <youpi> uh - <bdefreese> Ah, aye, I didn't look at the implementation.. :( - <youpi> it's then odd that it was added to the generic sys/mman.h :) - <bdefreese> Just another stub? - <pinotree> ah, only few linux archs have own versions - <youpi> for the macro values I guess - <pinotree> http://paste.debian.net/175173/ on glibc/master - <bdefreese> Hmm, so where is MREMAP_MAYMOVE coming in from? - <youpi> rgrep on a linux box ;) - <youpi> <bits/mman.h> - <youpi> but that's again linuxish - <bdefreese> Aye but with us having that in the header it is causing some - code to be run which utilizes mremap. If that wasn't defined we wouldn't - be calling it. - <youpi> ah - <youpi> we could try to remove it indeed - <bdefreese> Should I change the code to #ifdef MREMAP_MAYMOVE & !defined - __GNU__? - <youpi> no, I said we could remove the definition of MREMAP_MAYMOVE itself diff --git a/open_issues/glibc_madvise_vs_static_linking.mdwn b/open_issues/glibc_madvise_vs_static_linking.mdwn deleted file mode 100644 index 4af41931..00000000 --- a/open_issues/glibc_madvise_vs_static_linking.mdwn +++ /dev/null @@ -1,48 +0,0 @@ -[[!meta copyright="Copyright © 2010, 2011, 2012, 2013 Free Software Foundation, -Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled [[GNU Free Documentation -License|/fdl]]."]]"""]] - -[[!tag open_issue_glibc]] - -[[!sourceware_PR 4822]]. - - $ echo 'int main() {}' | gcc -o /dev/null -static -x c - - /usr/lib/gcc/i486-gnu/4.4.5/../../../libcrt.a(malloc.o): In function `_int_free': - (.text+0xdc3): warning: warning: madvise is not implemented and will always fail - -This is correct, but it does confuse GNU Autoconf, for example, which then -thinks that static linking is not supported and sets a flag accordingly, which -luckly no / not many packages use. - -*This call does not influence the semantics of the application (except in the -case of MADV_DONTNEED), but may influence its performance. The kernel is free -to ignore the advice.* (`man madvise`), so we may simply want to turn it into a -no-op in glibc, avoiding the link-time warning. - -GCC c5db973fdab3db3e13db575e5650c0bcfd3630f4 (2011-10-17) makes use of this. -As we now export the symbol (and `MADV_DONTNEED`, too), GCC will no longer -`munmap` pages, but will keep them mapped for later re-use. This may increase -memory usage. The discussion in [[!message-id -"20120720162519.734e02eb@spoyarek"]] touches related topics. - -2011-07: This is what Samuel has [done for Debian -glibc](http://anonscm.debian.org/viewvc/pkg-glibc/glibc-package/trunk/debian/patches/hurd-i386/local-madvise_warn.diff). - - -# IRC, freenode, #hurd, 2012-02-16 - - <tschwinge> youpi: With Roland's fix the situation will be that just using - gcc -static doesn't emit the stub warning, but still will do so in case - that the source code itself links in madvise. Is this acceptable for - you/Debian/...? - <youpi> packages with -Werror will still bug out - <youpi> not that I consider -Werror to be a good idea, though :) - <tschwinge> youpi: Indeed. Compiler warnings can be caused by all kinds of - things. -Werror is good for development, but not for releases. diff --git a/open_issues/gnumach_i686.mdwn b/open_issues/gnumach_i686.mdwn deleted file mode 100644 index b34df73b..00000000 --- a/open_issues/gnumach_i686.mdwn +++ /dev/null @@ -1,26 +0,0 @@ -[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled [[GNU Free Documentation -License|/fdl]]."]]"""]] - -[[!tag open_issue_gnumach]] - - -# IRC, freenode, #hurd, 2012-07-05 - - <braunr> we could use a gnumach-i686 too - <pinotree> how would you compile gnumach as i686 variant btw? add - -march=.. or something like that in CFLAGS? - <braunr> yes - <braunr> at least we'll get some cmovs :) - - -## IRC, freenode, #hurd, 2012-07-07 - - <braunr> it was rejected in the past because we didn't think it would bring - real performance benefit, but it actually may diff --git a/open_issues/gnumach_vm_map_entry_forward_merging.mdwn b/open_issues/gnumach_vm_map_entry_forward_merging.mdwn index 7739f4d1..b34bd61e 100644 --- a/open_issues/gnumach_vm_map_entry_forward_merging.mdwn +++ b/open_issues/gnumach_vm_map_entry_forward_merging.mdwn @@ -10,6 +10,193 @@ License|/fdl]]."]]"""]] [[!tag open_issue_gnumach]] +Mach is not always able to merge/coalesce mappings (VM entries) that +are made next to each other, leading to potentially very large numbers +of VM entries, which may slow down the VM functionality. This is said +to particularly affect ext2fs and bash. + +The basic idea of Mach designers is that entry coalescing is only an +optimization anyway, not a hard guarantee. We can apply it in the +common simple case, and just refuse to do it in any remotely complex +cases (copies, shadows, multiply referenced objects, pageout in +progress, ...). + +Suppose you define a special test program that intentionally maps +parts of a file next to each other and watches the resulting VM map +entries, and just ran a full Hurd system and observed results. + +One can stress test ext2fs in particular to check for VM entry +merging: + + # grep NR -r /usr &> /dev/null + # vminfo 8 | wc -l + +That grep opens and reads lots of files to simulate a long-running +machine (perhaps a build server); then one can look at the number of +mappings in ext2fs afterwards. Depending on how much your /usr is +populated, you will get different numbers. An older Hurd from say +2022, the above comand would result in 5,000-20,000 entries depending +on the machine! In June 2023, GNUMach gained some forward merging +functinality, which lowered the number of mappings down to 93 entries! + +(It is a separate question of why ext2fs makes that many mappings in +the first place. There could possible by a leak in ext2fs that would +be responsible for this, but none have been found so far. Possibly +another problem is that we have an unbounded node cache in libdiskfs +and Mach caching VM objects, which also keeps the node alive.) + +These are the simple forward merging cases that GNUMach now supports: + +- Forward merging: in `vm_map_enter`, merging with the next entry, in + addition to merging with the previous entry that was already there; + +- For forward merging, a `VM_OBJECT_NULL` can be merged in front of a + non-null VM object, provided the second entry has large enough + offset into the object to 'mount' the the first entry in front of + it; + +- A VM object can always be merged with itself (provded offsets/sizes + match) -- this allows merging entries referencing non-anonymous VM + objects too, such a file mappings; + +- Operations such as `vm_protect` do "clipping", which means splitting + up VM map entries, in case the specified region lands in the middle + of an entry -- but they were never "gluing" (merging, coalescing) + entries back together if the region is later vm_protect'ed back. Now + this is done (and we try to coalesce in some other cases too). This + should particularly help with "program break" (brk) in glibc, which + vm_protect's the pages allocated for the brk back and forth all the + time. + +- As another optimization, throw away unmapped physical pages when + there are no other references to the object (provided there is no + pager). Previously the pages would remain in core until the object + was either unmapped completely, or until another mapping was to be + created in place of the unmapped one and coalescing kicked in. + +- Also shrink the size of `struct vm_page` somewhat. This was a low + hanging fruit. + +`vm_map_coalesce_entry()` is analogous to `vm_map_simplify_entry()` in +other versions of Mach, but different enough to warrant a different +name. The same "coalesce" wording was used as in +`vm_object_coalesce()`, which is appropriate given that the former is +a wrapper for the latter. + +### The following provides clarifies some inaccuracies in old IRC logs: + + any request, be it e.g. `mmap()`, or `mprotect()`, can easily split + entries + +`mmap ()` cannot split entries to my knowledge, unless we're talking about +`MAP_FIXED` and unampping parts of the existing mappings. + + my ext2fs has ~6500 entries, but I guess this is related to + mapping blocks from the filesystem, right? + +No. Neither libdiskfs nor ext2fs ever map the store contents into memory +(arguably maybe they should); they just read them with `store_read ()`, +and then dispose of the the read buffers properly. The excessive number +of VM map entries, as far as I can see, is just heap memory. + + (I'm perplexed about how the kernel can merge two memory objects if + disctinct port names exist in the tasks' name space -- that's what + `mem_obj` is, right?) + + if, say, 584 and 585 above are port names which the task expects to be + able to access and do stuff with, what will happen to them when the + memory objects are merged? + +`mem_obj` in `vminfo` output is the VM object *name* port, not the +pager port (arguably `vminfo` should name it something other than +`mem_obj`). The name port is basically useful for seeing if two VM +regions have the exact same VM object mapped, and not much +else. Previously, it was also possible, as a GNU Mach extension, to +pass the name port into `vm_map ()`, but this was dropped for security +reasons. When Mach is built with `MACH_VM_DEBUG`, a name port can also +be used to query information about a VM object. + +Mach can't merge two memory objects. Mach doesn't merge *memory objects* +at all, it only merges/coalesces *VM objects*. The difference is subtle, +but important in certain contexts like this one: a "VM object" refers to +Mach's internal representation (`struct vm_object`), and a "memory object" +refers to the memory manager's implementation. There is normally a +1-to-1 correspondence between the two, but this is not always the case: +internal VM objects start without a memory object (pager) port at all, +and only get one created if/when they're paged out. There can be +multiple VM objects referencing the same backing memory object due to +copying and shadowing. + +So what Mach could do is merge the internal VM objects, by altering +page offsets to paste pages of one of the objects after the pager of +the other. But this is not implemented yet. What Mach actually does is +it avoids creating those internal VM objects and entries in the first +place, instead extending an already existing VM object and entry to +cover the new mapping. + + but at least, if two `vm_objects` are created but reference the same + externel memory object, the vm should be able to merge them back + +That never ever happens. There can only be a single `vm_object` for a +memory object. (In a single instance of Mach, that is -- if multiple +Machs access the same memory object over network-transparent IPC, each +is going to have its own `vm_object` representing the memory object.) + +See `vm_object_enter()` function, which looks up an existing VM object for +a memory object, and creates one if it doesn't yet exist. + + ok so if I get it right, the entries shown by `vmstat` are the + `vm_object`, and the mem_obj listed is a send right to the memory + object they're referencing ? + + yes + +No. The entries shown are VM map entries (`struct vm_map_entry`). There +can be entries that reference no VM object at all (`VM_OBJECT_NULL`), or +multiple entries that reference the same VM object. In fact this is +visible in the example above, the two entries mapped at `0x1311000` and at +`0x1314000` reference the same VM object, whose name port is 586. + +`mem_obj` listed is a send right to the *name* port of the VM object, not +to the memory object. Letting a task get the memory object port would be +disastrous for security (see the "No read-only mappings" vulnerability). + + i'm not sure about the type of the integer showed (port name or simply + an index) + +It is a port name (in vminfo's IPC name space) of the VM object name +port. + + if every `vm_allocate` request implies the creation of a memory object + from the default pager + +Not immediately, no. Only if the memory has to be paged out. Otherwise +an internal VM object is created without a memory object. + + and a `vm_object` is not a capability, but just an internal kernel + structure used to record the composition of the address space + +It is a kernel structure, but it also is a capability in the same way as +a task or a thread is a capability -- it is exposed as a port. +Specifically, a `memory_object_control_t` port is directly converted to a +`struct vm_object` by MIG. This would perhaps be clearer if +`memory_object_control_t` was instead named `vm_object_t`. The VM object +name port is also converted to a VM object, but this is only used in the +`MACH_VM_DEBUG RPCs`. + + i wonder when `vm_map_enter()` gets null objects though :/ + +Whenever you do `vm_map ()` with `MACH_PORT_NULL` for the object, or on +`vm_allocate ()` which is a shortcut for the same. + + the default pager backs `vm_objects` providing zero filled memory + +If that was the case, there would not be a need for a pager, Mach could +just hand out zero-filled pages. The anonymous mappings do start out +zero-filled, that is true. The default pager gets involved when the +pages are dirtied (so they no longer zero-filled) and there's memory +shortage so the pages have to paged out. + # IRC, freenode, #hurd, 2011-07-20 diff --git a/open_issues/libfshelp_in_hurdlibs.mdwn b/open_issues/libfshelp_in_hurdlibs.mdwn deleted file mode 100644 index 0700b061..00000000 --- a/open_issues/libfshelp_in_hurdlibs.mdwn +++ /dev/null @@ -1,17 +0,0 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] - -[[!meta title="libfshelp in HURDLIBS"]] - -[[!tag open_issue_hurd]] - -[[hurd/libtrivfs]] seems to use [[hurd/libfshelp]], but doesn't have it listed -in `HURDLIBS`. Should we change that? Same for [[hurd/libnetfs]] and -[[hurd/libdiskfs]]? diff --git a/open_issues/libpthread.mdwn b/open_issues/libpthread.mdwn index c628bc7b..3da5e558 100644 --- a/open_issues/libpthread.mdwn +++ b/open_issues/libpthread.mdwn @@ -13,20 +13,7 @@ License|/fdl]]."]]"""]] [[!toc]] - -# cthreads -> pthreads - -Get rid of cthreads; switch to pthreads. -Most of the issues raised on this page has been resolved, a few remain. - - -## IRC, freenode, #hurd, 2012-04-26 - - <pinotree> youpi: just to be sure: even if libpthread is compiled inside - glibc (with proper symbols forwarding etc), it doesn't change that you - cannot use both cthreads and pthreads in the same app, right? - -[[Packaging_libpthread]]. +# Packaging_libpthread. <youpi> it's the same libpthread <youpi> symbol forwarding does not magically resolve that libpthread lacks @@ -1176,7 +1163,7 @@ Most of the issues raised on this page has been resolved, a few remain. ## IRC, freenode, #hurd, 2012-09-23 <braunr> tschwinge: i committed the last hurd pthread change, - http://git.savannah.gnu.org/cgit/hurd/hurd.git/log/?h=master-pthreads + https://git.savannah.gnu.org/cgit/hurd/hurd.git/log/?h=master-pthreads <braunr> tschwinge: please tell me if you consider it ok for merging @@ -1310,7 +1297,7 @@ Most of the issues raised on this page has been resolved, a few remain. <braunr> thhe hurd must be plagued with wrong deallocations :( <braunr> i have so many problems when trying to cleanly destroy threads -[[libpthread/t/fix_have_kernel_resources]]. +[[libpthread/fix_have_kernel_resources]]. #### IRC, freenode, #hurd, 2013-11-25 @@ -1322,7 +1309,7 @@ Most of the issues raised on this page has been resolved, a few remain. #### IRC, freenode, #hurd, 2013-11-29 -See also [[open_issues/libpthread/t/fix_have_kernel_resources]]. +See also [[open_issues/libpthread/fix_have_kernel_resources]]. <braunr> there still are some leak ports making servers spawn threads with non-elevated priorities :/ @@ -1659,13 +1646,13 @@ See also [[open_issues/libpthread/t/fix_have_kernel_resources]]. does it right <braunr> in the io_select_timeout branch <braunr> see - http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/libthreads/cancel-cond.c?h=rbraun/select_timeout + https://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/libthreads/cancel-cond.c?h=rbraun/select_timeout for example * pinotree looks <braunr> what matters is the msg_delivered member used to synchronize sleeper and waker <braunr> the waker code is in - http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/libthreads/cprocs.c?h=rbraun/select_timeout + https://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/libthreads/cprocs.c?h=rbraun/select_timeout <pinotree> never seen cthreads' code before :) <braunr> soon you shouldn't have any more reason to :p <pinotree> ah, so basically the cthread version of the pthread cleanup diff --git a/open_issues/libpthread/t/fix_have_kernel_resources.mdwn b/open_issues/libpthread/fix_have_kernel_resources.mdwn index 02b6ab05..02b6ab05 100644 --- a/open_issues/libpthread/t/fix_have_kernel_resources.mdwn +++ b/open_issues/libpthread/fix_have_kernel_resources.mdwn diff --git a/open_issues/libpthread_cancellation_points.mdwn b/open_issues/libpthread_cancellation_points.mdwn index 09127e0c..cade7779 100644 --- a/open_issues/libpthread_cancellation_points.mdwn +++ b/open_issues/libpthread_cancellation_points.mdwn @@ -40,6 +40,8 @@ pthread_setcanceltype glibc/libpthread hook in the forward structure, but we are not using it: the LIBC_CANCEL_ASYNC macros are void, and we're not using them in the mig msg call either. +Update: As of glibc 2.33, some cancellation implementation was added. The test +above seems to be working fine. # Provenance diff --git a/open_issues/multithreading.mdwn b/open_issues/multithreading.mdwn index a66202c8..4f2db8fe 100644 --- a/open_issues/multithreading.mdwn +++ b/open_issues/multithreading.mdwn @@ -19,9 +19,7 @@ Hurd servers / VFS libraries are multithreaded. They can even be said to be * well-known threading libraries - * [[hurd/libthreads]] - - * [[hurd/libpthread]] + * [[/libpthread]] ## IRC, freenode, #hurd, 2011-04-20 diff --git a/open_issues/nice_vs_mach_thread_priorities.mdwn b/open_issues/nice_vs_mach_thread_priorities.mdwn deleted file mode 100644 index 1f4c6ab8..00000000 --- a/open_issues/nice_vs_mach_thread_priorities.mdwn +++ /dev/null @@ -1,429 +0,0 @@ -[[!meta copyright="Copyright © 2010, 2012, 2013 Free Software Foundation, -Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled [[GNU Free Documentation -License|/fdl]]."]]"""]] - -[[!tag open_issue_gnumach open_issue_glibc]] - -This issue has been known for some time, due to coreutils' testsuite choking -when testing *nice*: [[!debbug 190581]]. - -There has been older discussion about this, too, but this is not yet captured -here. - - -# IRC, freenode, #hurd, 2010-08 - - <pochu> I'm reading Mach and POSIX documentation to understand the priorities/nice problems - <pochu> antrik said it would be better to reimplement everything instead of - fixing the current Mach interfaces, though I'm not sure about that yet - <youpi> uh, so he changed his mind? - <pochu> it seems POSIX doesn't say nice values should be -20..20, but - 0..(2*NZERO - 1) - <youpi> he said we could just change the max priority value and be done - with it :) - <pochu> so we can probably define NZERO to 16 to match the Mach range of - 0..31 - <youpi> s/said/had said previously/ - <antrik> youpi: POSIX is actually fucked up regarding the definition of - nice values - <antrik> or at least the version I checked was - <pochu> antrik: why? this says the range is [0,{NZERO}*2-1], so we can just - set NZERO to 16 AFAICS: - http://www.opengroup.org/onlinepubs/9699919799/functions/getpriority.html - <antrik> it talkes about NZERO and all; making it *look* like this could be - defined arbitrarily... but in other places, it's clear that the standard - 40 level range is always assumed - <antrik> anyways, I totally see no point in deviating from other systems in - this regard. it can only cause problems, and gives us no benefits - <cfhammar> it says NZERO should be at least 20 iirc - <youpi> agreed - <antrik> I don't remember the details; it's been a while since I looked at - this - <antrik> youpi: changing the number of levels is only part of the - issue. I'm not sure why I didn't mention it initially when we discussed - this - <antrik> youpi: I already concluded years ago that it's not possible to - implement nice levels correctly with the current Mach interfaces in a - sane fashion - <antrik> (it's probably possible, but only with a stupid hack like setting - all the thread priorities one by one) - <antrik> youpi: also, last time we discussed this, I checked how the nice - stuff works currently on Hurd; and concluded that it's so utterly broken, - that there is no point in trying to preserve *any* compatibility. I think - we can safely throw away any handling that is alread there, and do it - over from scratch in the most straightforward fashion - <pochu> antrik: I've thought about setting NZERO to 16 and doing exactly - what you've just said to be a hack (setting all the thread priorities one - by one) - <pochu> but there seems to be consensus that that's undesirable... - <pochu> indeed, POSIX says NZERO should be at least 20 - <antrik> pochu: BTW, I forgot to say: I'm not sure you appreciate the - complexity of setting the thread max priorities individually - <pochu> antrik: I don't. would it be too complex? I imagined it would be a - simple loop :) - <antrik> pochu: in order to prevent race conditions, you have to stop all - other threads before obtaining the list of threads, and continue them - after setting the priority for each - <antrik> I don't even know whether it can be done without interfering with - other thread handling... in which case it gets really really ugly - <pochu> antrik: btw I'm looking at [gnumach]/kern/thread.[ch], removing the - priority stuff as appropriate, and will change the tasks code later - <antrik> it seems to me that using a more suitable kernel interface will - not only be more elegant, but quite possibly actually easier to - implement... - <pochu> antrik: apparently it's not that hard to change the priority for - all threads in a task, see task_priority() in gnumach/kern/task.c - <pochu> it looks like the nice test failures are mostly because of the not - 1:1 mapping between nice values and Mach priorities - <marcusb> "Set priority of task; used only for newly created threads." - <marcusb> there is a reason I didn't fix nice 8 years ago - <marcusb> ah there is a change_threads option - <pochu> marcusb: I'm not sure that comment is correct. that syscall is used - by setpriority() - <marcusb> yeah - <marcusb> I didn't read further, where it explains the change_threads - options - <marcusb> I was shooting before asking questions :) - <marcusb> pochu: although there are some bad interactions if max_priorities - are set per thread - <antrik> pochu: maybe we are talking past each other. my point was not that - it's hard to do in the kernel. I was just saying that it would be painful - to do from userspace with the current kernel interface - <pochu> antrik: you could still use that interface in user space, couldn't - you? or maybe I'm misunderstanding... - <pochu> cfhammar, antrik: current patch: - http://emilio.pozuelo.org/~deb/gnumach.patch, main issue is probably what - to do with high-priority threads. are there cases where there should be a - thread with a high priority but the task's priority shouldn't be high? - e.g. what to do with kernel_thread() in [gnumach]/kern/thread.c - <pochu> i.e. if tasks have a max_priority, then threads shouldn't have a - higher priority, but then either we raise the task's max_priority if we - need a high-prio thread, or we treat them specially (e.g. new field in - struct thread), or maybe it's a non-issue because in such cases, all the - task is high-prio? - <pochu> also I wonder whether I can kill the processor set's - max_priority. It seems totally unused (I've checked gnumach, hurd and - glibc) - <pochu> (that would simplify the priority handling) - <cfhammar> pochu: btw what does your patch do? i can't remember what was - decided - <pochu> cfhammar: it moves the max_priority from the thread to the task, so - raising/lowering it has effect on all of its threads - <pochu> it also increases the number of run queues (and thus that of - priority levels) from 32 to 40 so we can have a 1:1 mapping with nice - values - <pochu> cfhammar: btw don't do a full review yet, just a quick look would - be fine for now - <neal> why not do priorities from 0 to 159 - <neal> then both ranges can be scaled - <neal> without loss of precision - <pochu> neal: there would be from Mach to nice priorities, e.g. a task with - a priority of 2 another with 3 would have the same niceness, though their - priority isn't really the same - <neal> pochu: sure - <neal> pochu: but any posix priority would map to a current mach priority - and back - <neal> sorry, that's not true - <neal> a posix priority would map to a new mach priority and bach - <neal> and a current mach priority would map to a new mach priority and - back - <neal> which is I think more desirable than changing to 40 priority levels - <pochu> neal> and a current mach priority would map to a new mach priority - and back <- why should we care about this? - <neal> to be compatible with existing mach code - <neal> why gratutiously break existing interfaces? - <pochu> they would break anyway, wouldn't them? i.e. if you do - task_set_priority(..., 20), you can't know if the caller is assuming old - or new priorities (to leave it as 20 or as 100) - <neal> you add a new interface - <neal> you should avoid changing the semantics of existing interfaces as - much as possible - <pochu> ok, and deprecate the old ones I guess - <neal> following that rule, priorities only break if someone does - task_set_priority_new(..., X) and task_get_priority () - <neal> there are other users of Mach - <neal> I'd add a configure check for the new interface - <neal> alternatively, you can check at run time - <pochu> well if you _set_priority_new(), you should _get_priority_new() :) - <neal> it's not always possible - <pochu> other users of GNU Mach? - <neal> you are assuming you have complete control of all the code - <neal> this is usually not the case - <neal> no, other users of Mach - <neal> even apple didn't gratuitously break Mach - <neal> in fact, it may make sense to see how apple handles this problem - <pochu> hmm, I hadn't thought about that - <pochu> the other thing I don't understand is: "I'd add a configure check - for the new interface". a configure check where? in Mach's configure? - that doesn't make sense to me - <neal> any users of the interface - <pochu> ok so in clients, e.g. glibc & hurd - <neal> yes. - <antrik> neal: I'm not sure we are winning anything by keeping - compatibility with other users of Mach... - <antrik> neal: we *know* that to make Hurd work really well, we have to do - major changes sooner or later. we can just as well start now IMHO - <antrik> keeping compatibility just seems like extra effort without any - benefit for us - <guillem> just OOC have all other Mach forks, preserved full compatibility? - <neal> guillem: Darwin is pretty compatible, as I understand it - <antrik> pochu: the fundamental approach of changing the task_priority - interface to serve as a max priority, and to drop the notion of max - priorities from threads, looks fine - <antrik> pochu: I'm not sure about the thread priority handling - <antrik> I don't know how thread priorities are supposed to work in chreads - and/or pthread - <antrik> I can only *guess* that they assume a two-stage scheduling - process, where the kernel first decides what process to run; and only - later which thread in a process... - <antrik> if that's indeed the case, I don't think it's even possible to - implement with the current Mach scheduler - <antrik> I guess we could work with relative thread priorities if we really - want: always have the highest-priority thread run with the task's max - priority, and lower the priorities of the other threads accordingly - <antrik> however, before engaging into this, I think you should better - check whether any of the code in Hurd or glibc actually uses thread - priorities at all. my guess is that it doesn't - <antrik> I think we could get away with stubbing out thread priority - handling alltogether for now, and just use the task priority for all - threads - <antrik> I agree BTW that it would be useful to check how Darwin handles - this - <pochu> btw do you know where to download the OS X kernel source? I found - something called xnu, but I?m not sure that's it - <antrik> pochu: yeah, that's it - <antrik> Darwin is the UNIX core of OS X, and Xnu is the actual kernel... - <pochu> hmm, so they have both a task.priority and a task.max_priority - <neal> pochu: thoughts? - <pochu> neal: they have a priority and a max_priority in the task and in - the threads, new threads inherit it from its parent task - <pochu> then they have a task_priority(task, priority, max_priority) that - can change a task's priorities, and it also changes it for all its - threads - <neal> how does the global run queue work? - <pochu> and they have 128 run queues, no idea if there's a special reason - for that number - <pochu> neal: sorry, what do you mean? - <neal> I don't understand the point of the max_priority parameter - <pochu> neal: and I don't understand the point of the (base) priority ;) - <pochu> the max_priority is just that, the maximum priority of a thread, - which can be lowered, but can't exceed the max one - <pochu> the (base) priority, I don't understand what it does, though I - haven't looked too hard. maybe it's the one a thread starts at, and must - be <= max_priority - <antrik> pochu: it's clearly documented in the manual, as well as in the - code your initial patch changes... - <antrik> or do you mean the meaning is different in Darwin?... - <pochu> I was speaking of Darwin, though maybe it's the same as you say - <antrik> I would assume it's the same. I don't think there would be any - point in having the base vs. max priority distinction at all, except to - stay in line with standard Mach... - <antrik> at least I can't see a point in the base priority semantics for - use in POSIX systems... - <pochu> right, it would make sense to always have priority == max_priority - ... - <pochu> neal: so max_priority is that maximum priority, and priority is the - one used to calculate the scheduled priority, and can be raised and - lowered by the user without giving special permissions as long as he - doesn't raise it above max_priority - <pochu> well this would allow a user to lower a process' priority, and - raise it again later, though that may not be allowed by POSIX, so then we - would want to have max_priority == priority (or get rid of one of them if - possible and backwards compatible) - <antrik> pochu: right, that's what I think too - <antrik> BTW, did I bring up handling of thread priorities? I know that I - meant to, but I don't remember whether I actually did... - <pochu> antrik: you told me it'd be ok to just get rid of them for now - <pochu> so I'm more thinking of fixing max_priority and (base) priority and - leaving thread's scheduling priority as it currently is - <pochu> s/so/though/ - <antrik> pochu: well, my fear is that keeping the thread priority handling - as ist while changing task priority handling would complicate the - changes, while giving us no real benefit... - <antrik> though looking at what Darwin did there should give you an idea - what it involves exactly... - <pochu> antrik: what would you propose, keeping sched_priority == - max_priority ? - <pochu> s/keeping/making/ - <antrik> yes, if that means what I think it does ;-) - <antrik> and keeping the priority of all threads equal to the task priority - for now - <antrik> of course this only makes sense if changing it like this is - actually simpler than extending the current handling... - <antrik> again, I can't judge this without actually knowing the code in - question. looking at Darwin should give you an idea... - <pochu> I think leaving it as is, making it work with the task's - max_priority changes would be easier - <antrik> perhaps I'm totally overestimating the amount of changes required - to do what Darwin does - <antrik> OTOH, carrying around dead code isn't exactly helping the - maintainability and efficiency of gnumach... - <antrik> so I'm a bit ambivalent on this - <antrik> should we go for minimal changes here, or use this occasion to - simplify things?... - <antrik> I guess it would be good to bring this up on the ML - <cfhammar> in the context of gsoc i'd say minimal changes - <pochu> there's also neal's point on keeping backwards compatibility as - much as possible - <neal> my point was not backwards compatibility at all costs - <antrik> I'm still not convinced this is a valid point :-) - <neal> but to not gratutiously break things - <antrik> neal: well, I never suggested breaking things just because we - can... I only suggested breaking things to make the code and interface - simpler :-) - <antrik> I do not insist on it though - <neal> at that time, we did not know how Mac did it - <antrik> I only think it would be good to get into a habit that Mach - interfaces are not sacred... - <neal> and, I also had a proposal, which I think is not difficult to - implement given the existing patch - <antrik> but as I said, I do not feel strongly about this. if people feel - more confident about a minimal change, I'm fine with that :-) - <antrik> neal: err... IIRC your proposal was only about the number of nice - levels? we are discussing the interface change necessary to implement - POSIX semantics properly - <antrik> or am I misremembering? - <pochu> antrik: he argues that with that number of nice levels, we could - keep backwards compatibility for the 0..31 levels, and for 0..39 for - POSIX compatibility - <antrik> pochu: yes, I remember that part - <neal> antrik : My suggestion was: raise the number of nice levels to 160 - and introduce a new interface which uses those. Adjust the old interface - to space by 160/32 - <antrik> neal: I think I said it before: the problem is not *only* in the - number of priority levels. the semantics are also wrong. which is why - Darwin added a max_priority for tasks - <neal> what do you mean the semantics are wrong? - <neal> I apologize if you already explained this. - <antrik> hm... I explained it at some point, but I guess you were not - present at that conversation - <neal> I got disconnected recently so I likely don't have it in backlog. - <antrik> in POSIX, any process can lower its priority; while only - privileged processes can raise it - <antrik> Mach distinguishes between "current" and "max" priority for - threads: "max" behaves like POSIX; while "current" can be raised or - lowered at will, as long as it stays below "max" - <antrik> for tasks, there is only a "current" priority - <antrik> (which applies to newly created threads, and optionally can be set - for all current threads while changing the task priority) - <antrik> glibc currently uses the existing task priorities, which leads to - *completely* broken semantics - <antrik> instead, we need something like a max task priority -- which is - exactly what Darwin added - <neal> yes - <antrik> (the "current" task priority is useless for POSIX semantics as far - as I can tell; and regarding thread priorities, I doubt we actually use - them at all?...) - <cfhammar> where does a new thread get its initial max_priority from? - <antrik> cfhammar: from the creator thread IIRC - <pochu> yes - - -## IRC, freenode, #hurd, 2010-08-12 - - <pochu> my plan is to change the number of priority levels and the - threads/tasks priority handling, then add new RPCs to play with them and - make the old ones stay compatible, then make glibc use the new RPCs - - -# IRC, freenode, #hurd, 2012-12-29 - - <braunr> and, for a reason that i can't understand, there are less - priorities than nice levels, despite the fact mach was designed to run - unix systems on top of it .. - <youpi> btw, didn't we have a plan to increase that number? - <braunr> i have no idea - <braunr> but we should :) - <youpi> I remember some discussion about it on the list - - -## IRC, freenode, #hurd, 2012-12-31 - - <youpi> braunr: btw, we *do* have fixed the nice granularity - <youpi> +#define MACH_PRIORITY_TO_NICE(prio) ((prio) - 20) - <youpi> in the debian package at least - <youpi> ah, no - <youpi> it's not applied yet - <youpi> so I have the patch under hand, just not applied :) - <braunr> but that's a simple shift - <braunr> the real problem is that there aren't as many mach priorities as - there are nice levels - <youpi> that's not really a problem - <youpi> we can raise that in the kernel - <youpi> the problem is the change from shifted to unshifted - <youpi> that brings odd nice values during the upgrade - <braunr> ok - <braunr> i hope the scheduler code isn't allergic to more priorities :) - - -## IRC, freenode, #hurd, 2013-01-02 - - <braunr> pochu: i see you were working on nice levels and scheduling code - some time ago - <braunr> pochu: anything new since then ? - <pochu> braunr: nope - <braunr> pochu: were you preparing it for the gsoc ? - <pochu> braunr: can't remember right now, either that or to fix a ftbfs in - debian - <youpi> iirc it's coreutils which wants proper nice levels - - -# IRC, OFTC, #debian-hurd, 2013-03-04 - - <Steap> Is it not possible to set the priority of a process to 1 ? - <Steap> these macros: - <Steap> #define MACH_PRIORITY_TO_NICE(prio) (2 * ((prio) - 12)) - <Steap> #define NICE_TO_MACH_PRIORITY(nice) (12 + ((nice) / 2)) - <Steap> are used in the setpriority() implementation of Hurd - <Steap> so setting a process' priority to 1 is just like setting it to 0 - <youpi> Steap: that has already been discussed to drop the *2 - <youpi> the issue is mach not supporting enough sched levels - <youpi> can be fixed, of course - <youpi> just nobody did yet - -GNU Mach commit 6a234201081156e6d5742e7eeabb68418b518fad (and commit -6fe36b76f7983ec9a2e8a70420e431d54252442e). - - -## IRC, OFTC, #debian-hurd, 2013-03-07 - - <braunr> youpi: btw, why did you increase the number of priorites to 50 ? - <youpi> for the nice levels - <braunr> and probably something more, there are only 40 nice levels - <youpi> yes, the current computation leaves some margin - <youpi> so I preferred to keep a margin too - <braunr> ok - <youpi> e.g. for the idle thread, etc. - <braunr> or interrupt threads - <youpi> yep - <braunr> i see the point, thanks - <tschwinge> Is the number of 40 specified by POSIX (or whatever) or is that - a Linuxism? - <braunr> good question - <braunr> posix is weird when it comes to such old unixisms - <braunr> there is a NZERO value, but i don't remember how it's specified - <youpi> it's at least 20 - <tschwinge> (I don't object to the change; just wondered. And if practice, - you probably wouldn't really need more than a handful. But if that - change (plus some follow-up in glibc (?) improves something while not - adding a lot of overhead, then that's entirely fine, of course.) - <braunr> "A maximum nice value of 2*{NZERO}-1 and a minimum nice value of 0 - shall be imposed by the system" - <braunr> NZERO being 20 by default - <youpi> and 20 is the minimum for NZERO too - <braunr> hm, not the default, the minimul - <braunr> minimum - <braunr> yes that's it - <braunr> ok so it's actually well specified - <tschwinge> Aha, I see (just read it, too). So before that change we - simply couldn't satisfy the POSIX requirement of (minimum) NZERO = 20, - and allowing for step-1 increments. Alright. - <youpi> yep - <youpi> thus failing in coreutils testsuite diff --git a/open_issues/nightly_builds_deb_packages.mdwn b/open_issues/nightly_builds_deb_packages.mdwn index cef16734..6c5cda41 100644 --- a/open_issues/nightly_builds_deb_packages.mdwn +++ b/open_issues/nightly_builds_deb_packages.mdwn @@ -71,7 +71,7 @@ See also [[nightly_builds]]. For d-i purposes, you'll additionally need: - $ wget http://people.debian.org/~sthibault/hurd-i386/installer/cdimage/current/initrd.gz + $ wget https://cdimage.debian.org/cdimage/ports/stable/hurd-i386/initrd.gz ..., and to the `--initrd` option prepend `'initrd.gz $(ramdisk-create)',` before the `ext2fs.static`, and refer the latter to `gunzip:device:rd0` instead diff --git a/open_issues/open_symlink.mdwn b/open_issues/open_symlink.mdwn deleted file mode 100644 index 663bfcbd..00000000 --- a/open_issues/open_symlink.mdwn +++ /dev/null @@ -1,30 +0,0 @@ -[[!meta copyright="Copyright © 2012, 2013 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled [[GNU Free Documentation -License|/fdl]]."]]"""]] - -[[!tag open_issue_glibc]] - - -# IRC, freenode, #hurd, 2012-01-02 - - <pinotree> hm, is it a known issue that open("somesymlink", O_RDONLY | - O_NOFOLLOW) does not fail with ELOOP? - <youpi> pinotree: iirc there is code for it, maybe not the same behavior as - on linux - - -## IRC, OFTC, #debian-hurd, 2013-05-08 - - <pinotree> the hurd issue is that O_NOFOLLOW seems broken on symlinks, and - thus open(symlink, O_NOFOLLOW) doesn't fail with ELOOP - <youpi> I don't really see why it should fail - <youpi> since NOFOLLOW says not to follow the symlink - <pinotree> yeah, but you cannot open a symlink - <youpi> ah right ok - <youpi> interesting :) diff --git a/open_issues/pci_arbiter.mdwn b/open_issues/pci_arbiter.mdwn index 7fdb4323..a6f8c893 100644 --- a/open_issues/pci_arbiter.mdwn +++ b/open_issues/pci_arbiter.mdwn @@ -25,7 +25,7 @@ sequential: gnumach, netdde, and then Xorg. The PCI Arbiter will eventually allo concurrent access to the PCI config space. The Hurd now has a PCI Arbiter, but it could use some more polishing. You can find -its TODO file [[here|http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/pci-arbiter/TODO]]. +its TODO file [[here|https://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/pci-arbiter/TODO]]. Samuel also gave a presentation explaining some of the awesome possibilities that the PCI Arbiter can provide. You can watch his fosdem talk diff --git a/open_issues/perl.mdwn b/open_issues/perl.mdwn index 62d29ac1..6e05a8c0 100644 --- a/open_issues/perl.mdwn +++ b/open_issues/perl.mdwn @@ -14,7 +14,7 @@ License|/fdl]]."]]"""]] currently leads to: *Could not perform immediate configuration on 'perl'*. Easy workaround: - # apt-get install perl perl-base -o APT::Immediate-Configure=false + # apt install perl perl-base -o APT::Immediate-Configure=false """]] diff --git a/open_issues/pth.mdwn b/open_issues/pth.mdwn deleted file mode 100644 index 12bf5098..00000000 --- a/open_issues/pth.mdwn +++ /dev/null @@ -1,28 +0,0 @@ -[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation, -Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] - -[[!tag open_issue_porting]] - -IRC, unknown channel, unknown date. - - <azeem> seems pth still doesn't work - <bddebian> Doesn't build or doesn't work? - <azeem> both - <azeem> some configure test keep grinding the CPU, same for the test suite - <azeem> which apparently runs pth_init() and never returns - - <azeem> actually, pth fails to build right now - <azeem> pth_mctx.c:477: error: request for member '__pc' in something not a structure or union - - <azeem> I know the pth test suite fails (it locks up the machine) or used to fail, so I guess porting work for pth would be needed - <azeem> < marcusb> from reading the pth/PORTING document, porting libpth shouldn't be too hard... - - <youpi> dropped pth [from the channel's topic], as we think we know why it fails (sigaltstack is bogus) diff --git a/open_issues/pthread_atfork.mdwn b/open_issues/pthread_atfork.mdwn deleted file mode 100644 index d386e5c0..00000000 --- a/open_issues/pthread_atfork.mdwn +++ /dev/null @@ -1,111 +0,0 @@ -[[!meta copyright="Copyright © 2011, 2013 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled [[GNU Free Documentation -License|/fdl]]."]]"""]] - -[[!tag open_issue_glibc open_issue_libpthread]] - -`pthread_atfork` is not actually implemented, making some programs fail. Code -can probably be borrowed from `nptl/sysdeps/unix/sysv/linux/register-atfork.c`. - - -# IRC, OFTC, #debian-hurd, 2013-08-21 - - <pinotree> SRCDIR/opal/mca/memory/linux/arena.c:387: warning: warning: - pthread_atfork is not implemented and will always fail - - -# Samuel's implementation - -TODO. - - -## IRC, OFTC, #debian-hurd, 2013-10-08 - - <pinotree> youpi: if you need/want to test your pthread_atfork - implementation, you can check libposix-atfork-perl and its test suite - (whose test 004 hangs now, with eglibc -93) - <youpi> while it failed previously indeed - <youpi> we might simply need to rebuild perl against it - <youpi> (I see ifdef pthread_atfork in perl) - - -## undefined reference to `__start__hurd_atfork_prepare_hook' - -### IRC, freenode, #hurd, 2013-10-16 - - <teythoon> tschwinge: I'd love to try your cross-gnu tool, the wiki page - suggests that the list of required source packages is outdated. can you - give me some hints? - <teythoon> tschwinge: I got this error running cross-gnu: - http://paste.debian.net/58303/ - make[4]: Leaving directory `/home/teythoon/repos/hurd/cross/src/glibc/setjmp' - make subdir=string -C ../string ..=../ objdir=/home/teythoon/repos/hurd/cross/obj/glibc -f Makefile -f ../elf/rtld-Rules rtld-all rtld-modules='rtld-strchr.os rtld-strcmp.os rtld-strcpy.os rtld-strlen.os rtld-strnlen.os rtld-memchr.os rtld-memcmp.os rtld-memmove.os rtld-memset.os rtld-mempcpy.os rtld-stpcpy.os rtld-memcpy.os rtld-rawmemchr.os rtld-argz-count.os rtld-argz-extract.os rtld-stpncpy.os' - make[4]: Entering directory `/home/teythoon/repos/hurd/cross/src/glibc/string' - make[4]: Leaving directory `/home/teythoon/repos/hurd/cross/src/glibc/string' - make[4]: Entering directory `/home/teythoon/repos/hurd/cross/src/glibc/string' - make[4]: Nothing to be done for `rtld-all'. - make[4]: Leaving directory `/home/teythoon/repos/hurd/cross/src/glibc/string' - make[3]: Leaving directory `/home/teythoon/repos/hurd/cross/src/glibc/elf' - i686-pc-gnu-gcc -shared -static-libgcc -Wl,-O1 -Wl,-z,defs -Wl,-dynamic-linker=/lib/ld.so.1 -B/home/teythoon/repos/hurd/cross/obj/glibc/csu/ -Wl,--version-script=/home/teythoon/repos/hurd/cross/obj/glibc/libc.map -Wl,-soname=libc.so.0.3 -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both -nostdlib -nostartfiles -e __libc_main -L/home/teythoon/repos/hurd/cross/obj/glibc -L/home/teythoon/repos/hurd/cross/obj/glibc/math -L/home/teythoon/repos/hurd/cross/obj/glibc/elf -L/home/teythoon/repos/hurd/cross/obj/glibc/dlfcn -L/home/teythoon/repos/hurd/cross/obj/glibc/nss -L/home/teythoon/repos/hurd/cross/obj/glibc/nis -L/home/teythoon/repos/hurd/cross/obj/glibc/rt -L/home/teythoon/repos/hurd/cross/obj/glibc/resolv -L/home/teythoon/repos/hurd/cross/obj/glibc/crypt -L/home/teythoon/repos/hurd/cross/obj/glibc/mach -L/home/teythoon/repos/hurd/cross/obj/glibc/hurd -Wl,-rpath-link=/home/teythoon/repos/hurd/cross/obj/glibc:/home/teythoon/repos/hurd/cross/obj/glibc/math:/home/teythoon/repos/hurd/cross/obj/glibc/elf:/home/teythoon/repos/hurd/cross/obj/glibc/dlfcn:/home/teythoon/repos/hurd/cross/obj/glibc/nss:/home/teythoon/repos/hurd/cross/obj/glibc/nis:/home/teythoon/repos/hurd/cross/obj/glibc/rt:/home/teythoon/repos/hurd/cross/obj/glibc/resolv:/home/teythoon/repos/hurd/cross/obj/glibc/crypt:/home/teythoon/repos/hurd/cross/obj/glibc/mach:/home/teythoon/repos/hurd/cross/obj/glibc/hurd -o /home/teythoon/repos/hurd/cross/obj/glibc/libc.so -T /home/teythoon/repos/hurd/cross/obj/glibc/shlib.lds /home/teythoon/repos/hurd/cross/obj/glibc/csu/abi-note.o /home/teythoon/repos/hurd/cross/obj/glibc/elf/soinit.os /home/teythoon/repos/hurd/cross/obj/glibc/libc_pic.os /home/teythoon/repos/hurd/cross/obj/glibc/elf/sofini.os /home/teythoon/repos/hurd/cross/obj/glibc/elf/interp.os /home/teythoon/repos/hurd/cross/obj/glibc/elf/ld.so /home/teythoon/repos/hurd/cross/obj/glibc/mach/libmachuser-link.so /home/teythoon/repos/hurd/cross/obj/glibc/hurd/libhurduser-link.so -lgcc - /home/teythoon/repos/hurd/cross/obj/glibc/libc_pic.os: In function `__fork': - /home/teythoon/repos/hurd/cross/src/glibc/posix/../sysdeps/mach/hurd/fork.c:70: undefined reference to `__start__hurd_atfork_prepare_hook' - /home/teythoon/repos/hurd/cross/lib/gcc/i686-pc-gnu/4.8.1/../../../../i686-pc-gnu/bin/ld: /home/teythoon/repos/hurd/cross/obj/glibc/libc_pic.os: relocation R_386_GOTOFF against undefined hidden symbol `__start__hurd_atfork_prepare_hook' can not be used when making a shared object - /home/teythoon/repos/hurd/cross/lib/gcc/i686-pc-gnu/4.8.1/../../../../i686-pc-gnu/bin/ld: final link failed: Bad value - collect2: error: ld returned 1 exit status - make[2]: *** [/home/teythoon/repos/hurd/cross/obj/glibc/libc.so] Error 1 - make[2]: Leaving directory `/home/teythoon/repos/hurd/cross/src/glibc/elf' - make[1]: *** [elf/subdir_lib] Error 2 - make[1]: Leaving directory `/home/teythoon/repos/hurd/cross/src/glibc' - make: *** [all] Error 2 - + rm -f /home/teythoon/repos/hurd/cross/sys_root/lib/ld.so - + exit 100 - - binutils-2.23.2, - gcc-4.8.1, - everything else is from git as specified in the wiki. - - -### IRC, freenode, #hurd, 2013-10-24 - - <AliciaC> in recent glibc commits (tschwinge/Roger_Whittaker branch) there - are references to _hurd_atfork_* symbols in sysdeps/mach/hurd/fork.c, and - some _hurd_fork_* symbols, some of the _hurd_fork_* symbols seem to be - defined in Hurd's boot/frankemul.ld (mostly guessing by their names being - mentioned, I don't know linker script syntax), but those _hurd_atfork_* - symbols don't seem to be defined there, are they supposed to be defined - elsewhere or is th - <AliciaC> does anyone know where the _hurd_atfork_* group of symbols - referenced in glibc are defined (if anywhere)? - <youpi> AliciaC: it's the DEFINE_HOOK (_hurd_atfork_prepare_hook, (void)); - in glibc/sysdeps/mach/hurd/fork.c - <AliciaC> hm, is that not just a declaration? - <youpi> no, it's a definition, as its name suggests : - <AliciaC> (despite the macro name) - <youpi> :) - <AliciaC> ok - <AliciaC> I should look into it more, I could have sworn I was getting - undefined references, but maybe the symbol names used are different from - those defined, but that'd be odd as well, in the same file and all - <AliciaC> I mean, I do get undefined references, but question is if it's to - things that should have been defined or not - <youpi> what undefined references do you gaT? - <youpi> s/gaT/get - <AliciaC> I'll get back to you once I have that system up again - <AliciaC> youpi: sysdeps/mach/hurd/fork.c:70: undefined reference to - `__start__hurd_atfork_prepare_hook' - <AliciaC> fork.c:70: 'RUN_HOOK (_hurd_atfork_prepare_hook, ());' - <AliciaC> DEFINE_HOOK (_hurd_atfork_prepare_hook, (void)); is higher up in - the file - <AliciaC> though there is also this message: build/libc_pic.os: relocation - R_386_GOTOFF against undefined hidden symbol - `__start__hurd_atfork_prepare_hook' can not be used when making a shared - object - - -### [[!message-id "878uvfmwvs.fsf@kepler.schwinge.homeip.net"]] diff --git a/open_issues/rpc_stub_generator.mdwn b/open_issues/rpc_stub_generator.mdwn index d4622d67..26511d3b 100644 --- a/open_issues/rpc_stub_generator.mdwn +++ b/open_issues/rpc_stub_generator.mdwn @@ -122,7 +122,7 @@ License|/fdl]]."]]"""]] <neal> the first are a burden <neal> the latter is a pain <neal> - http://git.savannah.gnu.org/gitweb/?p=hurd/viengoos.git;a=blob;f=libviengoos/viengoos/rpc.h;h=721768358a0299637fb79f226aea6a304571da85;hb=refs/heads/viengoos-on-bare-metal + https://git.savannah.gnu.org/gitweb/?p=hurd/viengoos.git;a=blob;f=libviengoos/viengoos/rpc.h;h=721768358a0299637fb79f226aea6a304571da85;hb=refs/heads/viengoos-on-bare-metal <neal> in the same directory, you there are headers that use it <braunr> neal: cf. http://genode.org/documentation/release-notes/11.05 <braunr> tschwinge: why do you recommend an IDL ? diff --git a/open_issues/sa_siginfo_sa_sigaction.mdwn b/open_issues/sa_siginfo_sa_sigaction.mdwn deleted file mode 100644 index 4e1fa849..00000000 --- a/open_issues/sa_siginfo_sa_sigaction.mdwn +++ /dev/null @@ -1,96 +0,0 @@ -[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation, -Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled [[GNU Free Documentation -License|/fdl]]."]]"""]] - -[[!meta title="SA_SIGINFO, SA_SIGACTION"]] - -[[!tag open_issue_glibc]] - -Note: SA_SIGINFO has now been implemented by Jérémie Koenig. It will be -uploaded in Debian eglibc 2.13-19. - -IRC, #hurd, August / September 2010: - - <giselher> Hy, I came across SA_SIGINFO in cherokee, I have the void sighandler(int num) prototype but how do I add the sa_handler field? - <pinotree> if SA_SIGACTION is not defined, then you use sa_handler instead of sa_sigaction, and not add SA_SIGINFO in the sa_flags - <giselher> SA_SIGINFO is not defined - <pinotree> s/SA_SIGACTION/SA_SIGINFO/ above, yes - <giselher> K - <giselher> I am not sure if I fully understand this, there is the line "act.sa_flags = SA_SIGINFO" and how do I have to change that >_> - <pinotree> can you paste the source in a pastebin? - <giselher> k - <giselher> http://archhurd.pastebin.com/N8BCnG6g at line 790 - <pinotree> something along the lines of http://www.archhurd.pastebin.com/tdpcFD5G - <pinotree> note that in the handler the siginfo_t parameter is used, which cannot be done if SA_SIGINFO is not defined - <pinotree> (that code still won't compile, yet) - <giselher> btw: is there a reason why SA_SIGINFO is not implemented? - <giselher> the guildlines only say "It's not implemented" - <azeem> 09:43 < azeem> signal stuff is tricky :-/ - <azeem> basically it was pending on a complete rewrite by Roland, which never occured - <youpi> I have an almost complete implementation, just not finished yet - <youpi> (only the siginfo part) - <azeem> nobody really groked that code for years until youpi showed up, but he added partial support AFAIK, not having much time on his hand - <azeem> ah, he's here - <azeem> :) - <giselher> oh, should I just wait ? - <youpi> no - <giselher> k - <youpi> there are OSes which don't have SA_SIGINFO - <youpi> just cope with them: use sa_handler instead of sa_sigaction, and don't set SA_SIGINFO - <youpi> (i.e. replace with 0 in your example) - <giselher> ok - <youpi> when SA_SIGINFO becomes available, it'll just be used - -IRC, freenode, #hurd, 2011-08-20: - - < youpi> erf, tcpwrappers will need si_pid - < jkoenig> I could implement it not too far away in the future, we just - need a version of msg_sig_post() with a siginfo argument or something. - < youpi> I can also see a lot of packages using SA_SIGINFO for no reason... - < youpi> (probably copy/pasty code) - < youpi> sa.sa_flags = SA_SIGINFO; - < youpi> sa.sa_handler = parse_config; - < youpi> void parse_config(int) - < youpi> yay - < youpi> if(siginf->si_signo == SIGXCPU) - < youpi> fprintf(stderr, "Exceeded CPU usage.\n"); - < youpi> ... - < youpi> jkoenig: actually most package don't actually use the SA_SIGINFO - they request... - < youpi> jkoenig: si_pid should get us almost all actually used coverage - < youpi> I've seen only one example using si_errno - < jkoenig> ok - < youpi> oh, it's actually supported by your patch - < youpi> (errno) - < jkoenig> but I guess since implementing si_pid will require a new RPC, we - might as well plan for the rest - < youpi> jkoenig: indeed - < jkoenig> youpi, hmm I doubt it's properly filled in in all circumstances? - < youpi> ok, well, we'll see - < pinotree> jkoenig: if it can be of help, boost::unit_test queries various - fields of siginfo_t depending on the signal - < pinotree> jkoenig: also, pulseaudio uses siginfo_t for remapping faulting - memory on SIGBUS - < jkoenig> pinotree, oh ok good to know - < pinotree> *faulty - < youpi> jkoenig: well, I guess you had checked that the si_addr field is - correct in a few simple testcase :) - < jkoenig> hmm I think so, yes - < jkoenig> I ran like, "* (char *) 0x12345678;" or something IIRC - < youpi> ok - < jkoenig> I seem to remember mach generated SIGBUS instead of SIGSEGV - depending on the upper bit, or something (I can't quite remember) - < jkoenig> but when sigsegv was generated si_addr was right. - < pinotree> jkoenig: (see boost/test/impl/execution_monitor.ipp in boost - sources) - < pinotree> maybe you can try the unit tests for boost::unit_tests, if any - :) - < pinotree> (while src/pulsecore/memtrap.c in PA) - * pinotree stops doing MrObvious™ diff --git a/open_issues/select.mdwn b/open_issues/select.mdwn index caecc437..19468d90 100644 --- a/open_issues/select.mdwn +++ b/open_issues/select.mdwn @@ -1103,7 +1103,7 @@ IRC, unknown channel, unknown date: <braunr> unfortunately, my idea alone isn't enough <braunr> for those interested in the problem, i've updated the analysis in my last commit - (http://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?h=rbraun/select_timeout&id=40fe717ba9093c0c893d9ea44673e46a6f9e0c7d) + (https://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?h=rbraun/select_timeout&id=40fe717ba9093c0c893d9ea44673e46a6f9e0c7d) #### IRC, freenode, #hurd, 2012-08-01 @@ -1660,7 +1660,7 @@ IRC, unknown channel, unknown date: #### IRC, freenode, #hurd, 2012-12-17 <braunr> tschwinge: - http://git.savannah.gnu.org/cgit/hurd/glibc.git/log/?h=rbraun/select_timeout_for_one_fd + https://git.savannah.gnu.org/cgit/hurd/glibc.git/log/?h=rbraun/select_timeout_for_one_fd <braunr> gnu_srs: talking about that, can you explain : <braunr> "- The pure delay case is much faster now, making it necessary to <braunr> introduce a delay of 1 msec when the timeout parameter is set to diff --git a/open_issues/serial_console.mdwn b/open_issues/serial_console.mdwn index 827fd211..3100d60c 100644 --- a/open_issues/serial_console.mdwn +++ b/open_issues/serial_console.mdwn @@ -67,7 +67,7 @@ License|/fdl]]."]]"""]] <braunr> we definitely want it to work with 8N1 <gg0> never had problems with _virtual_ serial consoles <gg0> never = during last 2 years = since - http://git.savannah.gnu.org/gitweb/?p=hurd/gnumach.git;a=commitdiff;h=2a603e88f86bee88e013c2451eacf076fbcaed81 + https://git.savannah.gnu.org/gitweb/?p=hurd/gnumach.git;a=commitdiff;h=2a603e88f86bee88e013c2451eacf076fbcaed81 <gg0> but i don't think i was on real hardware at that time diff --git a/open_issues/smp.mdwn b/open_issues/smp.mdwn index 6496f388..b0287a48 100644 --- a/open_issues/smp.mdwn +++ b/open_issues/smp.mdwn @@ -289,7 +289,7 @@ maillist](https://lists.gnu.org/archive/html/bug-hurd/2018-08/msg00048.html) - [Initial thread in bug-hurd maillist](https://lists.gnu.org/archive/html/bug-hurd/2018-06/msg00048.html) - [SMP in GNU/Hurd FAQ](https://www.gnu.org/software/hurd/faq/smp.html) -- [GNU Mach git repository](http://git.savannah.gnu.org/cgit/hurd/gnumach.git) +- [GNU Mach git repository](https://git.savannah.gnu.org/cgit/hurd/gnumach.git) - [GNU Mach reference manual](https://www.gnu.org/software/hurd/gnumach-doc/) - [**MultiProcessor Specification**](https://pdos.csail.mit.edu/6.828/2011/readings/ia32/MPspec.pdf) - [**ACPI Specification**](http://www.uefi.org/sites/default/files/resources/ACPI%206_2_A_Sept29.pdf) diff --git a/open_issues/sync_but_still_unclean_filesystem.mdwn b/open_issues/sync_but_still_unclean_filesystem.mdwn deleted file mode 100644 index eae98077..00000000 --- a/open_issues/sync_but_still_unclean_filesystem.mdwn +++ /dev/null @@ -1,39 +0,0 @@ -[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled [[GNU Free Documentation -License|/fdl]]."]]"""]] - -[[!tag open_issue_gnumach open_issue_hurd]] - -Also filed as [[!GNU_Savannah_bug 29292]]. - -\#hurd, 2010, end of May / beginning of June - - [runnign sync, but sill unclean filesystem at next boot] - <slpz> guillem: when libpager syncs an object, it sends an m_o_lock_request - and waits (if the synchronous argument was specified) for a - m_o_lock_completed. But m_o_lock_completed only means that dirty pages - have been sent to the translator, and this one still needs to write them - to the backing storage - <slpz> guillem: there's no problem if sync() returns before actually - writting the changes to disk, but this also happens when shutting down - the translator - <slpz> guillem: in theory, locking mechanisms in libpager should prevent - this from happening by keeping track of write operations, but this seems - to fail in some situations - -It helps a lot to run [[`syncfs --synchronous /`|hurd/syncfs]] before issuing -the `halt` or `reboot` command. This will prevent most of the uncleanliness. -Of course, [[hurd/translator/ext2fs]] is meant to be doing this to-disk -synchronization internally upon translator shutdown, but evidently it doesn't -in all cases. - -Apparently diskfs simply does not set filesystems as read-only: -<http://lists.gnu.org/archive/html/bug-hurd/2011-08/msg00024.html>. - -A patch was applied, and the sync issue does not seem to happen any more. diff --git a/open_issues/systemd.mdwn b/open_issues/systemd.mdwn index dc8aa6e2..1055a196 100644 --- a/open_issues/systemd.mdwn +++ b/open_issues/systemd.mdwn @@ -9,8 +9,6 @@ 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]] - * <http://www.freedesktop.org/wiki/Software/systemd> * <http://0pointer.de/blog/projects/systemd.html>, diff --git a/open_issues/time.mdwn b/open_issues/time.mdwn index 99c2cbe9..425a7a82 100644 --- a/open_issues/time.mdwn +++ b/open_issues/time.mdwn @@ -180,7 +180,7 @@ not get a define for `HZ`, which is then defined with a fallback value of 60. <braunr> keep in mind rpctrace doesn't behave like ptrace at all <braunr> it acts as a proxy <braunr> nalaginrut: - http://git.savannah.gnu.org/cgit/hurd/glibc.git/commit/?h=rbraun/getclktck_100_hz&id=90404d6d1aa01f6ce1557841f5a675bb6a30f508 + https://git.savannah.gnu.org/cgit/hurd/glibc.git/commit/?h=rbraun/getclktck_100_hz&id=90404d6d1aa01f6ce1557841f5a675bb6a30f508 <braunr> nalaginrut: you need to add it to the debian eglibc patch list, rebuild the packages, and install the resulting .debs <braunr> if you have trouble doing it, i'll make packages when i have time @@ -786,7 +786,7 @@ not get a define for `HZ`, which is then defined with a fallback value of 60. <braunr> 04:53 < nalaginrut> braunr: BTW, where is the patch/ <braunr> there is hardly anyone here at 5am <braunr> nalaginrut: - http://git.savannah.gnu.org/cgit/hurd/glibc.git/log/?h=rbraun/clock_t_centiseconds + https://git.savannah.gnu.org/cgit/hurd/glibc.git/log/?h=rbraun/clock_t_centiseconds <nalaginrut> braunr: thanks for that, but why not use a constant for 100? <braunr> nalaginrut: i don't know where to define it <braunr> it's glibc, you don't define new stuff mindlessly diff --git a/open_issues/cvs_todo_file.mdwn b/open_issues/todo.mdwn index a42e6dca..0ea5967a 100644 --- a/open_issues/cvs_todo_file.mdwn +++ b/open_issues/todo.mdwn @@ -9,10 +9,10 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] -[[!meta title="CVS TODO file"]] +[[!meta title="TODO file"]] [[!tag open_issue_hurd]] The canonical [TODO -file](http://savannah.gnu.org/cgi-bin/viewcvs/~checkout~/hurd/hurd/TODO?rev=HEAD&content-type=text/plain) -from the CVS archive. +file](https://git.savannah.gnu.org/cgit/hurd/hurd.git/plain/TODO) +from the git archive. diff --git a/public_hurd_boxen/installation.mdwn b/public_hurd_boxen/installation.mdwn index 04ab5cd8..28a03b19 100644 --- a/public_hurd_boxen/installation.mdwn +++ b/public_hurd_boxen/installation.mdwn @@ -15,7 +15,7 @@ This page documents how installation of some new machines is being done. # [[zenhost]] For those on [[zenhost]], we use -*[install_crosshurd](http://git.savannah.gnu.org/cgit/hurd/incubator.git/log/?h=install_crosshurd)*. +*[install_crosshurd](https://git.savannah.gnu.org/cgit/hurd/incubator.git/log/?h=install_crosshurd)*. Another option might be switching to <http://www.informatik.uni-koeln.de/fai/> or a equivalent system. @@ -87,7 +87,7 @@ Steps for *install_crosshurd*: * if it's a Xen domU: - # sudo apt-get --purge install libc0.3-xen libc0.3-i686- + # sudo apt --purge install libc0.3-xen libc0.3-i686- * As needed: diff --git a/recent_changes.mdwn b/recent_changes.mdwn deleted file mode 100644 index 8b137891..00000000 --- a/recent_changes.mdwn +++ /dev/null @@ -1 +0,0 @@ - diff --git a/rump_kernel.mdwn b/rump_kernel.mdwn deleted file mode 100644 index 71b376e0..00000000 --- a/rump_kernel.mdwn +++ /dev/null @@ -1,44 +0,0 @@ -[[!meta copyright="Copyright © 2009, 2010 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled [[GNU Free Documentation -License|/fdl]]."]]"""]] - - -# Discussion - - The rump kernels provide existing real world drivers from netbsd. Since DDE no longer seems like a promising approach to get drivers for the Hurd, it appears that rump kernels are the best alternative. It already does the hard work of providing an environment where the foreign drivers can run, and offers the additional benefit of being externally maintained. Rump also offers the necessary facilities for running all drivers in separate userspace processes, which is more desirable than drivers running in the microkernel. - - - * [[community/gsoc/project ideas/driver glue code]] - - * [[open issues/user-space device drivers]] - - * [[open issues/device drivers and io systems]] - ---- - -# Documentation - - * <http://rumpkernel.org/> - - * <http://www.fixup.fi/misc/usenix-login-2015/login_oct15_02_kantee.pdf> - - This is an an opinion paper that explains why operating systems need compartmentalized kernel drivers. - - * <https://github.com/rumpkernel/wiki/wiki/Tutorial:-Getting-started> - - A tutorial introduction for those interested in using and deploying rump kernels. - - * <https://core.ac.uk/display/41816390> - - "User space approach to audio device driving on UNIX-like systems" by Robert Millan Hernandez. - - -# Source Code - - * <https://github.com/rumpkernel> diff --git a/shortcuts.mdwn b/shortcuts.mdwn index 85d4d386..5de19e8c 100644 --- a/shortcuts.mdwn +++ b/shortcuts.mdwn @@ -97,11 +97,11 @@ ikiwiki will include your shortcut in the standard underlay. ## Savannah * [[!shortcut name=GNU_Savannah_Git_hurd_gnumach - url="http://git.savannah.gnu.org/cgit/hurd/gnumach.git/commit/?id=%s" + url="https://git.savannah.gnu.org/cgit/hurd/gnumach.git/commit/?id=%s" desc="hurd/gnumach.git commit %s"]] * [[!shortcut name=GNU_Savannah_Git_hurd_hurd - url="http://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?id=%s" + url="https://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?id=%s" desc="hurd/hurd.git commit %s"]] diff --git a/sidebar.mdwn b/sidebar.mdwn index d2582210..b2c7c223 100644 --- a/sidebar.mdwn +++ b/sidebar.mdwn @@ -41,6 +41,7 @@ License|/fdl]]."]]"""]] --- * **[[Debian GNU/Hurd|hurd/running/debian]]** + * **[[Guix GNU/Hurd|hurd/running/Guix]]** * **[[Arch GNU/Hurd|hurd/running/live_cd/]]** * **[[GNU System|hurd/running/gnu]]** diff --git a/source_repositories.mdwn b/source_repositories.mdwn index 68421600..39c3dc80 100644 --- a/source_repositories.mdwn +++ b/source_repositories.mdwn @@ -18,7 +18,7 @@ This page is meant to give some guidelines. Please use good sense or ask on # Git repositories on Savannah -<http://git.savannah.gnu.org/cgit/hurd> +<https://git.savannah.gnu.org/cgit/hurd> * hurd.git -- Hurd meta package; no real content yet * [[hurd/glibc.git|glibc]] -- [[/glibc]] maintenance diff --git a/source_repositories/glibc.mdwn b/source_repositories/glibc.mdwn index a1b60eab..c44de59a 100644 --- a/source_repositories/glibc.mdwn +++ b/source_repositories/glibc.mdwn @@ -10,7 +10,7 @@ is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] There is a repository for maintenance of [[/glibc]] for the Hurd's needs: -<http://git.savannah.gnu.org/cgit/hurd/glibc.git/>. It's mainly used for +<https://git.savannah.gnu.org/cgit/hurd/glibc.git/>. It's mainly used for testing glibc's master branch, but with all the patches that we need on top of it, and also for development and sharing of (Hurd-specific) glibc patches. diff --git a/source_repositories/incubator.mdwn b/source_repositories/incubator.mdwn index 6d61a9e7..5bb6fc63 100644 --- a/source_repositories/incubator.mdwn +++ b/source_repositories/incubator.mdwn @@ -9,7 +9,7 @@ is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] There is a repository for *this*, and *that*, and *everything* -- the -*incubator*: <http://git.savannah.gnu.org/cgit/hurd/incubator.git/>. +*incubator*: <https://git.savannah.gnu.org/cgit/hurd/incubator.git/>. As the `README` file in the `master` branch says, the development of the various software happens in separate branches. diff --git a/toolchain/logs b/toolchain/logs deleted file mode 160000 -Subproject b9d5ce62343d50df7800d02ae97790ea9e530bd diff --git a/unsorted/InstallTips.mdwn b/unsorted/InstallTips.mdwn index 46b485ec..ed314979 100644 --- a/unsorted/InstallTips.mdwn +++ b/unsorted/InstallTips.mdwn @@ -73,8 +73,8 @@ You should have booted the kernel now, check output to see if it detects your ne Be sure to issue - apt-get update - apt-get upgrade + apt update + apt upgrade Before running x run the console diff --git a/user/Sergio_Lopez.mdwn b/user/Sergio_Lopez.mdwn index ab5ed1f1..5075b8e9 100644 --- a/user/Sergio_Lopez.mdwn +++ b/user/Sergio_Lopez.mdwn @@ -30,7 +30,7 @@ This work has two objectives: #### Trying it I've commited this work to this branch: -<http://git.savannah.gnu.org/cgit/hurd/gnumach.git/log/?h=k0ro/advisory_pageout/master> +<https://git.savannah.gnu.org/cgit/hurd/gnumach.git/log/?h=k0ro/advisory_pageout/master> You'll also need the counterpart for user space: diff --git a/user/arnuld.mdwn b/user/arnuld.mdwn index f14c72d0..63164e87 100644 --- a/user/arnuld.mdwn +++ b/user/arnuld.mdwn @@ -2,27 +2,28 @@ ## General -* Name: arnuld uttre +* Name: arnuld * Email: arnuld.mizong (at) gmail (dot) com * Country: India * Homepage: <http://www.lispmachine.wordpress.com> +## Experience -## Education +Half a decade of C Programming on Linux. Trivial Toy programs in two dozen or more languages. -* B.Sc. (with Comp. App) - Panjab Univeristy, Chandigarh +## GNU Art +Being inspired by GNU, I have created some copyleft art. It is mentioned on GNU website too in "GNU Art on other sites" section here: -## Professional +<https://www.gnu.org/graphics/graphics.html> -* I was a Salesman (sold Financial Products) for 2 years +For original links, go here: +Copyleft Art: <https://lispmachine.wordpress.com/2007/09/01/copyleft-logo/> -## Future Plans +Copyleft in Hebrew: <https://lispmachine.wordpress.com/2007/09/01/copyleft-logo-hebrew/> -* I am learning skills to finish what RMS started, GNU/Hurd microkernel. Then replace Linux kernel with Hurd, with GPLv3 of course. - -* Yes, I want to learn Jeet Kune Do. I love it as much as I love the copyleft. +Hagnus Art: <https://lispmachine.wordpress.com/2007/08/01/hagnus-logos/> diff --git a/user/flaviocruz.mdwn b/user/flaviocruz.mdwn index c4d3db69..850e2271 100644 --- a/user/flaviocruz.mdwn +++ b/user/flaviocruz.mdwn @@ -14,7 +14,7 @@ Email: flaviocruz at gmail dot com Some [Hurd stuff](http://opensvn.csie.org/leic/hurd/) -And code: [cl-hurd](http://git.savannah.gnu.org/cgit/hurd/incubator.git/log/?h=clisp) +And code: [cl-hurd](https://git.savannah.gnu.org/cgit/hurd/incubator.git/log/?h=clisp) ## Summer session @@ -71,8 +71,8 @@ Creating an extensible translator library in lisp using the mig generated stubs. ### Project dependencies - CLISP -- [CFFI](http://common-lisp.net/project/cffi/) (apt-get installable) -- [Flexi streams](http://www.weitz.de/flexi-streams/) (apt-get installable) +- [CFFI](http://common-lisp.net/project/cffi/) (apt installable) +- [Flexi streams](http://www.weitz.de/flexi-streams/) (apt installable) - [Trivial garbage](http://www.cliki.net/trivial-garbage) (not in debian repositories) - [cl-zip](http://common-lisp.net/project/zip/) (only needed for the zip translator) - [cl-irc](http://common-lisp.net/project/cl-irc/) (for the irc translator) diff --git a/user/tlecarrour/porting_guide_for_dummies.mdwn b/user/tlecarrour/porting_guide_for_dummies.mdwn index 772be2bb..fe297102 100644 --- a/user/tlecarrour/porting_guide_for_dummies.mdwn +++ b/user/tlecarrour/porting_guide_for_dummies.mdwn @@ -27,12 +27,12 @@ Test on Hurd ### Installing the required files -As `apt-get source` will download and extract many files, you may want to create a dedicated folder for the package and work from there. +As `apt source` will download and extract many files, you may want to create a dedicated folder for the package and work from there. mkdir PACKAGE cd PACKAGE - sudo apt-get build-dep PACKAGE - apt-get source PACKAGE + sudo apt build-dep PACKAGE + apt source PACKAGE ### Trying to build the package diff --git a/user/zhengda.mdwn b/user/zhengda.mdwn index a7f57f35..9422b02c 100644 --- a/user/zhengda.mdwn +++ b/user/zhengda.mdwn @@ -13,7 +13,7 @@ porting DDE developed by DROPS to the Hurd, and it will still run in the user sp The introduction of DDE/DDEKit can be found in [here](http://wiki.tudos.org/DDE/DDEKit) and more information can be found [here](http://os.inf.tu-dresden.de/pipermail/l4-hackers/2009/004291.html). DDE/DDEKit is a library, and it should be compiled with the code of Linux or FreeBSD drivers. DDE Linux26 is still under development and it can now support network and block devices (but doesn't support SCSI). ##The current status -Currently a few NIC cards work now. I tested pcnet32, e100, e1000, ne2k-pci and rtl8139 in VMWare and Qemu. But the DDE e100 driver cannot work for some e100 cards as currently DDE doesn't support firmware. Someone also reported sis900 cannot work, unfortunately, I cannot test it myself. I appreciate if someone can try some other NIC drivers and give me some feedbback. Please run DDE with GNUMach in the [master-user_level_drivers](http://git.savannah.gnu.org/cgit/hurd/gnumach.git/) branch. +Currently a few NIC cards work now. I tested pcnet32, e100, e1000, ne2k-pci and rtl8139 in VMWare and Qemu. But the DDE e100 driver cannot work for some e100 cards as currently DDE doesn't support firmware. Someone also reported sis900 cannot work, unfortunately, I cannot test it myself. I appreciate if someone can try some other NIC drivers and give me some feedbback. Please run DDE with GNUMach in the [master-user_level_drivers](https://git.savannah.gnu.org/cgit/hurd/gnumach.git/) branch. ## My work I separate DDE Linux26 to 2 parts: libddekit and libdde_linux26. I also provide a library called libmachdev on the top of the Linux code to provide the Mach device interface, so it is easy for the user to compile a Linux driver and run it in the Hurd. The latest code can be found in the dde branch of the incubator repository. |