diff options
| -rw-r--r-- | GPL.mdwn | 22 | ||||
| -rw-r--r-- | advantages.mdwn | 2 | ||||
| -rw-r--r-- | community.mdwn | 14 | ||||
| -rw-r--r-- | copyright.mdwn | 2 | ||||
| -rw-r--r-- | extensibility.mdwn | 3 | ||||
| -rw-r--r-- | faq/posix_compatibility.mdwn | 6 | ||||
| -rw-r--r-- | hurd/documentation/translator_primer.mdwn | 21 | ||||
| -rw-r--r-- | hurd/fsysopts.mdwn | 2 | ||||
| -rw-r--r-- | hurd/running/debian.mdwn | 56 | ||||
| -rw-r--r-- | hurd/running/debian/qemu_image.mdwn | 51 | ||||
| -rw-r--r-- | hurd/running/distrib.mdwn | 34 | ||||
| -rw-r--r-- | hurd/running/gnu.mdwn | 4 | ||||
| -rw-r--r-- | hurd/what_is_the_gnu_hurd.mdwn | 3 | ||||
| -rw-r--r-- | index.mdwn | 4 | ||||
| -rw-r--r-- | index/discussion.mdwn | 17 | ||||
| -rw-r--r-- | ipc.mdwn | 5 | ||||
| -rw-r--r-- | microkernel/mach/deficiencies.mdwn | 3288 | ||||
| -rw-r--r-- | microkernel/mach/documentation.mdwn | 3 | ||||
| -rw-r--r-- | open_issues/glibc.mdwn | 3453 | ||||
| -rw-r--r-- | recent_changes.mdwn | 13 | ||||
| -rw-r--r-- | unix.mdwn | 2 | ||||
| -rw-r--r-- | user/MutoShack.mdwn | 3 |
22 files changed, 159 insertions, 6849 deletions
diff --git a/GPL.mdwn b/GPL.mdwn new file mode 100644 index 00000000..9794871c --- /dev/null +++ b/GPL.mdwn @@ -0,0 +1,22 @@ +[[!meta copyright="Copyright © 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]]."]]"""]] + +The GNU General Public License (GPL) is a [Free Software](https://www.gnu.org/philosophy/free-sw.html) license created by Richard Stallman in 1989 for Free Software creators. The GPL grants users the Four Freedoms: + + +* The freedom to run the program as you wish, for any purpose (freedom 0). +* The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this. +* The freedom to redistribute copies so you can help others (freedom 2). +* The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this. + + +Since it's debut, the license has become extremely popular & wide-spread. The GPL has gone through 3 revisions, with GPLv3 being the latest. + +GPLv3 allows any user to access, modify, and redistribute the source code, given that the redistributed version of the software is also released as GPLv3. For example, if you create a pice of software named "FreedomJuice" under the GPLv3, and I download & moify it and name it "xFreedomJuicex", I cannot release xFreedomJuicex under the MIT license, it has to be GPLv3 as well. diff --git a/advantages.mdwn b/advantages.mdwn index 94e64c33..0cb4abed 100644 --- a/advantages.mdwn +++ b/advantages.mdwn @@ -14,7 +14,7 @@ License|/fdl]]."]]"""]] The GNU Hurd has a number of enticing features: It's free software, so anybody can use, modify, and redistribute it under the -terms of the [[GNU General Public License (GPL)|GPL]]. +terms of the [[GNU General Public License v3 (GPLv3)|GPL]]. It's compatible as it provides a familiar programming and user environment. For all intents and purposes, the Hurd provides the same facilities as a modern diff --git a/community.mdwn b/community.mdwn index 5327c1f9..f74c01d6 100644 --- a/community.mdwn +++ b/community.mdwn @@ -9,8 +9,8 @@ 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]]."]]"""]] -There is an expanding community of people developing and running GNU/Hurd -systems. +There is an ever expanding community of people developing and running GNU/Hurd +systems! This page tries to list all the places on the Web where we commonly hang out. [[Communication]] -- How communication and coordination works within the group. @@ -45,9 +45,9 @@ Further ways of getting in contact or getting information: # Hurd User Groups * [[THUG]] - Toronto (GNU/)Hurd User Group -* [[CHUG]] - California Hurd User Group +* [[CHUG]] - Californian HUG * [[DHUG]] - Dunedin (GNU/)Hurd User Group -* [[HurdBr]] - Hurd Br is a brasilian, portuguese speaking, HUG -* [HurdEs](http://hurd.es.gnu.org/) -* [Hurdfr.org](http://www.hurdfr.org/) -* [HurdIt](http://hurd-it.sf.net/) +* [[HurdBr]] - Brasilian, portuguese speaking, HUG +* [HurdEs](http://hurd.es.gnu.org/) - Currently down. Spanish HUG +* [Hurdfr.org](http://www.hurdfr.org/) - Currently down. French HUG +* [HurdIt](http://hurd-it.sf.net/) - An Italian speaking HUG diff --git a/copyright.mdwn b/copyright.mdwn index 39854057..8de1c44f 100644 --- a/copyright.mdwn +++ b/copyright.mdwn @@ -1,2 +1,2 @@ Copyright © 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, -2013, 2014, 2015, 2016, 2017, 2018 The Contributing Authors +2013, 2014, 2015, 2016, 2017, 2018, 2019 - The Contributing Authors diff --git a/extensibility.mdwn b/extensibility.mdwn index 17cd5e51..ef89d5f2 100644 --- a/extensibility.mdwn +++ b/extensibility.mdwn @@ -16,3 +16,6 @@ not generally facilitate the hooking of [[system call]]s. For instance, there i no way to hook into the virtual file system. This has motivated the introduction of separate, parallel interfaces by both the GNOME and KDE projects to provide users a more integrated view of their objects. + +# External +* The Wikipedia article on [[!wikipedia extensibility]] diff --git a/faq/posix_compatibility.mdwn b/faq/posix_compatibility.mdwn index 2212a7d4..db7989a6 100644 --- a/faq/posix_compatibility.mdwn +++ b/faq/posix_compatibility.mdwn @@ -13,6 +13,8 @@ License|/fdl]]."]]"""]] [[!meta title="POSIX compatibility"]] +Many computer operating systems strive to be POSIX (Portable Operating System Interface) compliant, as it makes cross-compiling and program portability much easier than having to package something for every new distribution. + Is it favorable of rather a hindrance to be compatible to POSIX and similar standards? @@ -33,3 +35,7 @@ striving for total POSIX compliance -- and the high-level programs (that is, their users) may not even notice this, but we would avoid a lot of overhead that comes with wrapping the [[Hurd interfaces|hurd/interface]] to be POSIX compliant. + +# External +* The Open Groups [POSIX Specification](https://pubs.opengroup.org/onlinepubs/9699919799/) +* Wikipedia [article on POSIX](https://en.wikipedia.org/wiki/POSIX) diff --git a/hurd/documentation/translator_primer.mdwn b/hurd/documentation/translator_primer.mdwn index bbfb3649..35eab2fb 100644 --- a/hurd/documentation/translator_primer.mdwn +++ b/hurd/documentation/translator_primer.mdwn @@ -28,13 +28,11 @@ to enable you to easily try three of them: To try out the simplest of translators, you can go the following simple steps: $ touch hello - $ cat hello + $ cat hello $ settrans hello /hurd/hello $ cat hello "Hello World!" - $ settrans -g hello - $ cat hello - $ + $ fsysopts hello /hurd/hello --contents='Hello World! ' @@ -42,22 +40,23 @@ To try out the simplest of translators, you can go the following simple steps: > ' $ cat hello Hello GNU! - $ - -What you do with these steps is first verifying that the file "hello" is empty. + + $ settrans -g hello + $ cat hello +What you do with these steps is first creating the file "hello" and verifying that it is empty. -Then you setup the translator /hurd/hello in the file/node hello. +Then you setup the translator `/hurd/hello` in the file/node `hello`. -After that you check the contents of the file, and the translator returns "Hello World!". +After that, you check the contents of the file, and the translator returns "Hello World!". Because you are a curious hacker, you wonder what filesystem options this node has. It turns out that the hello translator uses a "contents" option. We can change what the hello -translator returns with another call to fsysopts. +translator returns with another call to [[fsysopts]]. To finish it, you remove the translator from the file "hello" (and tell any active running instances to go away) -via "settrans -g hello". +via "`settrans --g hello`", which is shorthand for "`settrans --goaway hello`" Having done that, verify that now the file is empty again. ### Transparent FTP diff --git a/hurd/fsysopts.mdwn b/hurd/fsysopts.mdwn index ff30f31d..bafe2bc9 100644 --- a/hurd/fsysopts.mdwn +++ b/hurd/fsysopts.mdwn @@ -8,7 +8,7 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] -Get or set command line options for a running [[translator]]. +fsysopts, or <strong>F</strong>ile<strong>SYS</strong>tem<strong>OPT</strong>ions, Gets or sets command line options for a running [[translator]]. See [[documentation/translators#manage]]. diff --git a/hurd/running/debian.mdwn b/hurd/running/debian.mdwn index c52fbf75..b758fd52 100644 --- a/hurd/running/debian.mdwn +++ b/hurd/running/debian.mdwn @@ -1,8 +1,11 @@ [[!meta title="Debian GNU/Hurd"]] -# Debian Resources -- Official page about the Debian GNU/Hurd port: [Debian GNU/Hurd](http://www.debian.org/ports/hurd/) -- Debian [[FAQ]] — Frequently Asked Questions +Debian GNU/Hurd is an effort to port the Debian distribution to the Hurd. Around 75% of Debian packages can already be run under Debian GNU/Hurd, which makes it very usable. See the [[Status]] of the Debian port for more information. + +<!-- I don't know what it means that /etc/mtab -> /proc/mounts, but this is what I could interpret. + It was simply a line (h1, for some reason, on this page and it looked out of place. Correct or even delete this if it makes no sense --> + +One noteable difference in this port, is that `/etc/mtab` -> `/proc/mounts` ## QEMU Image [[!inline pages=hurd/running/debian/qemu_image raw=yes feeds=no]] @@ -17,23 +20,11 @@ * [[Patch_submission]] — How to submit patches for build failures - [[Creating_image_tarball]] -# Additional Information -- [Presentation](http://people.debian.org/~mbanck/talks/hurd_lt2004/html/) - *Debian GNU/Hurd*, [[MichaelBanck]], LinuxTag 2004 Karlsruhe -- [[Status]] -- [Archive Qualification](http://wiki.debian.org/ArchiveQualification/hurd-i386) - - -# `/etc/mtab` -> `/proc/mounts` - ## IRC, freenode, #hurd, 2014-02-12 <braunr> hm, there is something weird - <braunr> after successfully installing (with the new installer cd), and - rebooting, system init fails because fsck can't be run on /home (a - separate partition) - <braunr> it can't fsck because at that point, /home is already mounted, and - indeed the translator is running + <braunr> after successfully installing (with the new installer cd), and rebooting, system init fails because fsck can't be run on /home (a separate partition) + <braunr> it can't fsck because at that point, /home is already mounted, and indeed the translator is running <braunr> teythoon: any idea what might cause that ? <teythoon> me ? <teythoon> no @@ -52,30 +43,24 @@ <teythoon> i believe they dropped that <youpi> err, but something must be creating it for newer systems <teythoon> good point - <braunr> well, except for these small details, everything went pretty - smooth + <braunr> well, except for these small details, everything went pretty smooth <braunr> both on ide and ahci <youpi> it seems /etc/mtab gets created at boot <youpi> (on Linux I mean) - <teythoon> youpi: i cannot find the init script, but i'm sure that it was - there + <teythoon> youpi: i cannot find the init script, but i'm sure that it was there <youpi> I can't find it either on the installed system... <azeem> maybe pere or rleigh in #debian-hurd can help ## IRC, freenode, #hurd, 2014-02-13 - <braunr> 6<--60(pid1698)->dir_lookup ("var/run/mtab" 4194305 0) = 0 3 - "/run/mtab" (null) + <braunr> 6<--60(pid1698)->dir_lookup ("var/run/mtab" 4194305 0) = 0 3 "/run/mtab" (null) <braunr> looks like /etc/mtab isn't actually used anymore <teythoon> it never was on hurd <tomodach1> braunr: well it is generated i believe from mounted filesystems - <tomodach1> if its still around there is a reason for it, like posix - compatiblity perhaps? - <braunr> well the problem is that, as mentioned in pere's thread on - bug-hurd, some tools now expect /var/run/mtab instead of /etc/mtab - <braunr> and since nothing currently creates this file, these tools, such - as df, are lost + <tomodach1> if its still around there is a reason for it, like posix compatiblity perhaps? + <braunr> well the problem is that, as mentioned in pere's thread on bug-hurd, some tools now expect /var/run/mtab instead of /etc/mtab + <braunr> and since nothing currently creates this file, these tools, such as df, are lost <braunr> they can't find the info they're looking for @@ -87,11 +72,14 @@ <pere> yes. I recommended fixing it in the hurd package. (BTS #737759) <braunr> yes i saw but was there any action taken ? <pere> did not check - <teythoon> i thought youpi mentioned that it is fixed in the libc and we - just need to rebuild coreutils or something + <teythoon> i thought youpi mentioned that it is fixed in the libc and we just need to rebuild coreutils or something <pere> yes <braunr> oh ok <braunr> but doesn't that mean it will use /etc/mtab ? - <pere> if I was a hurd porter, I would fix it in hurd while waiting for a - fix in coreutils, just to save people for wondering about the breakage, - but I am not the most patient of developers. :) + <pere> if I was a hurd porter, I would fix it in hurd while waiting for a fix in coreutils, just to save people for wondering about the breakage, but I am not the most patient of developers. :) + +# Externel +* Official page about the Debian GNU/Hurd port: [Debian GNU/Hurd](http://www.debian.org/ports/hurd/) +* Debian [[FAQ]] — Frequently Asked Questions +* [Presentation](http://people.debian.org/~mbanck/talks/hurd_lt2004/html/) -Debian GNU/Hurd*, [[MichaelBanck]], LinuxTag 2004 Karlsruhe +* [Archive Qualification](http://wiki.debian.org/ArchiveQualification/hurd-i386) diff --git a/hurd/running/debian/qemu_image.mdwn b/hurd/running/debian/qemu_image.mdwn index c25b76ab..fe1b7444 100644 --- a/hurd/running/debian/qemu_image.mdwn +++ b/hurd/running/debian/qemu_image.mdwn @@ -14,23 +14,50 @@ as <https://cdimage.debian.org/cdimage/ports/latest/hurd-i386/debian-hurd.img.ta Usage: -* Install qemu-kvm via your distros packages. -* Download the debian image - $ `wget https://cdimage.debian.org/cdimage/ports/latest/hurd-i386/debian-hurd.img.tar.gz` -* Unpack it. - $ `tar -xz < debian-hurd.img.tar.gz` -* Run it - $ `kvm -m 1G -drive cache=writeback,file=$(echo debian-hurd-*.img) -net user,hostfwd=tcp:127.0.0.1:2222-:22` - # Optionally 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). +* Install qemu-kvm via your distribution's package manager (it might just be named qemu) + +* Download the debian image: + +<!-- Codeblocks nested in lists are garbage in Markdown. The only clean way to do this is by adding a comment after every list entry. Sorry about this!--> + + $ wget https://cdimage.debian.org/cdimage/ports/latest/hurd-i386/debian-hurd.img.tar.gz + +* Unpack it: + +<!-- Yes, another comment. I can leave these empty but then again I can fill them. --> + + $ tar -xz < debian-hurd.img.tar.gz + +* Run it: + +<!-- A world in which nobody washes their dishes is a dishtopia --> + + $ kvm -m 1G -drive cache=writeback,file=$(echo debian-hurd-*.img) -net user,hostfwd=tcp:127.0.0.1:2222-:22 + * Login as root (the root password is empty) -* set up a root password with passwd + +* Set up a root password with passwd + +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 + +Or, if your machine does not allow for KVM acceleration, omit `--enable-kvm` from the command. + + Please also read the README file: <https://cdimage.debian.org/cdimage/ports/latest/hurd-i386/README> +<!-- It is unconventional, in wikis, to write external links like [...](http://...). + Usually a link to an external site should always be fully visible, but I think + people can understand where these lead, but revert if this is a bad idea.--> + If you have troubles extracting the image, you can use -the gz version <https://cdimage.debian.org/cdimage/ports/latest/hurd-i386/debian-hurd.img.gz>, -the zip version <https://cdimage.debian.org/cdimage/ports/latest/hurd-i386/debian-hurd.img.zip>, -or even the plain version <https://cdimage.debian.org/cdimage/ports/latest/hurd-i386/debian-hurd.img> (5GiB!) +the [gz version](https://cdimage.debian.org/cdimage/ports/latest/hurd-i386/debian-hurd.img.gz), +the [zip version](https://cdimage.debian.org/cdimage/ports/latest/hurd-i386/debian-hurd.img.zip), +or even the [plain version](https://cdimage.debian.org/cdimage/ports/latest/hurd-i386/debian-hurd.img) (5GiB!) See the discussion about [[hurd/running/qemu/writeback_caching]]. diff --git a/hurd/running/distrib.mdwn b/hurd/running/distrib.mdwn index 8c411fd0..357d840a 100644 --- a/hurd/running/distrib.mdwn +++ b/hurd/running/distrib.mdwn @@ -9,45 +9,41 @@ distributions in regard to ethical criteria. Please visit <http://www.gnu.org/distros/free-system-distribution-guidelines.html> to learn what those standards are."""]] -Working distributions of GNU/Hurd: +There are several GNU distributions that are built on the Hurd. If you develop a Hurd-based distro or know of one that isn't on this list yet, feel free to add it! + +###Working distributions of GNU/Hurd: * [[Debian]] -GNU/Hurd distributions in early stages of development: +###GNU/Hurd distributions in early stages of development: * [[Arch|arch_hurd]] (features a LiveCD) * [[Nix]] -Defunct GNU/Hurd distributions: +###Defunct GNU/Hurd distributions: * Bee GNU/Hurd. Castellano distribution, pkgsrc package based. - * [[GNU]] * Unofficial port to Gentoo and the portage system. It was [announced](http://forums.gentoo.org/viewtopic.php?t=41939&postdays=0&postorder=asc&start=0) March 17, 2003 in the Gentoo forums, but development stopped at some point. - IRC, freenode, #hurd, 2013-01-15: +####IRC, freenode, #hurd, 2013-01-15: <WhiteKIBA> we are trying to revive Gentoo/hurd <WhiteKIBA> we are using debian as a start - <WhiteKIBA> we installed portage on debian and are now bootstrapping - the system into a folder + <WhiteKIBA> we installed portage on debian and are now bootstrapping the system into a folder <WhiteKIBA> except glibc everything seems fine - <_d3f> braunr: http://wiki.rout0r.org/index.php/Gentoo/Hurd/en - if you - want to know more. + <_d3f> braunr: http://wiki.rout0r.org/index.php/Gentoo/Hurd/en - if you want to know more. - IRC, freenode, #hurd, 2013-02-01: +####IRC, freenode, #hurd, 2013-02-01: - <WhiteKIBA> natsukao: http://wiki.rout0r.org/index.php/Gentoo/Hurd/en I - am working on it - <WhiteKIBA> if i can get glibc to compile correctly i can create a - stage3 but at the moment it fails + <WhiteKIBA> natsukao: http://wiki.rout0r.org/index.php/Gentoo/Hurd/en I am working on it + <WhiteKIBA> if i can get glibc to compile correctly i can create a stage3 but at the moment it fails - IRC, freenode, #hurd, 2013-02-02: +####IRC, freenode, #hurd, 2013-02-02: <alexxy> WhiteKIBA: you may be interested in my try to run gentoo/hurd - <alexxy> WhiteKIBA: - http://omrb.pnpi.spb.ru/gitweb/?p=gentoo/hurd.git;a=summary + <alexxy> WhiteKIBA: http://omrb.pnpi.spb.ru/gitweb/?p=gentoo/hurd.git;a=summary # Using @@ -72,7 +68,7 @@ about getting applications to work (if possible). </dl> -# Misc. +# External -* [Ognyan Kulev Collection](http://debian.fmi.uni-sofia.bg/~ogi/hurd/links/index.html) of links (unsupported) +* [Ognyan Kulev Collection](https://web.archive.org/web/20080513192630/http://www.bddebian.com/~wiki/) of links (unsupported) * [2000 Jim Franklin Collection](http://angg.twu.net/the_hurd_links.html) of links diff --git a/hurd/running/gnu.mdwn b/hurd/running/gnu.mdwn index 69a3210a..f6aada87 100644 --- a/hurd/running/gnu.mdwn +++ b/hurd/running/gnu.mdwn @@ -1,6 +1,6 @@ # <a name="The_GNU_Operating_System"> </a> The GNU Operating System -The GNU Operating System, or GNU System as it is more commonly known, will be a +The GNU Operating System, Commonly referred to as simply "The GNU System", is a complete [[Unix]]-like operating system composed entirely of [free software](http://www.gnu.org/philosophy/free-sw.html). The creation of the GNU System is one of the goals of the [GNU Project](http://www.gnu.org/), which was @@ -15,7 +15,7 @@ including [[POSIX|https://en.wikipedia.org/wiki/POSIX]], modularity, and respecting user freedom. Many of these goals are things that the GNU/Hurd can resolve, however the GNU/Hurd is not the most stable operating system yet. -If you are looking for a production ready GNU system, then Debian GNU/Hurd may +If you are looking for a production ready GNU system, then [[hurd/running/Debian]] GNU/Hurd may not be the best choice for you. Debian GNU/Hurd currently lacks 64-bit support, many device drivers, sound support, SMP, and a few other essential bits that provide a flexible operating system. diff --git a/hurd/what_is_the_gnu_hurd.mdwn b/hurd/what_is_the_gnu_hurd.mdwn index 7a7f3d43..8315bfff 100644 --- a/hurd/what_is_the_gnu_hurd.mdwn +++ b/hurd/what_is_the_gnu_hurd.mdwn @@ -11,8 +11,7 @@ License|/fdl]]."]]"""]] [[!meta title="What Is the GNU Hurd?"]] -The Hurd is the GNU project's replacement for [[UNIX]], a popular operating -system [[kernel]]. +The Hurd is the GNU project's replacement for the [[UNIX]] system's [[kernel]]. The Hurd is firstly a collection of protocols formalizing how different components may interact. The protocols are designed to reduce the mutual @@ -62,8 +62,8 @@ See our [[source_repositories]] for the source code. ## Access to a GNU/Hurd System -We provide accounts on our [[public_Hurd_boxen]], and there are also -[[hurd/running/QEMU]] images available. +We provide accounts on our [[public_Hurd_boxen]], and there are also several GNU/Hurd [[Distributions|hurd/running/distrib]] that allow for +[[hurd/running/QEMU]] emulation. # Getting Help diff --git a/index/discussion.mdwn b/index/discussion.mdwn new file mode 100644 index 00000000..1c1cdcd8 --- /dev/null +++ b/index/discussion.mdwn @@ -0,0 +1,17 @@ +[[!meta copyright="Copyright © 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]]."]]"""]] + +Ikiwiki has a "Talk" or "Discussion" feature at the top of the page. + +Interestingly, this feature is seldom used on the Hurd wiki. For information about this feature, please take a look at the article on Wikipedia: + +https://en.wikipedia.org/wiki/Help:Talk_pages + +`MutoShack, March 22, 2019` - I'll go first. How come the footer bar on the homepage isn't updated for 2019? I modified the copyright section, but this page still says "2016 FSF"! Editing the page and viewing the ?updated version does not work, but it displays 2019 just fine on other wiki pages! @@ -11,6 +11,8 @@ License|/fdl]]."]]"""]] *IPC* stands for *inter-process communication*. +Inter-process communication refers to the mechanisms, provided by the operating system, that allow allow processes to manage shared data. + On [[Unix]], inter-process communication can be achieved using pipes. This is inefficient for large amounts of data as the data must be copied. This is generally not a problem as most services are @@ -42,6 +44,9 @@ Continue reading about [[Mach's IPC system|microkernel/mach/IPC]]. * [[RPC]] +# Externel + * Wikipedia artile on [[!wikipedia Inter-process_communication]] + [[!ymlfront data=""" diff --git a/microkernel/mach/deficiencies.mdwn b/microkernel/mach/deficiencies.mdwn index b7927210..8b137891 100644 --- a/microkernel/mach/deficiencies.mdwn +++ b/microkernel/mach/deficiencies.mdwn @@ -1,3289 +1 @@ -[[!meta copyright="Copyright © 2012, 2013, 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]]."]]"""]] - -[[!tag open_issue_documentation open_issue_gnumach]] - -[[!toc levels=2]] - -# Deficiencies - -Mach is a first generational microkernel, and many of mach's implementations are poor. -The result is a complicated code base with many issues. Problems include resource accounting, -scheduling, and too many features inside the kernel. Another problem is mach's IPC is -too flexible and has numerous features. The more features and complex the message passing is, -the slower performance becomes. Mach's IPC ought to be simple enough to maximize performance. - -Mach also doesn't support any read-ahead techniques, so its I/O performance suffers. -Read ahead will have to be implemented inside the kernel. - -There are many optimizations that can be done: - -We could easily get rid of the ihash library making the message provide the address of -the object associated to a receive right, so the only real indirection is the capability, -like in other systems, and yes, buffering adds a bit of complexity. Another example is -merging structures to improve locality or having rights close to their target port, -when there are only a few. This would increase cache efficiency. - -## IRC, freenode, #hurd, 2012-06-29 - - <henrikcozza> I do not understand what are the deficiencies of Mach, the - content I find on this is vague... - <antrik> the major problems are that the IPC architecture offers poor - performance; and that resource usage can not be properly accounted to the - right parties - <braunr> antrik: the more i study it, the more i think ipc isn't the - problem when it comes to performance, not directly - <braunr> i mean, the implementation is a bit heavy, yes, but it's fine - <braunr> the problems are resource accounting/scheduling and still too much - stuff inside kernel space - <braunr> and with a very good implementation, the performance problem would - come from crossing address spaces - <braunr> (and even more on SMP, i've been thinking about it lately, since - it would require syncing mmu state on each processor currently using an - address space being modified) - <antrik> braunr: the problem with Mach IPC is that it requires too many - indirections to ever be performant AIUI - <braunr> antrik: can you mention them ? - <antrik> the semantics are generally quite complex, compared to Coyotos for - example, or even Viengoos - <braunr> antrik: the semantics are related to the message format, which can - be simplified - <braunr> i think everybody agrees on that - <braunr> i'm more interested in the indirections - <antrik> but then it's not Mach IPC anymore :-) - <braunr> right - <braunr> 22:03 < braunr> i mean, the implementation is a bit heavy, yes, - but it's fine - <antrik> that's not an implementation issue - <braunr> that's what i meant by heavy :) - <braunr> well, yes and no - <braunr> Mach IPC have changed over time - <braunr> it would be newer Mach IPC ... :) - <antrik> the fact that data types are (supposed to be) transparent to the - kernel is a major part of the concept, not just an implementation detail - <antrik> but it's not just the message format - <braunr> transparent ? - <braunr> but they're not :/ - <antrik> the option to buffer in the kernel also adds a lot of complexity - <braunr> buffer in the kernel ? - <braunr> ah you mean message queues - <braunr> yes - <antrik> braunr: eh? the kernel parses all the type headers during transfer - <braunr> yes, so it's not transparent at all - <antrik> maybe you have a different understanding of "transparent" ;-) - <braunr> i guess - <antrik> I think most of the other complex semantics are kinda related to - the in-kernel buffering... - <braunr> i fail to see why :/ - <antrik> well, it allows ports rights to be destroyed while a message is in - transfer. a lot of semantics revolve around what happens in that case - <braunr> yes but it doesn't affect performance a lot - <antrik> sure it does. it requires a lot of extra code and indirections - <braunr> not a lot of it - <antrik> "a lot" is quite a relative term :-) - <antrik> compared to L4 for example, it *is* a lot - <braunr> and those indirections (i think you refer to more branching here) - are taken only when appropriate, and can be isolated, improved through - locality, etc.. - <braunr> the features they add are also huge - <braunr> L4 is clearly insufficient - <braunr> all current L4 forks have added capabilities .. - <braunr> (that, with the formal verification, make se4L one of the - "hottest" recent system projects) - <braunr> seL4* - <antrik> yes, but with very few extra indirection I think... similar to - EROS (which claims to have IPC almost as efficient as the original L4) - <braunr> possibly - <antrik> I still fail to see much real benefit in formal verification :-) - <braunr> but compared to other problems, this added code is negligible - <braunr> antrik: for a microkernel, me too :/ - <braunr> the kernel is already so small you can simply audit it :) - <antrik> no, it's not neglible, if you go from say two cache lines touched - per IPC (original L4) to dozens (Mach) - <antrik> every additional variable that needs to be touched to resolve some - indirection, check some condition adds significant overhead - <braunr> if you compare the dozens to the huge amount of inter processor - interrupt you get each time you change the kernel map, it's next to - nothing .. - <antrik> change the kernel map? not sure what you mean - <braunr> syncing address spaces on hundreds of processors each time you - send a message is a real scalability issue here (as an example), where - Mach to L4 IPC seem like microoptimization - <youpi> braunr: modify, you mean? - <braunr> yes - <youpi> (not switchp - <youpi> ) - <braunr> but that's only one example - <braunr> yes, modify, not switch - <braunr> also, we could easily get rid of the ihash library - <braunr> making the message provide the address of the object associated to - a receive right - <braunr> so the only real indirection is the capability, like in other - systems, and yes, buffering adds a bit of complexity - <braunr> there are other optimizations that could be made in mach, like - merging structures to improve locality - <pinotree> "locality"? - <braunr> having rights close to their target port when there are only a few - <braunr> pinotree: locality of reference - <youpi> for cache efficiency - <antrik> hundreds of processors? let's stay realistic here :-) - <braunr> i am .. - <braunr> a microkernel based system is also a very good environment for RCU - <braunr> (i yet have to understand how liburcu actually works on linux) - <antrik> I'm not interested in systems for supercomputers. and I doubt - desktop machines will get that many independant cores any time soon. we - still lack software that could even romotely exploit that - <braunr> hum, the glibc build system ? :> - <braunr> lol - <youpi> we have done a survey over the nix linux distribution - <youpi> quite few packages actually benefit from a lot of cores - <youpi> and we already know them :) - <braunr> what i'm trying to say is that, whenever i think or even measure - system performance, both of the hurd and others, i never actually see the - IPC as being the real performance problem - <braunr> there are many other sources of overhead to overcome before - getting to IPC - <youpi> I completely agree - <braunr> and with the advent of SMP, it's even more important to focus on - contention - <antrik> (also, 8 cores aren't exactly a lot...) - <youpi> antrik: s/8/7/ , or even 6 ;) - <antrik> braunr: it depends a lot on the use case. most of the problems we - see in the Hurd are probably not directly related to IPC performance; but - I pretty sure some are - <antrik> (such as X being hardly usable with UNIX domain sockets) - <braunr> antrik: these have more to do with the way mach blocks than IPC - itself - <braunr> similar to the ext2 "sleep storm" - <antrik> a lot of overhead comes from managing ports (for for example), - which also mostly comes down to IPC performance - <braunr> antrik: yes, that's the main indirection - <braunr> antrik: but you need such management, and the related semantics in - the kernel interface - <braunr> (although i wonder if those should be moved away from the message - passing call) - <antrik> you mean a different interface for kernel calls than for IPC to - other processes? that would break transparency in a major way. not sure - we really want that... - <braunr> antrik: no - <braunr> antrik: i mean calls specific to right management - <antrik> admittedly, transparency for port management is only useful in - special cases such as rpctrace, and that probably could be served better - with dedicated debugging interfaces... - <braunr> antrik: i.e. not passing rights inside messages - <antrik> passing rights inside messages is quite essential for a capability - system. the problem with Mach IPC in regard to that is that the message - format allows way more flexibility than necessary in that regard... - <braunr> antrik: right - <braunr> antrik: i don't understand why passing rights inside messages is - important though - <braunr> antrik: essential even - <youpi> braunr: I guess he means you need at least one way to pass rights - <antrik> braunr: well, for one, you need to pass a reply port with each RPC - request... - <braunr> youpi: well, as he put, the message passing call is overpowered, - and this leads to many branches in the code - <braunr> antrik: the reply port is obvious, and can be optimized - <braunr> antrik: but the case i worry about is passing references to - objects between tasks - <braunr> antrik: rights and identities with the auth server for example - <braunr> antrik: well ok forget it, i just recall how it actually works :) - <braunr> antrik: don't forget we lack thread migration - <braunr> antrik: you may not think it's important, but to me, it's a major - improvement for RPC performance - <antrik> braunr: how can seL4 be the most interesting microkernel - then?... ;-) - <braunr> antrik: hm i don't know the details, but if it lacks thread - migration, something is wrong :p - <braunr> antrik: they should work on viengoos :) - <antrik> (BTW, AIUI thread migration is quite related to passive objects -- - something Hurd folks never dared seriously consider...) - <braunr> i still don't know what passive objects are, or i have forgotten - it :/ - <antrik> no own control threads - <braunr> hm, i'm still missing something - <braunr> what do you refer to by control thread ? - <braunr> with* - <antrik> i.e. no main loop etc.; only activated by incoming calls - <braunr> ok - <braunr> well, if i'm right, thomas bushnel himself wrote (recently) that - the ext2 "sleep" performance issue was expected to be solved with thread - migration - <braunr> so i guess they definitely considered having it - <antrik> braunr: don't know what the "sleep peformance issue" is... - <braunr> http://lists.gnu.org/archive/html/bug-hurd/2011-12/msg00032.html - <braunr> antrik: also, the last message in the thread, - http://lists.gnu.org/archive/html/bug-hurd/2011-12/msg00050.html - <braunr> antrik: do you consider having a reply port being an avoidable - overhead ? - <antrik> braunr: not sure. I don't remember hearing of any capability - system doing this kind of optimisation though; so I guess there are - reasons for that... - <braunr> antrik: yes me too, even more since neal talked about it on - viengoos - <antrik> I wonder whether thread management is also such a large overhead - with fully sync IPC, on L4 or EROS for example... - <braunr> antrik: it's still a very handy optimization for thread scheduling - <braunr> antrik: it makes solving priority inversions a lot easier - <antrik> actually, is thread scheduling a problem at all with a thread - activation approach like in Viengoos? - <braunr> antrik: thread activation is part of thread migration - <braunr> antrik: actually, i'd say they both refer to the same thing - <antrik> err... scheduler activation was the term I wanted to use - <braunr> same - <braunr> well - <braunr> scheduler activation is too vague to assert that - <braunr> antrik: do you refer to scheduler activations as described in - http://en.wikipedia.org/wiki/Scheduler_activations ? - <antrik> my understanding was that Viengoos still has traditional threads; - they just can get scheduled directly on incoming IPC - <antrik> braunr: that Wikipedia article is strange. it seems to use - "scheduler activations" as a synonym for N:M multithreading, which is not - at all how I understood it - <youpi> antrik: I used to try to keep a look at those pages, to fix such - wrong things, but left it - <braunr> antrik: that's why i ask - <antrik> IIRC Viengoos has a thread associated with each receive - buffer. after copying the message, the kernel would activate the - processes activation handler, which in turn could decide to directly - schedule the thead associated with the buffer - <antrik> or something along these lines - <braunr> antrik: that's similar to mach handoff - <youpi> antrik: generally enough, all the thread-related pages on wikipedia - are quite bogus - <antrik> nah, handoff just schedules the process; which is not useful, if - the right thread isn't activated in turn... - <braunr> antrik: but i think it's more than that, even in viengoos - <youpi> for instance, the french "thread" page was basically saying that - they were invented for GUIs to overlap computation with user interaction - <braunr> .. :) - <antrik> youpi: good to know... - <braunr> antrik: the "misunderstanding" comes from the fact that scheduler - activations is the way N:M threading was implemented on netbsd - <antrik> youpi: that's a refreshing take on the matter... ;-) - <braunr> antrik: i'll read the critique and viengoos doc/source again to be - sure about what we're talking :) - <braunr> antrik: as threading is a major issue in mach, and one of the - things i completely changed (and intend to change) in x15, whenever i get - to work on that again ..... :) - <braunr> antrik: interestingly, the paper about scheduler activations was - written (among others) by brian bershad, in 92, when he was actively - working on research around mach - <antrik> braunr: BTW, I have little doubt that making RPC first-class would - solve a number of problems... I just wonder how many others it would open - - -# X15 - -X15 is an in-development hurd-like operating system. It's developer, Richard -Braun, decided that GNU/Hurd running on the mach microkernel has many short-comings. -Namely to make the Hurd "better" required deep changes to gnumach. He decided to start -a new project from scratch. Instead of running the Hurd on top of gnumach, he started -building his own microkernel: X15, which is like gnumach. Originally he had intended -to port the gnuhurd to run ontop of X15, but X15 has since made some design decisions -that make porting the Hurd to run on top of X15 very unlikely. Occasionally some X15 -code can be used on the GNU/Hurd, which is what happened with the buddy allocator. - -Currently X15 is a real-time microkernel with low-level performance monitoring system, -local atomic operations, lockless synchronization, RCU, and it can scale well on any 32-bit, -64-bit target. It currently runs on x86 and ARM processors, but it lacks userspace support. - -## IRC, freenode, #hurd, 2012-09-04 - - <braunr> it was intended as a mach clone, but now that i have better - knowledge of both mach and the hurd, i don't want to retain mach - compatibility - <braunr> and unlike viengoos, it's not really experimental - <braunr> it's focused on memory and cpu scalability, and performance, with - techniques likes thread migration and rcu - <braunr> the design i have in mind is closer to what exists today, with - strong emphasis on scalability and performance, that's all - <braunr> and the reason the hurd can't be modified first is that my design - relies on some important design changes - <braunr> so there is a strong dependency on these mechanisms that requires - the kernel to exists first - - -## IRC, freenode, #hurd, 2012-09-06 - -In context of [[open_issues/multithreading]] and later [[open_issues/select]]. - - <gnu_srs> And you will address the design flaws or implementation faults - with x15? - <braunr> no - <braunr> i'll address the implementation details :p - <braunr> and some design issues like cpu and memory resource accounting - <braunr> but i won't implement generic resource containers - <braunr> assuming it's completed, my work should provide a hurd system on - par with modern monolithic systems - <braunr> (less performant of course, but performant, scalable, and with - about the same kinds of problems) - <braunr> for example, thread migration should be mandatory - <braunr> which would make client calls behave exactly like a userspace task - asking a service from the kernel - <braunr> you have to realize that, on a monolithic kernel, applications are - clients, and the kernel is a server - <braunr> and when performing a system call, the calling thread actually - services itself by running kernel code - <braunr> which is exactly what thread migration is for a multiserver system - <braunr> thread migration also implies sync IPC - <braunr> and sync IPC is inherently more performant because it only - requires one copy, no in kernel buffering - <braunr> sync ipc also avoids message floods, since client threads must run - server code - <gnu_srs> and this is not achievable with evolved gnumach and/or hurd? - <braunr> well that's not entirely true, because there is still a form of - async ipc, but it's a lot less likely - <braunr> it probably is - <braunr> but there are so many things to change i prefer starting from - scratch - <braunr> scalability itself probably requires a revamp of the hurd core - libraries - <braunr> and these libraries are like more than half of the hurd code - <braunr> mach ipc and vm are also very complicated - <braunr> it's better to get something new and simpler from the start - <gnu_srs> a major task nevertheless:-D - <braunr> at least with the vm, netbsd showed it's easier to achieve good - results from new code, as other mach vm based systems like freebsd - struggled to get as good - <braunr> well yes - <braunr> but at least it's not experimental - <braunr> everything i want to implement already exists, and is tested on - production systems - <braunr> it's just time to assemble those ideas and components together - into something that works - <braunr> you could see it as a qnx-like system with thread migration, the - global architecture of the hurd, and some improvements from linux like - rcu :) - - -### IRC, freenode, #hurd, 2012-09-07 - - <antrik> braunr: thread migration is tested on production systems? - <antrik> BTW, I don't think that generally increasing the priority of - servers is a good idea - <antrik> in most cases, IPC should actually be sync. slpz looked at it at - some point, and concluded that the implementation actually has a - fast-path for that case. I wonder what happens to scheduling in this case - -- is the receiver sheduled immediately? if not, that's something to - fix... - <braunr> antrik: qnx does something very close to thread migration, yes - <braunr> antrik: i agree increasing the priority isn't a good thing, but - it's the best of the quick and dirty ways to reduce message floods - <braunr> the problem isn't sync ipc in mach - <braunr> the problem is the notifications (in our cases the dead name - notifications) that are by nature async - <braunr> and a malicious program could send whatever it wants at the - fastest rate it can - <antrik> braunr: malicious programs can do any number of DOS attacks on the - Hurd; I don't see how increasing priority of system servers is relevant - in that context - <antrik> (BTW, I don't think dead name notifications are async by - nature... just like for most other IPC, the *usual* case is that a server - thread is actively waiting for the message when it's generated) - <braunr> antrik: it's async with respect to the client - <braunr> antrik: and malicious programs shouldn't be able to do that kind - of dos - <braunr> but this won't be fixed any time soon - <braunr> on the other hand, a higher priority helps servers not create too - many threads because of notifications, and that's a good thing - <braunr> gnu_srs: the "fix" for this will be to rewrite select so that it's - synchronous btw - <braunr> replacing dead name notifications with something like cancelling a - previously installed select request - <antrik> no idea what "async with respect to the client" means - <braunr> it means the client doesn't wait for anything - <antrik> what is the client? what scenario are you talking about? how does - it affect scheduling? - <braunr> for notifications, it's usually the kernel - <braunr> it doesn't directly affect scheduling - <braunr> it affects the amount of messages a hurd server has to take care - of - <braunr> and the more messages, the more threads - <braunr> i'm talking about event loops - <braunr> and non blocking (or very short) selects - <antrik> the amount of messages is always the same. the question is whether - they can be handled before more come in. which would be the case if be - default the receiver gets scheduled as soon as a message is sent... - <braunr> no - <braunr> scheduling handoff doesn't imply the thread will be ready to - service the next message by the time a client sends a new one - <braunr> the rate at which a message queue gets filled has nothing to do - with scheduling handoff - <antrik> I very much doubt rates come into play at all - <braunr> well they do - <antrik> in my understanding the problem is that a lot of messages are sent - before the receive ever has a chance to handle them. so no matter how - fast the receiver is, it looses - <braunr> a lot of non blocking selects means a lot of reply ports - destroyed, a lot of dead name notifications, and what i call message - floods at server side - <braunr> no - <braunr> it used to work fine with cthreads - <braunr> it doesn't any more with pthreads because pthreads are slightly - slower - <antrik> if the receiver gets a chance to do some work each time a message - arrives, in most cases it would be free to service the next request with - the same thread - <braunr> no, because that thread won't have finished soon enough - <antrik> no, it *never* worked fine. it might have been slighly less - terrible. - <braunr> ok it didn't work fine, it worked ok - <braunr> it's entirely a matter of rate here - <braunr> and that's the big problem, because it shouldn't - <antrik> I'm pretty sure the thread would finish before the time slice ends - in almost all cases - <braunr> no - <braunr> too much contention - <braunr> and in addition locking a contended spin lock depresses priority - <braunr> so servers really waste a lot of time because of that - <antrik> I doubt contention would be a problem if the server gets a chance - to handle each request before 100 others come in - <braunr> i don't see how this is related - <braunr> handling a request doesn't mean entirely processing it - <braunr> there is *no* relation between handoff and the rate of incoming - message rate - <braunr> unless you assume threads can always complete their task in some - fixed and low duration - <antrik> sure there is. we are talking about a single-processor system - here. - <braunr> which is definitely not the case - <braunr> i don't see what it changes - <antrik> I'm pretty sure notifications can generally be handled in a very - short time - <braunr> if the server thread is scheduled as soon as it gets a message, it - can also get preempted by the kernel before replying - <braunr> no, notifications can actually be very long - <braunr> hurd_thread_cancel calls condition_broadcast - <braunr> so if there are a lot of threads on that .. - <braunr> (this is one of the optimizations i have in mind for pthreads, - since it's possible to precisely select the target thread with a doubly - linked list) - <braunr> but even if that's the case, there is no guarantee - <braunr> you can't assume it will be "quick enough" - <antrik> there is no guarantee. but I'm pretty sure it will be "quick - enough" in the vast majority of cases. which is all it needs. - <braunr> ok - <braunr> that's also the idea behind raising server priorities - <antrik> braunr: so you are saying the storms are all caused by select(), - and once this is fixed, the problem should be mostly gone and the - workaround not necessary anymore? - <braunr> yes - <antrik> let's hope you are right :-) - <braunr> :) - <antrik> (I still think though that making hand-off scheduling default is - the right thing to do, and would improve performance in general...) - <braunr> sure - <braunr> well - <braunr> no it's just a hack ;p - <braunr> but it's a right one - <braunr> the right thing to do is a lot more complicated - <braunr> as roland wrote a long time ago, the hurd doesn't need dead-name - notifications, or any notification other than the no-sender (which can be - replaced by a synchronous close on fd like operation) - <antrik> well, yes... I still think the viengoos approach is promising. I - meant the right thing to do in the existing context ;-) - <braunr> better than this priority hack - <antrik> oh? you happen to have a link? never heard of that... - <braunr> i didn't want to do it initially, even resorting to priority - depression on trhead creation to work around the problem - <braunr> hm maybe it wasn't him, i can't manage to find it - <braunr> antrik: - http://lists.gnu.org/archive/html/l4-hurd/2003-09/msg00009.html - <braunr> "Long ago, in specifying the constraints of - <braunr> what the Hurd needs from an underlying IPC system/object model we - made it - <braunr> very clear that we only need no-senders notifications for object - <braunr> implementors (servers)" - <braunr> "We don't in general make use of dead-name notifications, - <braunr> which are the general kind of object death notification Mach - provides and - <braunr> what serves as task death notification." - <braunr> "In the places we do, it's to serve - <braunr> some particular quirky need (and mostly those are side effects of - Mach's - <braunr> decouplable RPCs) and not a semantic model we insist on having." - - -### IRC, freenode, #hurd, 2012-09-08 - - <antrik> The notion that seemed appropriate when we thought about these - issues for - <antrik> Fluke was that the "alert" facility be a feature of the IPC system - itself - <antrik> rather than another layer like the Hurd's io_interrupt protocol. - <antrik> braunr: funny, that's *exactly* what I was thinking when looking - at the io_interrupt mess :-) - <antrik> (and what ultimately convinced me that the Hurd could be much more - elegant with a custom-tailored kernel rather than building around Mach) - - -## IRC, freenode, #hurd, 2012-09-24 - - <braunr> my initial attempt was a mach clone - <braunr> but now i want a mach-like kernel, without compability - <lisporu> which new licence ? - <braunr> and some very important changes like sync ipc - <braunr> gplv3 - <braunr> (or later) - <lisporu> cool 8) - <braunr> yes it is gplv2+ since i didn't take the time to read gplv3, but - now that i have, i can't use anything else for such a project: ) - <lisporu> what is mach-like ? (how it is different from Pistachio like ?) - <braunr> l4 doesn't provide capabilities - <lisporu> hmmm.. - <braunr> you need a userspace for that - <braunr> +server - <braunr> and it relies on complete external memory management - <lisporu> how much work is done ? - <braunr> my kernel will provide capabilities, similar to mach ports, but - simpler (less overhead) - <braunr> i want the primitives right - <braunr> like multiprocessor, synchronization, virtual memory, etc.. - - -### IRC, freenode, #hurd, 2012-09-30 - - <braunr> for those interested, x15 is now a project of its own, with no - gnumach compability goal, and covered by gplv3+ - - -### IRC, freenode, #hurd, 2012-12-31 - - <braunr> bits of news about x15: it can now create tasks, threads, vm_maps, - physical maps (cpu-specific page tables) for user tasks, and stack - tracing (in addition to symbol resolution when symbols are available) - were recently added - - -### IRC, freenode, #hurd, 2013-01-15 - - <braunr> Anarchos: as a side note, i'm currently working on a hurd clone - with a microkernel that takes a lot from mach but also completely changes - the ipc interface (making it not mach at all in the end) - <braunr> it's something between mach and qnx neutrino - <zacts> braunr: do you have a git repo of your new clone? - <braunr> http://git.sceen.net/rbraun/x15.git/ - <zacts> neat - <braunr> it's far from complete - <braunr> and hasn't reached a status where it can be publically announced - <zacts> ok - <braunr> but progress has been constant so far, the ideas i'm using have - proven applicable on other systems, i don't expect the kind of design - issues that blocked HurdNG - <braunr> (also, my attempt doesn't aim at the same goals as hurdng did) - <braunr> (e.g. denial of service remains completely possible) - <zacts> so x15 will use the current hurd translators? you are only - replacing gnumach? - <braunr> that was the plan some years ago, but now that i know the hurd - better, i think the main issues are in the hurd, so there isn't much - point rewriting mach - <braunr> so, if the hurd needs a revamp, it's better to also make the - underlying interface better if possible - <braunr> zacts: in other words: it's a completely different beast - <zacts> ok - <braunr> the main goal is to create a hurd-like system that overcomes the - current major defficiencies, most of them being caused by old design - decisions - <zacts> like async ipc? - <braunr> yes - <Anarchos> time for a persistent hurd ? :) - <braunr> no way - <braunr> i don't see a point to persistence for a general purpose system - <braunr> and it easily kills performance - <braunr> on the other hand, it would be nice to have a truely scalable, - performant, and free microkernel based system - <braunr> (and posix compatible) - <braunr> there is currently none - <braunr> zacts: the projects focuses mostly on performance and scalability, - while also being very easy to understand and maintain (something i think - the current hurd has failed at :/) - <braunr> project* - <zacts> very cool - <braunr> i think so, but we'll have to wait for an end result :) - <braunr> what's currently blocking me is the IDL - <braunr> earlier research has shown that an idl must be optmized the same - way compilers are for the best performances - <braunr> i'm not sure i can write something good enough :/ - <braunr> the first version will probably be very similar to mig, small and - unoptimized - - -### IRC, freenode, #hurd, 2013-01-18 - - <zacts> braunr: so how exactly do the goals of x15 differ from viengoos? - <braunr> zacts: viengoos is much more ambitious about the design - <braunr> tbh, i still don't clearly see how its half-sync ipc work - <braunr> x15 is much more mach-like, e.g. a hybrid microkernel with - scheduling and virtual memory in the kernel - <braunr> its goals are close to those of mach, adding increased scalability - and performance to the list - <zacts> that's neat - <braunr> that's different - <braunr> in a way, you could consider x15 is to mach what linux is to unix, - a clone with a "slightly" different interface - <zacts> ah, ok. cool! - <braunr> viengoos is rather a research project, with very interesting - goals, i think they're both neat :p - - -### IRC, freenode, #hurd, 2013-01-19 - - <braunr> for now, it provides kernel memory allocation and basic threading - <braunr> it already supports both i386 and amd64 processors (from i586 - onwards), and basic smp - <zacts> oh wow - <zacts> how easily can it be ported to other archs? - <braunr> the current focus is smp load balancing, so that thread migration - is enabled during development - <braunr> hard to say - <braunr> everything that is arch-specific is cleanly separated, the same - way it is in mach and netbsd - <braunr> but the arch-specific interfaces aren't well defined yet because - there is only one (and incomplete) arch - - -### IRC, freenode, #hurd, 2013-03-08 - - <antrik> BTW, what is your current direction? did you follow through with - abandonning Mach resemblance?... - <braunr> no - <braunr> it's very similar to mach in many ways - <braunr> unless mach is defined by its ipc in which case it's not mach at - all - <braunr> the ipc interface will be similar to the qnx one - <antrik> well, Mach is pretty much defined by it's IPC and VM interface... - <braunr> the vm interface remains - <antrik> its - <braunr> although vm maps will be first class objects - <braunr> so that it will be possible to move parts of the vm server outside - the kernel some day if it feels like a good thing to do - <braunr> i.e. vm maps won't be inferred from tasks - <braunr> not implicitely - <braunr> the kernel will be restricted to scheduling, memory management, - and ipc, much as mach is (notwithstanding drivers) - <antrik> hm... going with QNX IPC still seems risky to me... it's designed - for simple embedded environments, not for general-purpose operating - systems in my understanding - <braunr> no, the qnx ipc interface is very generic - <braunr> they can already call remote services - <braunr> the system can scale well on multiprocessor machines - <braunr> that's not risky at all, on the contrary - <antrik> yeah, I'm sure it's generic... but I don't think anybody tried to - build a Hurd-like system on top of it; so it's not at all clear whether - it will work out at all... - <auronandace> clueless question: does x15 have any inspiration from - helenos? - <braunr> absolutely none - <braunr> i'd say x15 is almost an opposite to helenos - <braunr> it's meant as a foundation for unix systems, like mach - <braunr> some unix interfaces considered insane by helenos people (such as - fork and signals) will be implemented (although not completely in the - kernel) - <braunr> ipc will be mostly synchronous - <braunr> they're very different - <braunr> well, helenos is very different - <auronandace> cool - <braunr> x15 and actually propel (the current name i have for the final - system), are meant to create a hurd clone - <auronandace> another clueless question: any similarities of x15 to minix? - <braunr> and since we're few, implementing posix efficiently is a priority - goal for me - <braunr> again, absolutely none - <braunr> for the same reasons - <braunr> minix targets resilience in embedded environments - <braunr> propel is a hurd clone - <braunr> propel aims at being a very scalable and performant hurd clone - <braunr> that's all - <auronandace> neato - <braunr> unfortunately, i couldn't find a name retaining all the cool - properties of the hurd - <braunr> feel free to suggest ideas :) - <auronandace> propel? as in to launch forward? - <braunr> push forward, yes - <auronandace> that's very likely a better name than anything i could - conjure up - <braunr> x15 is named after mach (the first aircraft to break mach 4, - reaching a bit less than mach 7) - <braunr> servers will be engines, and together to push the system forward - ..... :) - <auronandace> nice - <auronandace> thrust might be a bit too generic i guess - <braunr> oh i'm looking for something like "hurd" - <braunr> doubly recursive acronym, related to gnu - <braunr> and short, so it can be used as a c namespace - <braunr> antrik: i've thought about it a lot, and i'm convinced this kind - of interface is fine for a hurd like system - <braunr> the various discussions i found about the hurd requirements - (remember roland talking about notifications) all went in this direction - <braunr> note however the interface isn't completely synchronous - <braunr> and that's very important - <antrik> well, I'm certainly curious. but if you are serious about this, - you'd better start building a prototype as soon as possible, rather than - perfecting SMP ;-) - <braunr> i'm not perfecting smp - <braunr> but i consider it very important to have migrations and preemption - actually working before starting the prototype - <braunr> so that tricky mistakes about concurrency can be catched early - <antrik> my current hunch is that you are trying to do too much at the same - time... improving both the implementation details and redoing the system - design - <braunr> so, for example, there is (or will be soon, actually) thread - migratio, but the scheduler doesn't take processor topology into account - <braunr> that's why i'm starting from scratch - <braunr> i don't delve too deep into the details - <braunr> just the ones i consider very important - <antrik> what do you mean by thread migration here? didn't you say you - don't even have IPC?... - <braunr> i mean migration between cpus - <antrik> OK - <braunr> the other is too confusing - <braunr> and far too unused and unknown to be used - <braunr> and i won't actually implement it the way it was done in mach - <braunr> again, it will be similar to qnx - <antrik> oh? now that's news for me :-) - <antrik> you seemed pretty hooked on thread migration when we talked about - these things last time... - <braunr> i still am - <braunr> i'm just saying it won't be implemented the same way - <braunr> instead of upcalls from the kernel into userspace, i'll "simply" - make server threads inherit from the caller's scheduling context - <braunr> the ideas i had about stack management are impossible to apply in - practice - <braunr> which make the benefit i imagined unrealistic - <braunr> and the whole idea was very confusing when compared and integrated - into a unix like view - <braunr> so stack usage will be increased - <braunr> that's ok - <antrik> but thread migration is more or less equivalent with first-class - RPCs AIUI. does that work with the QNX IPC model?... - <braunr> the very important property that threads don't block and wake a - server when sending, and the server again blocks and wake the client on - reply, is preserved - <antrik> (in fact I find the term "first-class RPC" much clearer...) - <braunr> i dont - <braunr> there are two benefits in practice: since the scheduling context - is inherited, the client is charged for the cpu time consumed - <braunr> and since there are no wakeups and blockings, but a direct hand - off in the scheduler, the cost of crossing task space is closer to the - system call - <antrik> which can be problematic too... but still it's the solution chosen - by EROS for example AIUI - <antrik> (inheriting scheduling contexts I mean) - <braunr> by practically all modern microkernel based systems actually, as - noted by shapiro - <antrik> braunr: well, both benefits can be achieved by other means as - well... scheduler activations like in Viengoos should handle the hand-off - part AIUI, and scheduling contexts can be inherited explicitly too, like - in EROS (and in a way in Viengoos) - <braunr> i don't understand viengoos well enough to do it that way - - -## IRC, freenode, #hurd, 2013-04-13 - - <braunr> a microkernel loosely based on mach for a future hurd-like system - <JoshuaB> ok. no way! Are you in the process of building a micro-kernel - that the hurd may someday run on? - <braunr> not the hurd, a hurd-like system - <JoshuaB> ok wow. sounds pretty cool, and tricky - <braunr> the hurd could, but would require many changes too, and the point - of this rewrite is to overcome the most difficult technical performance - and scalability problems of the current hurd - <braunr> doing that requires deep changes in the low level interfaces - <braunr> imo, a rewrite is more appropriate - <braunr> sometimes, things done in x15 can be ported to the hurd - <braunr> but it still requires a good deal of effort - - -## IRC, freenode, #hurd, 2013-04-26 - - <bddebian> braunr: Did I see that you are back tinkering with X15? - <braunr> well yes i am - <braunr> and i'm very satisfied with it currently, i hope i can maintain - the same level of quality in the future - <braunr> it can already handle hundreds of processors with hundreds of GB - of RAM in a very scalable way - <braunr> most algorithms are O(1) - <braunr> even waking up multiple threads is O(1) :) - <braunr> i'd like to implement rcu this summer - <bddebian> Nice. When are you gonna replace gnumach? ;-P - <braunr> never - <braunr> it's x15, not x15mach now - <braunr> it's not meant to be compatible - <bddebian> Who says it has to be compatible? :) - <braunr> i don't know, my head - <braunr> the point is, the project is about rewriting the hurd now, not - just the kernel - <braunr> new kernel, new ipc, new interfaces, new libraries, new everything - <bddebian> Yikes, now that is some work. :) - <braunr> well yes and no - <braunr> ipc shouldn't be that difficult/long, considering how simple i - want the interface to be - <bddebian> Cool. - <braunr> networking and drivers will simply be reused from another code - base like dde or netbsd - <braunr> so besides the kernel, it's a few libraries (e.g. a libports like - library), sysdeps parts in the c library, and a file system - <bddebian> For inclusion in glibc or are you not intending on using glibc? - <braunr> i intend to use glibc, but not for upstream integration, if that's - what you meant - <braunr> so a private, local branch i assume - <braunr> i expect that part to be the hardest - - -## IRC, freenode, #hurd, 2013-05-02 - - <zacts> braunr: also, will propel/x15 use netbsd drivers or netdde linux - drivers? - <zacts> or both? - <braunr> probably netbsd drivers - <zacts> and if netbsd, will it utilize rump? - -[[open_issues/user-space_device_drivers]], *External Projects*, *The Anykernel -and Rump Kernels*. - - <braunr> i don't know yet - <zacts> ok - <braunr> device drivers and networking will arrive late - <braunr> the system first has to run in ram, with a truely configurable - boot process - <braunr> (i.e. a boot process that doesn't use anything static, and can - boot from either disk or network) - <braunr> rump looks good but it still requires some work since it doesn't - take care of messaging as well as we'd want - <braunr> e.g. signal relaying isn't that great - <zacts> I personally feel like using linux drivers would be cool, just - because linux supports more hardware than netbsd iirc.. - <mcsim> zacts: But it could be problematic as you should take quite a lot - code from linux kernel to add support even for a single driver. - <braunr> zacts: netbsd drivers are far more portable - <zacts> oh wow, interesting. yeah I did have the idea that netbsd would be - more portable. - <braunr> mcsim: that doesn't seem to be as big a problem as you might - suggest - <braunr> the problem is providing the drivers with their requirements - <braunr> there are a lot of different execution contexts in linux (hardirq, - softirq, bh, threads to name a few) - <braunr> being portable (as implied in netbsd) also means being less - demanding on the execution context - <braunr> which allows reusing code in userspace more easily, as - demonstrated by rump - <braunr> i don't really care about extensive hardware support, since this - is required only for very popular projects such as linux - <braunr> and hardware support actually comes with popularity (the driver - code base is related with the user base) - <zacts> so you think that more users will contribute if the projects takes - off? - <braunr> i care about clean and maintainable code - <braunr> well yes - <zacts> I think that's a good attitude - <braunr> what i mean is, there is no need for extensive hardware support - <mcsim> braunr: TBH, I did not really got idea of rump. Do they try to run - the whole kernel or some chosen subsystems as user tasks? - <braunr> mcsim: some subsystems - <braunr> well - <braunr> all the subsystems required by the code they actually want to run - <braunr> (be it a file system or a network stack) - <mcsim> braunr: What's the difference with dde? - <braunr> it's not kernel oriented - <mcsim> what do you mean? - <braunr> it's not only meant to run on top of a microkernel - <braunr> as the author named it, it's "anykernel" - <braunr> if you remember at fosdem, he run code inside a browser - <braunr> ran* - <braunr> and also, netbsd drivers wouldn't restrict the license - <braunr> although not a priority, having a (would be) gnu system under - gplv3+ would be nice - <zacts> that would be cool - <zacts> x15 is already gplv3+ - <zacts> iirc - <braunr> yes - <zacts> cool - <zacts> yeah, I would agree netbsd drivers do look more attractive in that - case - <braunr> again, that's clearly not the main reason for choosing them - <zacts> ok - <braunr> it could also cause other problems, such as accepting a bsd - license when contributing back - <braunr> but the main feature of the hurd isn't drivers, and what we want - to protect with the gpl is the main features - <zacts> I see - <braunr> drivers, as well as networking, would be third party code, the - same way you run e.g. firefox on linux - <braunr> with just a bit of glue - <zacts> braunr: what do you think of the idea of being able to do updates - for propel without rebooting the machine? would that be possible down the - road? - <braunr> simple answer: no - <braunr> that would probably require persistence, and i really don't want - that - <zacts> does persistence add a lot of complexity to the system? - <braunr> not with the code, but at execution, yes - <zacts> interesting - <braunr> we could add per-program serialization that would allow it but - that's clearly not a priority for me - <braunr> updating with a reboot is already complex enough :) - - -## IRC, freenode, #hurd, 2013-05-09 - - <braunr> the thing is, i consider the basic building blocks of the hurd too - crappy to build anything really worth such effort over them - <braunr> mach is crappy, mig is crappy, signal handling is crappy, hurd - libraries are ok but incur a lot of contention, which is crappy today - <bddebian> Understood but it is all we have currently. - <braunr> i know - <braunr> and it's good as a prototype - <bddebian> We have already had L4, viengoos, etc and nothing has ever come - to fruition. :( - <braunr> my approach is compeltely different - <braunr> it's not a new design - <braunr> a few things like ipc and signals are redesigned, but that's minor - compared to what was intended for hurdng - <braunr> propel is simply meant to be a fast, scalable implementation of - the hurd high level architecture - <braunr> bddebian: imagine a mig you don't fear using - <braunr> imagine interfaces not constrained to 100 calls ... - <braunr> imagine per-thread signalling from the start - <bddebian> braunr: I am with you 100% but it's vaporware so far.. ;-) - <braunr> bddebian: i'm just explaining why i don't want to work on large - scale projects on the hurd - <braunr> fixing local bugs is fine - <braunr> fixing paging is mandatory - <braunr> usb could be implemented with dde, perhaps by sharing the pci - handling code - <braunr> (i.e. have one big dde server with drivers inside, a bit ugly but - straightforward compared to a full fledged pci server) - <bddebian> braunr: But this is the problem I see. Those of you that have - the skills don't have the time or energy to put into fixing that kind of - stuff. - <bddebian> braunr: That was my thought. - <braunr> bddebian: well i have time, and i'm currently working :p - <braunr> but not on that - <braunr> bddebian: also, it won't be vaporware for long, i may have ipc - working well by the end of the year, and optimized and developer-friendly - by next year) - - -## IRC, freenode, #hurd, 2013-06-05 - - <braunr> i'll soon add my radix tree with support for lockless lookups :> - <braunr> a tree organized based on the values of the keys thmselves, and - not how they relatively compare to each other - <braunr> also, a tree of arrays, which takes advantage of cache locality - without the burden of expensive resizes - <arnuld> you seem to be applying good algorithmic teghniques - <arnuld> that is nice - <braunr> that's one goal of the project - <braunr> you can't achieve performance and scalability without the - appropriate techniques - <braunr> see https://git.sceen.net/rbraun/librbraun.git/plain/rdxtree.c - for the existing userspace implementation - <arnuld> in kern/work.c I see one TODO "allocate numeric IDs to better - identify worker threads" - <braunr> yes - <braunr> and i'm adding my radix tree now exactly for that - <braunr> (well not only, since radix tree will also back VM objects and IPC - spaces, two major data structures of the kernel) - - -## IRC, freenode, #hurd, 2013-06-11 - - <braunr> and also starting paging anonymous memory in x15 :> - <braunr> well, i've merged my radix tree code, made it safe for lockless - access (or so i hope), added generic concurrent work queues - <braunr> and once the basic support for anonymous memory is done, x15 will - be able to load modules passed from grub into userspace :> - <braunr> but i've also been thinking about how to solve a major scalability - issue with capability based microkernels that noone else seem to have - seen or bothered thinking about - <braunr> for those interested, the problem is contention at the port level - <braunr> unlike on a monolithic kernel, or a microkernel with thread-based - ipc such as l4, mach and similar kernels use capabilities (port rights in - mach terminology) to communicate - <braunr> the kernel then has to "translate" that reference into a thread to - process the request - <braunr> this is done by using a port set, putting many ports inside, and - making worker threads receive messages on the port set - <braunr> and in practice, this gets very similar to a traditional thread - pool model - <braunr> one thread actually waits for a message, while others sit on a - list - <braunr> when a message arrives, the receiving thread wakes another from - that list so it receives the next message - <braunr> this is all done with a lock - <bddebian> Maybe they thought about it but couldn't or were to lazy to find - a better way? :) - <mcsim> braunr: what do you mean under "unlike .... a microkernel with - thread-based ipc such as l4, mach and similar kernels use capabilities"? - L4 also has capabilities. - <braunr> mcsim: not directly - <braunr> capabilities are implemented by a server on top of l4 - <braunr> unless it's OKL4 or another variant with capabilities back in the - kernel - <braunr> i don't know how fiasco does it - <braunr> so the problem with this lock is potentially very heavy contention - <braunr> and contention in what is the equivalent of a system call .. - <braunr> it's also hard to make it real-time capable - <braunr> for example, in qnx, they temporarily apply priority inheritance - to *every* server thread since they don't know which one is going to be - receiving next - <mcsim> braunr: in fiasco you have capability pool for each thread and this - pool is stored in tread control block. When one allocates capability - kernel just marks slot in a pool as busy - <braunr> mcsim: ok but, there *is* a thread for each capability - <braunr> i mean, when doing ipc, there can only be one thread receiving the - message - <braunr> (iirc, this was one of the big issue for l4-hurd) - <mcsim> ok. i see the difference. - <braunr> well i'm asking - <braunr> i'm not so sure about fiasco - <braunr> but that's what i remember from the generic l4 spec - <mcsim> sorry, but where is the question? - <braunr> 16:04 < braunr> i mean, when doing ipc, there can only be one - thread receiving the message - <mcsim> yes, you specify capability to thread you want to send message to - <braunr> i'll rephrase: - <braunr> when you send a message, do you invoke a capability (as in mach), - or do you specify the receiving thread ? - <mcsim> you specify a thread - <braunr> that's my point - <mcsim> but you use local name (that is basically capability) - <braunr> i see - <braunr> from wikipedia: "Furthermore, Fiasco contains mechanisms for - controlling communication rights as well as kernel-level resource - consumption" - <braunr> not certain that's what it refers to, but that's what i understand - from it - <braunr> more capability features in the kernel - <braunr> but you still send to one thread - <mcsim> yes - <braunr> that's what makes it "easily" real time capable - <braunr> a microkernel that would provide mach-like semantics - (object-oriented messaging) but without contention at the messsage - passing level (and with resource preallocation for real time) would be - really great - <braunr> bddebian: i'm not sure anyone did - <bddebian> braunr: Well you can be the hero!! ;) - <braunr> the various papers i could find that were close to this subject - didn't take contention into account - <braunr> exception for network-distributed ipc on slow network links - <braunr> bddebian: eh - <braunr> well i think it's doable acctually - <mcsim> braunr: can you elaborate on where contention is, because I do not - see this clearly? - <braunr> mcsim: let's take a practical example - <braunr> a file system such as ext2fs, that you know well enough - <braunr> imagine a large machine with e.g. 64 processors - <braunr> and an ignorant developer like ourselves issuing make -j64 - <braunr> every file access performed by the gcc tools will look up files, - and read/write/close them, concurrently - <braunr> at the server side, thread creation isn't a problem - <braunr> we could have as many threads as clients - <braunr> the problem is the port set - <braunr> for each port class/bucket (let's assume they map 1:1), a port set - is created, and all receive rights for the objects managed by the server - (the files) are inserted in this port set - <braunr> then, the server uses ports_manage_port_operations_multithread() - to service requests on that port set - <braunr> with as many threads required to process incoming messages, much - the same way a work queue does it - <braunr> but you can't have *all* threads receiving at the same time - <braunr> there can only be one - <braunr> the others are queued - <braunr> i did a change about the queue order a few months ago in mach btw - <braunr> mcsim: see ipc/ipc_thread.c in gnumach - <braunr> this queue is shared and must be modified, which basically means a - lock, and contention - <braunr> so the 64 concurrent gcc processes will suffer from contenion at - the server while they're doing something similar to a system call - <braunr> by that, i mean, even before the request is received - <braunr> mcsim: if you still don't understand, feel free to ask - <mcsim> braunr: I'm thinking on it :) give me some time - <braunr> "Fiasco.OC is a third generation microkernel, which evolved from - its predecessor L4/Fiasco. Fiasco.OC is capability based" - <braunr> ok - <braunr> so basically, there are no more interesting l4 variants strictly - following the l4v2 spec any more - <braunr> "The completely redesigned user-land environment running on top of - Fiasco.OC is called L4 Runtime Environment (L4Re). It provides the - framework to build multi-component systems, including a client/server - communication framework" - <braunr> so yes, client/server communication is built on top of the kernel - <braunr> something i really want to avoid actually - <mcsim> So when 1 core wants to pull something out of queue it has to lock - it, and the problem arrives when other 63 cpus are waiting in the same - lock. Right? - <braunr> mcsim: yes - <mcsim> could this be solved by implementing per cpu queues? Like in slab - allocator - <braunr> solved, no - <braunr> reduced, yes - <braunr> by using multiple port sets, each with their own thread pool - <braunr> but this would still leave core problems unsolved - <braunr> (those making real-time hard) - <mcsim> to make it real-time is not really essential to solve this problem - <braunr> that's the other way around - <mcsim> we just need to guarantee that locking protocol is fair - <braunr> solving this problem is required for quality real-time - <braunr> what you refer to is similar to what i described in qnx earlier - <braunr> it's ugly - <braunr> keep in mind that message passing is the equivalent of system - calls on monolithic kernels - <braunr> os ideally, we'd want something as close as possible to an - actually system call - <braunr> so* - <braunr> mcsim: do you see why it's ugly ? - <mcsim> no i meant exactly opposite, I meant to use some deterministic - locking protocol - <braunr> please elaborate - <braunr> because what qnx does is deterministic - <mcsim> We know in what sequences threads will acquire the lock, so we will - not have to apply inheritance to all threads - <braunr> hwo do you know ? - <mcsim> there are different approaches, like you use ticket system or MCS - lock (http://portal.acm.org/citation.cfm?id=103729) - <braunr> that's still locking - <braunr> a system call has 0 contention - <braunr> 0 potential contention - <mcsim> in linux? - <braunr> everywhere i assume - <mcsim> than why do they need locks? - <braunr> they need locks after the system call - <braunr> the system call itself is a stupid trap that makes the thread - "jump" in the kernel - <braunr> and the reason why it's so simple is the same as in fiasco: - threads (clients) communicate directly with the "server thread" - (themselves in kernel mode) - <braunr> so 1/ they don't go through a capability or any other abstraction - <braunr> and 2/ they're even faster than on fiasco because they don't need - to find the destination, it's implied by the trap mechanism) - <braunr> 2/ is only an optimization that we can live without - <braunr> but 1/ is a serious bottleneck for microkernels - <mcsim> Do you mean that there system call that process without locks or do - you mean that there are no system calls that use locks? - <braunr> this is what makes papers such as - https://www.kernel.org/doc/ols/2007/ols2007v1-pages-251-262.pdf valid - <braunr> i mean the system call (the mechanism used to query system - services) doesn't have to grab any lock - <braunr> the idea i have is to make the kernel transparently (well, as much - as it can be) associate a server thread to a client thread at the port - level - <braunr> at the server side, it would work practically the same - <braunr> the first time a server thread services a request, it's - automatically associated to a client, and subsequent request will - directly address this thread - <braunr> when the client is destroyed, the server gets notified and - destroys the associated server trhead - <braunr> for real-time tasks, i'm thinking of using a signal that gets sent - to all servers, notifying them of the thread creation so that they can - preallocate the server thread - <braunr> or rather, a signal to all servers wishing to be notified - <braunr> or perhaps the client has to reserve the resources itself - <braunr> i don't know, but that's the idea - <mcsim> and who will send this signal? - <braunr> the kernel - <braunr> x15 will provide unix like signals - <braunr> but i think the client doing explicit reservation is better - <braunr> more complicated, but better - <braunr> real time developers ought to know what they're doing anyway - <braunr> mcsim: the trick is using lockless synchronization (like rcu) at - the port so that looking up the matching server thread doesn't grab any - lock - <braunr> there would still be contention for the very first access, but - that looks much better than having it every time - <braunr> (potential contention) - <braunr> it also simplifies writing servers a lot, because it encourages - the use of a single port set for best performance - <braunr> instead of burdening the server writer with avoiding contention - with e.g. a hierarchical scheme - <mcsim> "looking up the matching server" -- looking up where? - <braunr> in the port - <mcsim> but why can't you just take first? - <braunr> that's what triggers contention - <braunr> you have to look at the first - <mcsim> > (16:34:13) braunr: mcsim: do you see why it's ugly ? - <mcsim> BTW, not really - <braunr> imagine serveral clients send concurrently - <braunr> mcsim: well, qnx doesn't do it every time - <braunr> qnx boosts server threads only when there are no thread currently - receiving, and a sender with a higher priority arrives - <braunr> since qnx can't know which server thread is going to be receiving - next, it boosts every thread - <braunr> boosting priority is expensive, and boosting everythread is linear - with the number of threads - <braunr> so on a big system, it would be damn slow for a system call :) - <mcsim> ok - <braunr> and grabbing "the first" can't be properly done without - serialization - <braunr> if several clients send concurrently, only one of them gets - serviced by the "first server thread" - <braunr> the second client will be serviced by the "second" (or the first - if it came back) - <braunr> making the second become the first (i call it the manager) must be - atomic - <braunr> that's the core of the problem - <braunr> i think it's very important because that's currently one of the - fundamental differences wih monolithic kernels - <mcsim> so looking up for server is done without contention. And just - assigning task to server requires lock, right? - <braunr> mcsim: basically yes - <braunr> i'm not sure it's that easy in practice but that's what i'll aim - at - <braunr> almost every argument i've read about microkernel vs monolithic is - full of crap - <mcsim> Do you mean lock on the whole queue or finer grained one? - <braunr> the whole port - <braunr> (including the queue) - <mcsim> why the whole port? - <braunr> how can you make it finer ? - <mcsim> is queue a linked list? - <braunr> yes - <mcsim> than can we just lock current element in the queue and elements - that point to current - <braunr> that's two lock - <braunr> and every sender will want "current" - <braunr> which then becomes coarse grained - <mcsim> but they want different current - <braunr> let's call them the manager and the spare threads - <braunr> yes, that's why there is a lock - <braunr> so they don't all get the same - <braunr> the manager is the one currently waiting for a message, while - spare threads are available but not doing anything - <braunr> when the manager finally receives a message, it takes the first - spare, which becomes the new manager - <braunr> exactly like in a common thread pool - <braunr> so what are you calling current ? - <mcsim> we have in a port queue of threads that wait for message: t1 -> t2 - -> t3 -> t4; kernel decided to assign message to t3, than t3 and t2 are - locked. - <braunr> why not t1 and t2 ? - <mcsim> i was calling t3 in this example as current - <mcsim> some heuristics - <braunr> yeah well no - <braunr> it wouldn't be deterministic then - <mcsim> for instance client runs on core 3 and wants server that also runs - on core 3 - <braunr> i really want the operation as close as a true system call as - possible, so O(1) - <braunr> what if there are none ? - <mcsim> it looks up forward up to the end of queue: t1->t2->t4; takes t4 - <mcsim> than it starts from the beginning - <braunr> that becomes linear in the worst case - <mcsim> no - <braunr> so 4095 attempts on a 4096 cpus machine - <braunr> ? - <mcsim> you're right - <braunr> unfortunately :/ - <braunr> a per-cpu scheme could be good - <braunr> and applicable - <braunr> with much more thought - <braunr> and the problem is that, unlike the kernel, which is naturally a - one thread per cpu server, userspace servers may have less or more - threads than cpu - <braunr> possibly unbalanced too - <braunr> so it would result in complicated code - <braunr> one good thing with microkernels is that they're small - <braunr> they don't pollute the instruction cache much - <braunr> keeping the code small is important for performance too - <braunr> so forgetting this kind of optimization makes for not too - complicated code, and we rely on the scheduler to properly balance - threads - <braunr> mcsim: also note that, with your idea, the worst cast is twice - more expensive than a single lock - <braunr> and on a machine with few processors, this worst case would be - likely - <mcsim> so, you propose every time try to take first server from the queue? - <mcsim> braunr: ^ - <braunr> no - <braunr> that's what is done already - <braunr> i propose doing that the first time a client sends a message - <braunr> but then, the server thread that replied becomes strongly - associated to that client (it cannot service requests from other clients) - <braunr> and it can be recycled only when the client dies - <braunr> (which generates a signal indicating the server it can now recycle - the server thread) - <braunr> (a signal similar to the no-sender or dead-name notifications in - mach) - <braunr> that signal would be sent from the kernel, in the traditional unix - way (i.e. no dedicated signal thread since it would be another source of - contention) - <braunr> and the server thread would directly receive it, not interfering - with the other threads in the server in any way - <braunr> => contention on first message only - <braunr> now, for something like make -j64, which starts a different - process for each compilation (itself starting subprocesses for - preprocessing/compiling/assembling) - <braunr> it wouldn't be such a big win - <braunr> so even this first access should be optimized - <braunr> if you ever get an idea, feel free to share :) - <mcsim> May mach block thread when it performs asynchronous call? - <mcsim> braunr: ^ - <braunr> sure - <braunr> but that's unrelated - <braunr> in mach, a sender is blocked only when the message queue is full - <mcsim> So we can introduce per cpu queues at the sender side - <braunr> (and mach_msg wasn't called in non blocking mode obviously) - <braunr> no - <braunr> they need to be delivered in order - <mcsim> In what order? - <braunr> messages can't be reorder once queued - <braunr> reordered - <braunr> so fifo order - <braunr> if you break the queue in per cpu queues, you may break that, or - need work to rebuild the order - <braunr> which negates the gain from using per cpu queues - <mcsim> Messages from the same thread will be kept in order - <braunr> are you sure ? - <braunr> and i'm not sure it's enough - <mcsim> thes cpu queues will be put to common queue once context switch - occurs - <braunr> *all* messages must be received in order - <mcsim> these* - <braunr> uh ? - <braunr> you want each context switch to grab a global lock ? - <mcsim> if you have parallel threads that send messages that do not have - dependencies than they are unordered - <mcsim> always - <braunr> the problem is they might - <braunr> consider auth for example - <braunr> you have one client attempting to authenticate itself to a server - through the auth server - <braunr> if message order is messed up, it just won't work - <braunr> but i don't have this problem in x15, since all ipc (except - signals) is synchronous - <mcsim> but it won't be messed up. You just "send" messages in O(1), but - than you put these messages that are not actually sent in queue all at - once - <braunr> i think i need more details please - <mcsim> you have lock on the port as it works now, not the kernel lock - <mcsim> the idea is to batch these calls - <braunr> i see - <braunr> batching can be effective, but it would really require queueing - <braunr> x15 only queues clients when there is no receiver - <braunr> i don't think batching can be applied there - <mcsim> you batch messages only from one client - <braunr> that's what i'm saying - <mcsim> so client can send several messages during his time slice and than - you put them into queue all together - <braunr> x15 ipc is synchronous, no more than 1 message per client at any - time - <braunr> there also are other problems with this strategy - <braunr> problems we have on the hurd, such as priority handling - <braunr> if you delay the reception of messages, you also delay priority - inheritance to the server thread - <braunr> well not the reception, the queueing actually - <braunr> but since batching is about delaying that, it's the same - <mcsim> if you use synchronous ipc than there is no sence in batching, at - least as I see it. - <braunr> yes - <braunr> 18:08 < braunr> i don't think batching can be applied there - <braunr> and i think sync ipc is the only way to go for a system intended - to provide messaging performance as close as possible to the system call - <mcsim> do you have as many server thread as many cores you have? - <braunr> no - <braunr> as many server threads as clients - <braunr> which matches the monolithic model - <mcsim> in current implementation? - <braunr> no - <braunr> currently i don't have userspace :> - <mcsim> and what is in hurd atm? - <mcsim> in gnumach - <braunr> asyn ipc - <braunr> async - <braunr> with message queues - <braunr> no priority inheritance, simple "handoff" on message delivery, - that's all - <anatoly> I managed to read the conversation :-) - <braunr> eh - <braunr> anatoly: any opinion on this ? - <anatoly> braunr: I have no opinion. I understand it partially :-) But - association of threads sounds for me as good idea - <anatoly> But who am I to say what is good or what is not in that area :-) - <braunr> there still is this "first time" issue which needs at least one - atomic instruction - <anatoly> I see. Does mach do this "first time" thing every time? - <braunr> yes - <braunr> but gnumach is uniprocessor so it doesn't matter - <mcsim> if we have 1:1 relation for client and server threads we need only - per-cpu queues - <braunr> mcsim: explain that please - <braunr> and the problem here is establishing this relation - <braunr> with a lockless lookup, i don't even need per cpu queues - <mcsim> you said: (18:11:16) braunr: as many server threads as clients - <mcsim> how do you create server threads? - <braunr> pthread_create - <braunr> :) - <mcsim> ok :) - <mcsim> why and when do you create a server thread? - <braunr> there must be at least one unbound thread waiting for a message - <braunr> when a message is received, that thread knows it's now bound with - a client, and if needed wakes up/spawns another thread to wait for - incoming messages - <braunr> when it gets a signal indicating the death of the client, it knows - it's now unbound, and goes back to waiting for new messages - <braunr> becoming either the manager or a spare thread if there already is - a manager - <braunr> a timer could be used as it's done on the hurd to make unbound - threads die after a timeout - <braunr> the distinction between the manager and spare threads would only - be done at the kernel level - <braunr> the server would simply make unbound threads wait on the port set - <anatoly> How client sends signal to thread about its death (as I - understand signal is not message) (sorry for noob question) - <mcsim> in what you described there are no queues at all - <braunr> anatoly: the kernel does it - <braunr> mcsim: there is, in the kernel - <braunr> the queue of spare threads - <braunr> anatoly: don't apologize for noob questions eh - <anatoly> braunr: is that client is a thread of some user space task? - <braunr> i don't think it's a newbie topic at all - <braunr> anatoly: a thread - <mcsim> make these queue per cpu - <braunr> why ? - <braunr> there can be a lot less spare threads than processors - <braunr> i don't think it's a good idea to spawn one thread per cpu per - port set - <braunr> on a large machine you'd have tons of useless threads - <mcsim> if you have many useless threads, than assign 1 thread to several - core, thus you will have twice less threads - <mcsim> i mean dynamically - <braunr> that becomes a hierarchical model - <braunr> it does reduce contention, but it's complicated, and for now i'm - not sure it's worth it - <braunr> it could be a tunable though - <mcsim> if you want something fast you should use something complicated. - <braunr> really ? - <braunr> a system call is very simple and very fast - <braunr> :p - <mcsim> why is it fast? - <mcsim> you still have a lot of threads in kernel - <braunr> but they don't interact during the system call - <braunr> the system call itself is usually a simple instruction with most - of it handled in hardware - <mcsim> if you invoke "write" system call, what do you do in kernel? - <braunr> you look up the function address in a table - <mcsim> you still have queues - <braunr> no - <braunr> sorry wait - <braunr> by system call, i mean "the transition from userspace to kernel - space" - <braunr> and the return - <braunr> not the service itself - <braunr> the equivalent on a microkernel system is sending a message from a - client, and receiving it in a server, not processing the request - <braunr> ideally, that's what l4 does: switching from one thread to - another, as simply and quickly as the hardware can - <braunr> so just a context and address space switch - <mcsim> at some point you put something in queue even in monolithic kernel - and make request to some other kernel thread - <braunr> the problem here is the indirection that is the capability - <braunr> yes but that's the service - <braunr> i don't care about the service here - <braunr> i care about how the request reaches the server - <mcsim> this division exist for microkernels - <mcsim> for monolithic it's all mixed - <anatoly> What does thread do when it receive a message? - <braunr> anatoly: what it wants :p - <braunr> the service - <braunr> mcsim: ? - <braunr> mixed ? - <anatoly> braunr: hm, is it a thread of some server? - <mcsim> if you have several working threads in monolithic kernel you have - to put request in queue - <braunr> anatoly: yes - <braunr> mcsim: why would you have working threads ? - <mcsim> and there is no difference either you consider it as service or - just "transition from userspace to kernel space" - <braunr> i mean, it's a good thing to have, they usually do, but they're - not implied - <braunr> they're completely irrelevant to the discussion here - <braunr> of course there is - <braunr> you might very well perform system calls that don't involve - anything shared - <mcsim> you can also have only one working thread in microkernel - <braunr> yes - <mcsim> and all clients will wait for it - <braunr> you're mixing up work queues in the discussion here - <braunr> server threads are very similar to a work queue, yes - <mcsim> but you gave me an example with 64 cores and each core runs some - server thread - <braunr> they're a thread pool handling requests - <mcsim> you can have only one thread in a pool - <braunr> they have to exist in a microkernel system to provide concurrency - <braunr> monolithic kernels can process concurrently without them though - <mcsim> why? - <braunr> because on a monolithic system, _every client thread is its own - server_ - <braunr> a thread making a system call is exactly like a client requesting - a service - <braunr> on a monolithic kernel, the server is the kernel - <braunr> and it *already* has as many threads as clients - <braunr> and that's pretty much the only thing beautiful about monolithic - kernels - <mcsim> right - <mcsim> have to think about it :) - <braunr> that's why they scale so easily compared to microkernel based - systems - <braunr> and why l4 people chose to have thread-based ipc - <braunr> but this just moves the problems to an upper level - <braunr> and is probably why they've realized one of the real values of - microkernel systems is capabilities - <braunr> and if you want to make them fast enough, they should be handled - directly by the kernel - - -## IRC, freenode, #hurd, 2013-06-13 - - <bddebian> Heya Richard. Solve the worlds problems yet? :) - <kilobug> bddebian: I fear the worlds problems are NP-complete ;) - <bddebian> heh - <braunr> bddebian: i wish i could solve mine at least :p - <bddebian> braunr: I meant the contention thing you were discussing the - other day :) - <braunr> bddebian: oh - <braunr> i have a solution that improves the behaviour yes, but there is - still contention the first time a thread performs an ipc - <bddebian> Any thread or the first time there is contention? - <braunr> there may be contention the first time a thread sends a message to - a server - <braunr> (assuming a server uses a single port set to receive requests) - <bddebian> Oh aye - <braunr> i think it's as much as can be done considering there is a - translation from capability to thread - <braunr> other schemes are just too heavy, and thus don't scale well - <braunr> this translation is one of the two important nice properties of - microkernel based systems, and translations (or indrections) usually have - a cost - <braunr> so we want to keep them - <braunr> and we have to accept that cost - <braunr> the amount of code in the critical section should be so small it - should only matter for machines with several hundreds or thousands - processors - <braunr> so it's not such a bit problem - <bddebian> OK - <braunr> but it would have been nice to have an additional valid - theoretical argument to explain how ipc isn't that slow compared to - system calls - <braunr> s/bit/big/ - <braunr> people keep saying l4 made ipc as fast as system calls without - taking that stuff into account - <braunr> which makes the community look lame in the eyes of those familiar - with it - <bddebian> heh - <braunr> with my solution, persistent applications like databases should - perform as fast as on an l4 like kernel - <braunr> but things like parallel builds, which start many different - processes for each file, will suffer a bit more from contention - <braunr> seems like a fair compromise to me - <bddebian> Aye - <braunr> as mcsim said, there is a lot of contention about everywhere in - almost every application - <braunr> and lockless stuff is hard to correctly implement - <braunr> os it should be all right :) - <braunr> ... :) - <mcsim> braunr: What if we have at least 1 thread for each core that stay - in per-core queue. When we decide to kill a thread and this thread is - last in a queue we replace it with load balancer. This is still worse - than with monolithic kernel, but it is simplier to implement from kernel - perspective. - <braunr> mcsim: it doesn't scale well - <braunr> you end up with one thread per cpu per port set - <mcsim> load balancer is only one thread - <mcsim> why would it end up like you said? - <braunr> remember the goal is to avoid contention - <braunr> your proposition is to set per cpu queues - <braunr> the way i understand what you said, it means clients will look up - a server thread in these queues - <braunr> one of them actually, the one for the cpu they're currently - running one - <braunr> so 1/ it disables migration - <braunr> or 2/ you have one server thread per client per cpu - <braunr> i don't see what a "load balancer" would do here - <mcsim> client either finds server thread without contention or it sends - message to load balancer, that redirects message to thread from global - queue. Where global queue is concatenation of local ones. - <braunr> you can't concatenate local queues in a global one - <braunr> if you do that, you end up with a global queue, and a global lock - again - <mcsim> not global - <mcsim> load balancer is just one - <braunr> then you serialize all remote messaging through a single thread - <mcsim> so contention will be only among local thread and load balancer - <braunr> i don't see how it doesn't make the load balancer global - <mcsim> it makes - <mcsim> but it just makes bootstraping harder - <braunr> i'm not following - <braunr> and i don't see how it improves on my solution - <mcsim> in your example with make -j64 very soon there will be local - threads at any core - <braunr> yes, hence the lack of scalability - <mcsim> but that's your goal: create as many server thread as many clients - you have, isn't it? - <braunr> your solution may create a lot more - <braunr> again, one per port set (or server) per cpu - <braunr> imagine this worst case: you have a single client with one thread - <braunr> which gets migrated to every cpu on the machine - <braunr> it will spawn one thread per cpu at the server side - <mcsim> why would it migrate all the time? - <braunr> it's a worst case - <braunr> if it can migrate, consider it will - <braunr> murphy's law, you know - <braunr> also keep in mind contention doesn't always occur with a global - lock - <braunr> i'm talking about potential contention - <braunr> and same things apply: if it can happen, consider it will - <mcsim> than we can make load balancer that also migrates server threads - <braunr> ok so in addition to worker threads, we'll add an additional per - server load balancer which may have to lock several queues at once - <braunr> doesn't it feel completely overkill to you ? - <mcsim> load balancer is global, not per-cpu - <mcsim> there could be contention for it - <braunr> again, keep in mind this problem becomes important for several - hundreds processors, not below - <braunr> yes but it has to balance - <braunr> which means it has to lock cpu queues - <braunr> and at least two of them to "migrate" server threads - <braunr> and i don't know why it would do that - <braunr> i don't see the point of the load balancer - <mcsim> so, you start make -j64. First 64 invocations of gcc will suffer - from contention for load balancer, but later on it will create enough - server threads and contention will disappear - <braunr> no - <braunr> that's the best case : there is always one server thread per cpu - queue - <braunr> how do you guarantee your 64 server threads don't end up in the - same cpu queue ? - <braunr> (without disabling migration) - <mcsim> load balancer will try to put some server thread to the core where - load balancer was invoked - <braunr> so there is no guarantee - <mcsim> LB can pin server thread - <braunr> unless we invoke it regularly, in a way similar to what is already - done in the SMP scheduler :/ - <braunr> and this also means one balancer per cpu then - <mcsim> why one balance per cpu? - <braunr> 15:56 < mcsim> load balancer will try to put some server thread to - the core where load balancer was invoked - <braunr> why only where it was invoked ? - <mcsim> because it assumes that if some one asked for server at core x, it - most likely will ask for the same service from the same core - <braunr> i'm not following - <mcsim> LB just tries to prefetch were next call will be - <braunr> what you're describing really looks like per-cpu work queues ... - <braunr> i don't see how you make sure there aren't too many threads - <braunr> i don't see how a load balancer helps - <braunr> this is just an heuristic - <mcsim> when server thread is created? - <mcsim> who creates it? - <braunr> and it may be useless, depending on how threads are migrated and - when they call the server - <braunr> same answer as yesterday - <braunr> there must be at least one thread receiving messages on a port set - <braunr> when a message arrives, if there aren't any spare threads, it - spawns one to receive messages while it processes the request - <mcsim> at the moment server threads are killed by timeout, right? - <braunr> yes - <braunr> well no - <braunr> there is a debian patch that disables that - <braunr> because there is something wrong with thread destruction - <braunr> but that's an implementation bug, not a design issue - <mcsim> so it is the mechanism how we insure that there aren't too many - threads - <mcsim> it helps because yesterday I proposed to hierarchical scheme, were - one server thread could wait in cpu queues of several cores - <mcsim> but this has to be implemented in kernel - <braunr> a hierarchical scheme would help yes - <braunr> a bit - <mcsim> i propose scheme that could be implemented in userspace - <braunr> ? - <mcsim> kernel should not distinguish among load balancer and server thread - <braunr> sorry this is too confusing - <braunr> please start describing what you have in mind from the start - <mcsim> ok - <mcsim> so my starting point was to use hierarchical management - <mcsim> but the drawback was that to implement it you have to do this in - kernel - <mcsim> right? - <braunr> no - <mcsim> so I thought how can this be implemented in user space - <braunr> being in kernel isn't the problem - <braunr> contention is - <braunr> on the contrary, i want ipc in kernel exactly because that's where - you have the most control over how it happens - <braunr> and can provide the best performance - <braunr> ipc is the main kernel responsibility - <mcsim> but if you have few clients you have low contention - <braunr> the goal was "0 potential contention" - <mcsim> and if you have many clients, you have many servers - <braunr> let's say server threads - <braunr> for me, a server is a server task or process - <mcsim> right - <braunr> so i think 0 potential contention is just impossible - <braunr> or it requires too many resources that make the solution not - scalable - <mcsim> 0 contention is impossible, since you have disbalance in numbers of - client threads and server threads - <braunr> well no - <braunr> it *canù be achieved - <braunr> imagine servers register themselves to the kernel - <braunr> and the kernel signals them when a client thread is spawned - <braunr> you'd effectively have one server thread per client - <braunr> (there would be other problems like e.g. when a server thread - becomes the client of another, etc..) - <braunr> so it's actually possible - <braunr> but we clearly don't want that, unless perhaps for real time - threads - <braunr> but please continue - <mcsim> what does "and the kernel signals them when a client thread is - spawned" mean? - <braunr> it means each time a thread not part of a server thread is - created, servers receive a signal meaning "hey, there's a new thread out - there, you might want to preallocate a server thread for it" - <mcsim> and what is the difference with creating thread on demand? - <braunr> on demand can occur when receiving a message - <braunr> i.e. during syscall - <mcsim> I will continue, I just want to be sure that I'm not basing on - wrong assumtions. - <mcsim> and what is bad in that? - <braunr> (just to clarify, i use the word "syscall" with the same meaning - as "RPC" on a microkernel system, whereas it's a true syscall on a - monolithic one) - <braunr> contention - <braunr> whether you have contention on a list of threads or on map entries - when allocating a stack doesn't matter - <braunr> the problem is contention - <mcsim> and if we create server thread always? - <mcsim> and do not keep them in queue? - <braunr> always ? - <mcsim> yes - <braunr> again - <braunr> you'd have to allocate a stack for it - <braunr> every time - <braunr> so two potentially heavy syscalls to allocate/free the stac - <braunr> k - <braunr> not to mention the thread itself, its associations with its task, - ipc space, maintaining reference counts - <braunr> (moar contention) - <braunr> creating threads was considered cheap at the time the process was - the main unit of concurrency - <mcsim> ok, than we will have the same contention if we will create a - thread when "the kernel signals them when a client thread is spawned" - <braunr> now we have work queues / thread pools just to avoid that - <braunr> no - <braunr> because that contention happens at thread creation - <braunr> not during a syscall - <braunr> i'll redefine the problem: the problem is contention during a - system call / IPC - <mcsim> ok - <braunr> note that my current solution is very close to signalling every - server - <braunr> it's the lazy version - <braunr> match at first IPC time - <mcsim> so I was basing my plan on the case when we create new thread when - client makes syscall and there is not enough server threads - <braunr> the problem exists even when there is enough server threads - <braunr> we shouldn't consider the case where there aren't enough server - threads - <braunr> real time tasks are the only ones which want that, and can - preallocate resources explicitely - <mcsim> I think that real time tasks should be really separated - <mcsim> For them resource availability as much more important that good - resource utilisation. - <mcsim> So if we talk about real time tasks we should apply one police and - for non-real time another - <mcsim> So it shouldn't be critical if thread is created during syscall - <braunr> agreed - <braunr> that's what i was saying : - <braunr> :) - <braunr> 16:23 < braunr> we shouldn't consider the case where there aren't - enough server threads - <braunr> in this case, we spawn a thread, and that's ok - <braunr> it will live on long enough that we really don't care about the - cost of lazily creating it - <braunr> so let's concentrate only on the case where there already are - enough server threads - <mcsim> So if client makes a request to ST (is it ok to use abbreviations?) - there are several cases: - <mcsim> 1/ There is ST waiting on local queue (trivial case) - <mcsim> 2/ There is no ST, only load balancer (LB). LB decides to create a - new thread - <mcsim> 3/ Like in previous case, but LB decides to perform migration - <braunr> migration of what ? - <mcsim> migration of ST from other core - <braunr> the only case effectively solving the problem is 1 - <braunr> others introduce contention, and worse, complex code - <braunr> i mean a complex solution - <braunr> not only code - <braunr> even the addition of a load balancer per port set - <braunr> thr data structures involved for proper migration - <mcsim> But 2 and 3 in long run will lead to having enough threads on all - cores - <braunr> then you end up having 1 per client per cpu - <mcsim> migration is needed in any case - <braunr> no - <braunr> why would it be ? - <mcsim> to balance load - <mcsim> not only for this case - <braunr> there already is load balancing in the scheduler - <braunr> we don't want to duplicate its function - <mcsim> what kind of load balancing? - <mcsim> *has scheduler - <braunr> thread weight / cpu - <mcsim> and does it perform migration? - <braunr> sure - <mcsim> so scheduler can be simplified if policy "when to migrate" will be - moved to user space - <braunr> this is becoming a completely different problem - <braunr> and i don't want to do that - <braunr> it's very complicated for no real world benefit - <mcsim> but all this will be done in userspace - <braunr> ? - <braunr> all what ? - <mcsim> migration decisions - <braunr> in your scheme you mean ? - <mcsim> yes - <braunr> explain how - <mcsim> LB will decide when thread will migrate - <mcsim> and LB is user space task - <braunr> what does it bring ? - <braunr> imagine that, in the mean time, the scheduler then decides the - client should migrate to another processor for fairness - <braunr> you'd have migrated a server thread once for no actual benefit - <braunr> or again, you need to disable migration for long durations, which - sucks - <braunr> also - <braunr> 17:06 < mcsim> But 2 and 3 in long run will lead to having enough - threads on all cores - <braunr> contradicts the need for a load balancer - <braunr> if you have enough threads every where, why do you need to balance - ? - <mcsim> and how are you going to deal with the case when client will - migrate all the time? - <braunr> i intend to implement something close to thread migration - <mcsim> because some of them can die because of timeout - <braunr> something l4 already does iirc - <braunr> the thread scheduler manages scheduling contexts - <braunr> which can be shared by different threads - <braunr> which means the server thread bound to its client will share the - scheduling context - <braunr> the only thing that gets migrated is the scheduling context - <braunr> the same way a thread can be migrated indifferently on a - monolithic system, whether it's in user of kernel space (with kernel - preemption enabled ofc) - <braunr> or* - <mcsim> but how server thread can process requests from different clients? - <braunr> mcsim: load becomes a problem when there are too many threads, not - when they're dying - <braunr> they can't - <braunr> at first message, they're *bound* - <braunr> => one server thread per client - <braunr> when the client dies, the server thread is ubound and can be - recycled - <braunr> unbound* - <mcsim> and you intend to put recycled threads to global queue, right? - <braunr> yes - <mcsim> and I propose to put them in local queues in hope that next client - will be on the same core - <braunr> the thing is, i don't see the benefit - <braunr> next client could be on another - <braunr> in which case it gets a lot heavier than the extremely small - critical section i have in mind - <mcsim> but most likely it could be on the same - <braunr> uh, no - <mcsim> becouse on this load on this core is decreased - <mcsim> *because - <braunr> well, ok, it would likely remain on the same cpu - <braunr> but what happens when it migrates ? - <braunr> and what about memory usage ? - <braunr> one queue per cpu per port set can get very large - <braunr> (i understand the proposition better though, i think) - <mcsim> we can ask also "What if random access in memory will be more usual - than sequential?", but we still optimise sequential one, making random - sometimes even worse. The real question is "How can we maximise benefit - of knowledge where free server thread resides?" - <mcsim> previous was reply to: "(17:17:08) braunr: but what happens when it - migrates ?" - <braunr> i understand - <braunr> you optimize for the common case - <braunr> where a lot more ipc occurs than migrations - <braunr> agreed - <braunr> now, what happens when the server thread isn't in the local queue - ? - <mcsim> than client request will be handled to LB - <braunr> why not search directly itself ? - <braunr> (and btw, the right word is "then") - <mcsim> LB can decide whom to migrate - <mcsim> right, sorry - <braunr> i thought you were improving on my scheme - <braunr> which implies there is a 1:1 mapping for client and server threads - <mcsim> If job of LB is too small than it can be removed and everything - will be done in kernel - <braunr> it can't be done in userspace anyway - <braunr> these queues are in the port / port set structures - <braunr> it could be done though - <braunr> i mean - <braunr> using per cpu queues - <braunr> server threads could be both in per cpu queues and in a global - queue as long as they exist - <mcsim> there should be no global queue, because there again will be - contention for it - <braunr> mcsim: accessing a load balancer implies contention - <braunr> there is contention anyway - <braunr> what you're trying to do is reduce it in the first message case if - i'm right - <mcsim> braunr: yes - <braunr> well then we have to revise a few assumptions - <braunr> 17:26 < braunr> you optimize for the common case - <braunr> 17:26 < braunr> where a lot more ipc occurs than migrations - <braunr> that actually becomes wrong - <braunr> the first message case occurs for newly created threads - <mcsim> for make -j64 this is actually common case - <braunr> and those are usually not spawn on the processor their parent runs - on - <braunr> yes - <braunr> if you need all processors, yes - <braunr> i don't think taking into account this property changes many - things - <braunr> per cpu queues still remain the best way to avoid contention - <braunr> my problem with this solution is that you may end up with one - unbound thread per processor per server - <braunr> also, i say "per server", but it's actually per port set - <braunr> and even per port depending on how a server is written - <braunr> (the system will use one port set for one server in the common - case but still) - <braunr> so i'll start with a global queue for unbound threads - <braunr> and the day we decide it should be optimized with local (or - hierarchical) queues, we can still do it without changing the interface - <braunr> or by simply adding an option at port / port set creation - <braunr> whicih is a non intrusive change - <mcsim> ok. your solution should be simplier. And TBH, what I propose is - not clearly much mory gainful. - <braunr> well it is actually for big systems - <braunr> it is because instead of grabbing a lock, you disable preemption - <braunr> which means writing to a local, uncontended variable - <braunr> with 0 risk of cache line bouncing - <braunr> this actually looks very good to me now - <braunr> using an option to control this behaviour - <braunr> and yes, in the end, it gets very similar to the slab allocator, - where you can disable the cpu pool layer with a flag :) - <braunr> (except the serialized case would be the default one here) - <braunr> mcsim: thanks for insisting - <braunr> or being persistent - <mcsim> braunr: thanks for conversation :) - <mcsim> and probably I had to start from statement that I wanted to improve - common case - - -## IRC, freenode, #hurd, 2013-06-20 - - <congzhang> braunr: how about your x15, it is impovement for mach or - redesign? I really want to know that:) - <braunr> it's both largely based on mach and now quite far from it - <braunr> based on mach from a functional point of view - <braunr> i.e. the kernel assumes practically the same functions, with a - close interface - <congzhang> Good point:) - <braunr> except for ipc which is entirely rewritten - <braunr> why ? :) - <congzhang> for from a functional point of view:) I think each design has - it intrinsic advantage and disadvantage - <braunr> but why is it good ? - <congzhang> if redesign , I may need wait more time to a new function hurd - <braunr> you'll have to wait a long time anyway :p - <congzhang> Improvement was better sometimes, although redesign was more - attraction sometimes :) - <congzhang> I will wait :) - <braunr> i wouldn't put that as a reason for it being good - <braunr> this is a departure from what current microkernel projects are - doing - <braunr> i.e. x15 is a hybrid - <congzhang> Sure, it is good from design too:) - <braunr> yes but i don't see why you say that - <congzhang> Sorry, i did not show my view clear, it is good from design - too:) - <braunr> you're just saying it's good, you're not saying why you think it's - good - <congzhang> I would like to talk hybrid, I want to talk that, but I am a - litter afraid that you are all enthusiasm microkernel fans - <braunr> well no i'm not - <braunr> on the contrary, i'm personally opposed to the so called - "microkernel dogma" - <braunr> but i can give you reasons why, i'd like you to explain why *you* - think a hybrid design is better - <congzhang> so, when I talk apple or nextstep, I got one soap :) - <braunr> that's different - <braunr> these are still monolithic kernels - <braunr> well, monolithic systems running on a microkernel - <congzhang> yes, I view this as one type of hybrid - <braunr> no it's not - <congzhang> microkernel wan't to divide process ( task ) from design view, - It is great - <congzhang> as implement view or execute view, we have one cpu and some - physic memory, as the simplest condition, we can't change that - <congzhang> that what resource the system has - <braunr> what's your point ? - <congzhang> I view this as follow - <congzhang> I am cpu and computer - <congzhang> application are the things I need to do - <congzhang> for running the program and finish the job, which way is the - best way for me - <congzhang> I need keep all the thing as simple as possible, divide just - from application design view, for me no different - <congzhang> desgin was microkernel , run just for one cpu and these - resource. - <braunr> (well there can be many processors actually) - <congzhang> I know, I mean hybrid at some level, we can't escape that - <congzhang> braunr: I show my point? - <braunr> well l4 systems showed we somehow can - <braunr> no you didn't - <congzhang> x15's api was rpc, right? - <braunr> yes - <braunr> well a few system calls, and mostly rpcs on top of the ipc one - <braunr> jsu tas with mach - <congzhang> and you hope the target logic run locally just like in process - function call, right? - <braunr> no - <braunr> it can't run locally - <congzhang> you need thread context switch - <braunr> and address space context switch - <congzhang> but you cut down the cost - <braunr> how so ? - <congzhang> I mean you do it, right? - <congzhang> x15 - <braunr> yes but no in this way - <braunr> in every other way :p - <congzhang> I know, you remeber performance anywhere :p - <braunr> i still don't see your point - <braunr> i'd like you to tell, in one sentence, why you think hybrids are - better - <congzhang> balance the design and implement problem :p - <braunr> which is ? - <congzhang> hybird for kernel arc - <braunr> you're stating the solution inside the problem - <congzhang> you are good at mathmatics - <congzhang> sorry, I am not native english speaker - <congzhang> braunr: I will find some more suitable sentence to show my - point some day, but I can't find one if you think I did not show my - point:) - <congzhang> for today - <braunr> too bad - <congzhang> If i am computer I hope the arch was monolithic, If i am - programer I hope the arch was microkernel, that's my idea - <braunr> ok let's get a bit faster - <braunr> monolithic for performance ? - <congzhang> braunr: sorry for that, and thank you for the talk:) - <braunr> (a computer doesn't "hope") - <congzhang> braunr: you need very clear answer, I can't give you that, - sorry again - <braunr> why do you say "If i am computer I hope the arch was monolithic" ? - <congzhang> I know you can slove any single problem - <braunr> no i don't, and it's not about me - <braunr> i'm just curious - <congzhang> I do the work for myself, as my own view, all the resource - belong to me, I does not think too much arch related divide was need, if - I am the computer :P - <braunr> separating address spaces helps avoiding serious errors like - corrupting memory of unrelated subsystems - <braunr> how does one not want that ? - <braunr> (except for performance) - <congzhang> braunr: I am computer when I say that words! - <braunr> a computer doesn't want anything - <braunr> users (including developers) on the other way are the point of - view you should have - <congzhang> I am engineer other time - <congzhang> we create computer, but they are lifeable just my feeling, hope - not talk this topic - <braunr> what ? - <congzhang> I mark computer as life things - <braunr> please don't - <braunr> and even, i'll make a simple example in favor of isolating - resources - <braunr> if we, humans, were able to control all of our "resources", we - could for example shut down our heart by mistake - <congzhang> back to the topic, I think monolithic was easy to understand, - and cut the combinatorial problem count for the perfect software - <braunr> the reason the body have so many involuntary functions is probably - because those who survived did so because these functions were - involuntary and controlled by separated physiological functions - <braunr> now that i've made this absurd point, let's just not consider - computers as life forms - <braunr> microkernels don't make a system that more complicated - <congzhang> they does - <braunr> no - <congzhang> do - <braunr> they create isolation - <braunr> and another layer of indirection with capabilities - <braunr> that's it - <braunr> it's not that more complicated - <congzhang> view the kernel function from more nature view, execute some - code - <braunr> what ? - <congzhang> I know the benefit of the microkernel and the os - <congzhang> it's complicated - <braunr> not that much - <congzhang> I agree with you - <congzhang> microkernel was the idea of organization - <braunr> yes - <braunr> but always keep in mind your goal when thinking about means to - achieve them - <congzhang> we do the work at diferent view - <kilobug> what's quite complicated is making a microkernel design without - too much performances loss, but aside from that performances issue, it's - not really much more complicated - <congzhang> hurd do the work at os level - <kilobug> even a monolithic kernel is made of several subsystems that - communicated with each others using an API - <core-ix> i'm reading this conversation for some time now - <core-ix> and I have to agree with braunr - <core-ix> microkernels simplify the design - <braunr> yes and no - <braunr> i think it depends a lot on the availability of capabilities - <core-ix> i have experience mostly with QNX and i can say it is far more - easier to write a driver for QNX, compared to Linux/BSD for example ... - <braunr> which are the major feature microkernels usually add - <braunr> qnx >= 5 do provide capabilities - <braunr> (in the form of channels) - <core-ix> yeah ... it's the basic communication mechanism - <braunr> but my initial and still unanswered question was: why do people - think a hybrid kernel is batter than a true microkernel, or not - <braunr> better* - <congzhang> I does not say what is good or not, I just say hybird was - accept - <braunr> core-ix: and if i'm right, they're directly implemented by the - kernel, and not a userspace system server - <core-ix> braunr: evolution is more easily accepted than revolution :) - <core-ix> braunr: yes, message passing is in the QNX kernel - <braunr> not message passing, capabilities - <braunr> l4 does message passing in kernel too, but you need to go through - a capability server - <braunr> (for the l4 variants i have in mind at least) - <congzhang> the operating system evolve for it's application. - <braunr> congzhang: about evolution, that's one explanation, but other than - that ? - <braunr> core-ix: ^ - <core-ix> braunr: by capability you mean (for the lack of a better word - i'll use) access control mechanisms? - <braunr> i mean reference-rights - <core-ix> the "trusted" functionality available in other OS? - <braunr> http://en.wikipedia.org/wiki/Capability-based_security - <braunr> i don't know what other systems refer to with "trusted" - functionnality - <core-ix> yeah, the same thing - <congzhang> for now, I am searching one way to make hurd arm edition - suitable for Raspberry Pi - <congzhang> I hope design or the arch itself cant scale - <congzhang> can be scale - <core-ix> braunr: i think (!!!) that those are implemented in the Secure - Kernel (http://www.qnx.com/products/neutrino-rtos/secure-kernel.html) - <core-ix> never used it though ... - <congzhang> rpc make intercept easy :) - <braunr> core-ix: regular channels are capabilities - <core-ix> yes, and by extensions - they are in the kenrel - <braunr> that's my understanding too - <braunr> and that one thing that, for me, makes qnx an hybrid as well - <congzhang> just need intercept in kernel, - <core-ix> braunr: i would dive the academic aspects of this ... in my mind - a microkernel is system that provides minimal hardware abstraction, - communication primitives (usually message passing), virtual memory - protection - <core-ix> *wouldn't ... - <braunr> i think it's very important on the contrary - <braunr> what you describe is the "microkernel dogma" - <braunr> precisely - <braunr> that doesn't include capabilities - <braunr> that's why l4 messaging is thread-based - <braunr> and that's why l4 based systems are so slow - <braunr> (except okl4 which put back capabilities in the kernel) - <core-ix> so the compromise here is to include capabilities implementation - in the kernel, thus making the final product hybrid? - <braunr> not only - <braunr> because now that you have them in kernel - <braunr> the kernel probably has to manage memory for itself - <braunr> so you need more features in the virtual memory system - <core-ix> true ... - <braunr> that's what makes it a hybrid - <braunr> other ways being making each client provide memory, but that's - when your system becomes very complicated - <core-ix> but I believe this is true for pretty much any "general OS" case - <braunr> and some resources just can't be provided by a client - <braunr> e.g. a client can't provide virtual memory to another process - <braunr> okl4 is actually the only pragmatic real-world implementation of - l4 - <braunr> and they also added unix-like signals - <braunr> so that's an interesting model - <braunr> as well as qnx - <braunr> the good thing about the hurd is that, although it's not kernel - agnostic, it doesn't require a lot from the underlying kernel - <core-ix> about hurd? - <braunr> yes - <core-ix> i really need to dig into this code at some point :) - <braunr> well you may but you may not see that property from the code - itself - - -## IRC, freenode, #hurd, 2013-06-28 - - <teythoon> so tell me about x15 if you are in the mood to talk about that - <braunr> what do you want to know ? - <teythoon> well, the high level stuff first - <teythoon> like what's the big picture - <braunr> the big picture is that x15 is intended to be a "better mach for - the hurd - <braunr> " - <braunr> mach is too general purpose - <braunr> its ipc mechanism too powerful - <braunr> too complicated, error prone, and slow - <braunr> so i intend to build something a lot simpler and faster :p - <teythoon> so your big picture includes actually porting hurd? i thought i - read somewhere that you have a rewrite in mind - <braunr> it's a clone, yes - <braunr> x15 will feature mostly sync ipc, and no high level types inside - messages - <braunr> the ipc system call will look like what qnx does - <braunr> send-recv from the client, recv/reply/reply-recv from the server - <teythoon> but doesn't sync mean that your context switch will have to be - quite fast? - <braunr> how does that differ from the async approach ? - <braunr> (keep in mind that almost all hurd RPCs are synchronous) - <teythoon> yes, I know, and it also affects async mode, but a slow switch - is worse for the sync case, isn't it? - <teythoon> ok so your ipc will be more agnostic wrt to what it transports? - unlike mig I presume? - <braunr> no it's the same - <braunr> yes - <braunr> input will be an array, each entry denoting either memory or port - rights - <braunr> (or directly one entry for fast ipcs) - <teythoon> memory as in pointers? - <braunr> (well fast ipc when there is only one entry to avoid hitting a - table) - <braunr> pointer/size yes - <teythoon> hm, surely you want a way to avoid copying that, right? - <braunr> the only operation will be copy (i.e. unlike mach which allows - sharing) - <braunr> why ? - <braunr> copy doesn't exclude zero copy - <braunr> (zero copy being adjusting page tables with copy on write - techniques) - <teythoon> right - <teythoon> but isn't that too coarse, like in cow a whole page? - <braunr> depends on the message size - <braunr> or options provided by the caller, i don't know yet - <teythoon> oh, you are going to pack the memory anyway? - <braunr> depends on the caller - <braunr> i'm not yet sure about these details - <braunr> ideally, i'd like to avoid serialization altogether - <teythoon> wouldn't that be like cheating b/c it's the first copy? - <braunr> directly pass pointers/sizes from the sender address space, and - either really copy or use zero copy - <teythoon> right, but then you're back at the page size issue - <braunr> yes - <braunr> it's not a real issue - <braunr> the kernel must support both ways - <braunr> the minor issue is determining which way to choose - <braunr> it's not a critical issue - <braunr> my current plan is to always copy, unless the caller has - explicitely set a flag and is passing properly aligned buffers - <teythoon> u sure? I mean the caller is free to arange the stuff he intends - to send anyway he likes, how are you going to cow that then? - <teythoon> ok - <teythoon> right - <braunr> properly aligned buffers :) - <braunr> otherwise the kernel rejects the request - <teythoon> that's reasonable, yes - <braunr> in addition to being synchronous, ipc will also take a special - path in the scheduler to directly use the client scheduling context - <braunr> avoiding the sleep/wakeup overhead, and providing priority - inheritence by side effect - <teythoon> uh, but wouldn't dropping serialization create security and - reliability issues? if the receiver isn't doing a proper job sanitizing - its stuff - <braunr> why would the client not sanitize ? - <braunr> err - <braunr> server - <braunr> it has to anyway - <teythoon> sure, but a proper parser written once might be more robust, - even if it adds overhead - <teythoon> the serialization i mean - <braunr> it's just a layer - <braunr> even with high level types, you still need to sanitize - <braunr> the real downside is loosing cross architecture portability - <braunr> making the potential implementation of a single system image a lot - more restricted or difficult - <braunr> but i don't care about that much - <braunr> mach was built with this in mind though - <teythoon> it's a nice idea, but i don't believe anyone does ssi anymore - <braunr> i don't know - <teythoon> and certainly not across architectures - <braunr> there are few projects - <braunr> anyway it's irrelevant currently - <braunr> and my interface just restricts it, it doesn't prevent it - <braunr> so i consider it an acceptable compromise - <teythoon> so, does it run? what does it do? - <teythoon> it certainly is, yes - <braunr> for now, it manages memory (physical, virtual, kernel, and soon, - anonymous) - <braunr> support multiple processors with the required posix scheduling - policies - <braunr> (it uses a cute proportionally fair time sharing algorithm) - <braunr> there are locks (spin locks, mutexes, condition variables) and - lockless stuff (à la rcu) - <braunr> both x86 and x86_64 are supported - <braunr> (even pae) - <braunr> work queues - <teythoon> sounds impressive :) - <braunr> :) - <braunr> i also added basic debugging - <braunr> stack trace (including getting the symbol table) handling - <braunr> so yes, it's much much better than what i previously did - <braunr> and on the right track - <braunr> it already scales a lot better than mach for what it does - <braunr> there are generic data structures (linked list, red-black tree, - radix tree) - <braunr> the radix tree supports lockless lookups, so looking up both the - page cache and the ipc spaces is lockless) - <teythoon> that's nice :) - <braunr> there are a few things using global locks, but there are TODOs - about them - <braunr> even with that, it should be scalable enough for a start - <braunr> and improving those parts shouldn't be too difficult - - -## IRC, freenode, #hurd, 2013-07-10 - - <nlightnfotis> braunr: From what I have understood you aim for x15 to be a - production ready μ-kernel for usage in the Hurd? Or is it unrelated to - the Hurd? - <braunr> nlightnfotis: it's for a hurd clone - <nlightnfotis> braunr: I see. Is it close to any of the existing - microkernels as far as its design is concerned (L4, Viengoos) or is it - new research? - <braunr> it's close to mach - <braunr> and qnx - - -## IRC, freenode, #hurd, 2013-07-29 - - <braunr> making progress on x15 pmap module - <braunr> factoring code for mapping creation/removal on current/kernel and - remote processes - <braunr> also started "swap emulation" by reserving some physical memory to - act as swap backing store - <braunr> which will allow creating memory pressure very early in the - development process - - -## IRC, freenode, #hurd, 2013-08-23 - - < nlightnfotis> braunr: something a little bit irrelevant: how many things - are missing from mach to be considered a solid base for the Hurd? Is it - only SMP and x86_64 support? - < braunr> define "solid base for the hurd" - < nlightnfotis> solid enough to not look for a replacement for it - < braunr> then i'd say, from my very personal point of view, that you want - x15 - < nlightnfotis> I didn't understand this. Are you planning for x15 to be a - better mach? - < braunr> with a different interface, so not compatible - < braunr> and thus, not mach - < nlightnfotis> is the source code for it available? Can I read it - somewhere? - < braunr> the implied answer being: no, mach isn't a solid base for the - hurd considering your definition - < braunr> http://git.sceen.net/rbraun/x15.git/ - < nlightnfotis> thanks. for that. So it's definite that mach won't stay for - long as the Hurd's base, right? - < braunr> it will, for long - < braunr> my opinion is that it needs to be replaced - < nlightnfotis> is it possible that it (slowly) gets rearchitected into - what's being considered a second generation microkernel, or is it - hopeless? - < braunr> it would require a new interface - < braunr> you can consider x15 to be a modern mach, with that new interface - < braunr> from a high level view, it's very similar (it's a hybrid, with - both scheduling and virtual memory management in the kernel) - < braunr> ipc change a lot - - -## IRC, freenode, #hurd, 2013-09-23 - - <braunr> for those of us interested in x15 and scalability in general: - http://darnassus.sceen.net/~rbraun/radixvm_scalable_address_spaces_for_multithreaded_applications.pdf - <braunr> finally an implementation allowing memory mapping to occur - concurrently - <braunr> (which is another contention issue when using mach-like ipc, which - often do need to allocate/release virtual memory) - - -## IRC, freenode, #hurd, 2013-09-28 - - <rah> braunr: https://git.sceen.net/rbraun/x15.git/plain/README - <rah> "X15 is a free microkernel." - <rah> braunr: what distinguishes it from existing microkernels? - - -## IRC, freenode, #hurd, 2013-09-29 - - <braunr> rah: the next part maybe ? - <braunr> "Its purpose is to provide a foundation for a Hurd-like operating - system." - <rah> braunr: there are already microkernels that canbe used as the - foundatin for Hurd=like operating systems; why are you creating another - one? - <rah> braunr: what distinguishes your microkernel from existing - microkernels? - <tschwinge> rah: - http://www.gnu.org/software/hurd/microkernel/mach/deficiencies.html - <braunr> rah: it's better :) - <braunr> rah: and please, cite one suitable kernel for the hurd - <rah> tschwinge: those are deficiencies in Mach; I'm asking about x15 - <rah> braunr: in what way is it better exactly? - <braunr> rah: more performant, more scalable - <rah> braunr: how? - <braunr> better algorithms, better interfaces - <braunr> for example, it supports smp - <rah> ah - <rah> it supports SMP - <rah> ok - <rah> that's one thing - <braunr> it implements lockless synchronization à la rcu - <rah> are there any others? - <rah> ok - <rah> lockless sync - <rah> anything else? - <braunr> it can scale from 4MB of physical memory up to several hundreds - GiB - <braunr> ipc is completely different, leading to simpler code, less data - involved, faster context switches - <braunr> (although there is no code for that yet) - <rah> how can it support larger memory while other microkernels can't? - <rah> how is the ipc "different"? - <braunr> others can - <braunr> gnumach doesn't - <rah> how can it support larger memory while gnumach can't? - <azeem_> because it's not the same code base? - <braunr> gnumach doesn't support temporary kernel mapping - <rah> ok, so x15 supports temporary kernel mapping - <braunr> not exactly - <braunr> virtual memory is completely different - <rah> how so? - <braunr> gnumach does the same as linux, physical memory is mapped in - kernel space - <braunr> so you can't have more physical memory than you have kernel space - <braunr> which is why gnumach can't handle more than 1.8G right now - <braunr> it's a 2/2 split - <braunr> in x15, the kernel maps what it needs - <braunr> and can map it from anywhere in physical memory - <tschwinge> rah: I think basically all this has already been discussed - before and captured on that page? - <braunr> it already supports i386/pae/amd64 - <rah> I see - <braunr> the drawback is that it needs to update kernel page tables more - often - <braunr> on linux, a small part of the kernel space is reserved for - temporary mappings, which need page table updates too - <braunr> but most allocations don't use that - <braunr> it's complicated - <braunr> also, i plan to make virtual memory operations completely - concurrent on x15, similar to what is described in radixvm - <rah> ok - <braunr> which means mapping operations on non overlapping regions won't be - serialized - <braunr> a big advantage for microkernels which base their messaging - optimizations on mapping - <braunr> so simply put, better performance because of simpler ipc and data - structures, and better scalability because of improved data structure - algorithms and concurrency - <rah> tschwinge: yes but that page is no use to someone who wants a summary - of what distinguishes x15 - <braunr> x15 is still far from complete, which is why i don't advertise it - other than here - <rah> "release early, release often"? - <braunr> give it a few more years :p - <braunr> release what ? - <braunr> something that doesn't work ? - <rah> software - <rah> yes - <braunr> this release early practice applies to maintenance - <rah> release something that doesn't work so that others can help make it - work - <braunr> not big developments - <braunr> i don't want that for now - <braunr> i have a specific idea of what i want, and both explaining and - defending it would take time, better spent in development itself - <braunr> just wait for a first prototype - <braunr> and then you'll see if you want to help or not - * rah does not count himself as one of the "others" who might help make it - work - <braunr> one big difference with other microkernels is that x15 is - specifically intended to run a unix like system - <braunr> a hurd like system providing a psoix interface more accurately - <braunr> and efficiently - <braunr> so for example, while many microkernels provide only sync ipc, x15 - provides both sync ipc and signals - <braunr> and then, there are a lot of small optimizations, like port names - which will transparently identify as file descriptors - <braunr> light reference counting - <braunr> a restriction on ipc that only allows reliable transfers across - network to machines with same arch and endianness - <braunr> etc.. - - -## Summary - -Created on 2013-09-29 by wiki user *BobHam*, *rah* on IRC. - -> The x15 microkernel is under development by Richard Braun. Overall, x15 is intended to provide better performance because of simpler IPC and data structures and better scalability because of improved data structure algorithms and concurrency. -> -> The following specific features are intended to distinguish x15 from other microkernels. However, it should be noted that the microkernel is under heavy development and so the list may (and almost certainly will) change. -> -> * SMP support -> * Lockless synchronisation à la RCU -> * Support for large amounts of physical memory. GNU Mach does the same as Linux, physical memory is mapped in kernel space so you can't have more physical memory than you have kernel space which is why GNU Mach can't handle more than 1.8G right now, it's a 2/2 split. In x15, the kernel maps what it needs and can map it from anywhere in physical memory the drawback is that it needs to update kernel page tables more often. -> * Virtual memory operations are planned to be completely concurrent on x15, similar to what is described in radixvm -> * Intended to efficiently run a Hurd-like system providing a POSIX interface -> * Providing both synchronisation IPC and signals, as opposed to just synchronisation IPC -> * Port names which will transparently identify as file descriptors -> * Light reference counting -> * A restriction on IPC that only allows reliable transfers across network to machines with same arch and endianness -> * etc. - - -## IRC, freenode, #hurd, 2013-10-12 - - <zacts> braunr: are you still working on x15/propel? - * zacts checks the git logs - <braunr> zacts: taking a break for now, will be back on it when i have a - clearer view of the new vm system - - -## IRC, freenode, #hurd, 2013-10-15 - - <gnufreex> braunr, few questions about x15. I was reading IRC logs on hurd - site, and in the latest part, you say (or I misunderstood) that x15 is - now hybrid kernel. So what made you change design... or did you? - <braunr> gnufreex: i always intended to go for a hybrid - - -## IRC, freenode, #hurd, 2013-10-19 - - <zacts> braunr: when do you plan to start on x15/propel again? - <braunr> zacts: after i'm done with thread destruction on the hurd - -[[open_issues/libpthread/t/fix_have_kernel_resources]]. - - <zacts> and do you plan to actually run hurd on top of x15, or are you - still going to reimplement hurd as propel? - <braunr> and no, i don't intend to run the hurd on top of x15 - - -## IRC, freenode, #hurd, 2013-10-24 - - <neal> braunr: What is your Mach replacement doing? - <braunr> "what" ? :) - <braunr> you mean how i guess - <neal> Sure. - <braunr> well it's not a mach replacement any more - <braunr> and for now it's stalled while i'm working on the hurd - <neal> that could be positive :) - <braunr> it's in good shape - <neal> how did it diverge? - <braunr> sync ipc, with unix-like signals - <braunr> and qnx-like bare data messages - <neal> hmm, like okl5? - <braunr> (with scatter gather) - <neal> okl4 - <braunr> yes - <braunr> btw, if you can find a document that explains this property of - okl4, i'm interested, since i can't find it again on my own :/ - <braunr> basically, x15 has a much lighter ipc interface - <neal> capabilities? - <braunr> mach ports are mostly retained - <braunr> but reference counting will be simplified - <neal> hmm - <neal> I don't like the reference counting part - <braunr> port names will be plain integers, to directly be usable as file - descriptors and avoid a useless translation layer - <braunr> (same as in qnx) - <neal> this sounds like future tense - <braunr> there is no ipc code yet - <neal> so I guess this stuff is not implemented - <neal> ok. - <braunr> next step is virtual memory - <braunr> and i'm taking my time because i want it to be a killer feature - <neal> so if you don't IPC and you don't have VM, what do you have? :) - <braunr> i have multiprocessor multithreading - <neal> I see. - <braunr> mutexes, condition variables, rcu-like lockless synchronization, - work queues - <braunr> basic bsd-like virtual memory - <braunr> which i want to rework - <neal> I ignored all of that in Viengoos :) - <braunr> and since ipc will still depend on virtual memory for zero-copy, i - want the vm system to be right - <braunr> well, i'm more interested in the implementation than the - architecture - <braunr> for example, i have unpublished code that features a lockless - radix tree for vm_object lookups - <braunr> that's quite new for a microkernel based system, but the ipc - interface itself is very similar to what already exists - <braunr> your half-sync ipc are original :) - <neal> I'm considering getting back in the OS game. - <braunr> oh - <neal> But, I'm not going to write a kernel this time. - <braunr> did anyone here consider starting a company for such things, like - genode did ? - <neal> I was considering using genode as a base. - <braunr> neal: why genode ? - <neal> I want to build a secure system. - <neal> I think the best way to do that is using capabilities. - <neal> Genode runs on Fiasco.OC, for instance - <neal> and it provides a lot of infrastructure - <braunr> neal: why not l4re for example ? - <braunr> neal: how important is the ability to revoke capabilities ? - -In the discussion on [[community/gsoc/project_ideas/object_lookups]], *IRC, -freenode, #hurd, 2013-10-24*: - - <teythoon> and, with some effort, getting rid of the hash table lookup by - letting the kernel provide the address of the object (iirc neil knew the - proper term for that) - <braunr> teythoon: that is a big interface change - <teythoon> how so - <braunr> optimizing libihash and libpthread should already be a good start - <braunr> well how do you intend to add this information ? - <braunr> ok, "big" is overstatement, but still, it's a low level interface - change that would probably break a lot of things - <teythoon> store a pointer in the port structure in gnumach, make that - accessible somehow - <braunr> yes but how ? - <teythoon> interesting question indeed - <braunr> my plan for x15 is to make this "label" part of received messages - <braunr> which means you need to change the format of messages - <braunr> that is what i call a big change - - -### IRC, freenode, #hurd, 2013-10-31 - - <antrik> neal: you mentioned you want to use Genode as a base... what - exactly would you want to build on top of it, different than what the - Genode folks are doing? - -[[Genode]]. - - <neal> antrik: I want to build a secure operating system. - <neal> antrik: One focused on user security. - - <neal> braunr: You mean revoke individual send rights? - <neal> braunr: Or, what do you mean? - <neal> Or do you mean the ability to receive anotification on revocation? - <braunr> neal: yes, revoking individual send rights - <neal> I don't think it is needed in practice. - <braunr> neal: ok - <neal> But, you need a membrane object - <neal> Here's the idea: - <braunr> like a peropen ? - <neal> you have say a file server - <neal> and a proxy - <neal> a process only talks to the file server via the proxy - <neal> for the proxy to revoke access to the file object it gave out, it - needs to either use your revoke - <neal> interpose on all ipcs (which is expensive) - <neal> or use a proxy object/membrane - <neal> which basically forwards messages to the underlying object - <braunr> isn't that also interposing ? - <neal> of course - <neal> but if it is done in the kernel, it is fast - <braunr> ah in the kernel - <neal> you just walk a linked list - <braunr> what's the difference with a peropen object ? - <neal> That's another option - <neal> you use a peropen and then provide a call to force the per-open to - be closed - <neal> so the proxy now invokes the server - <neal> the issue here is that the proxy has to trust the server - <braunr> yes - <braunr> how can you not trust servers ? - <neal> that is, if the intent is to prevent further communication between - the server and the process, the server may ignore the request - <neal> in this case, you probably trust the server - <braunr> hum - <neal> but it could be that you have two processes communicating - <braunr> if the intent is to prevent communication, doesn't the client just - need to humm not communicate ? :) - <neal> the point is that the two processes are colluding - <braunr> what are these two processes ? - <neal> I'm not sure this case is of practical relevance - <braunr> ok - <neal> https://www.cs.cornell.edu/courses/cs513/2002sp/L10.html - <braunr> thanks - - -### IRC, freenode, #hurd, 2013-11-14 - - <antrik> neal: hm... I was under the impression that the Genode themselves - are also interested in user security... what is missing from their - version that you want to add? - <antrik> err... the Genode folks - <neal> antrik: I'm missing some context - <antrik> neal: a while back you said that you want to build a secure system - on top of Genode - <neal> yes - <neal> the fact that they are doing what I want is great - <neal> but there is more to a secure system than an operating system - <antrik> ah, so it's about applications+ - <antrik> ? - <neal> yes, that is part of it - <neal> it's also about secure messaging - <neal> and hiding "meta-data" - <braunr> i'm still wondering how you envision the powerbox - <neal> when a program wants the user to select a file, it makes an upcall - to the power box application - <antrik> braunr: you can probably find some paper from Shapiro ;-) - <braunr> well, sure, it looks easy - <braunr> but is there always a power box application ? - <braunr> is there always a guarantee there won't be recursive calls made by - that application ? - <braunr> how does it integrate with the various interfaces a system can - have ? - <neal> there is always a power box application - <neal> I don't know what you mean by recursive calls - <braunr> aer techniques such as remembering for some time like sudo does - applicable to a powerbox application ? - <neal> if you mean many calls, then it is possible to rate limit it - <braunr> well, the powerbox will use messaging itself - <braunr> is it always privileged ? - <braunr> privileged enough - <neal> it is privileged such like the X11 display manager is privileged and - can see all of the video content - <braunr> what else other than accessing a file would it be used for ? - <braunr> one case i think of is accessing the address space of another - application, in debuggers - <braunr> 14:56 < neal> there is always a power box application - <braunr> what would it be when logging on a terminal ? - <antrik> braunr: when running pure command line tools, you can already pass - the authority as part of the command line. however, I'm wondering whether - it really makes sense to apply this to traditional shell tools... - <braunr> that's one of my concerns - <braunr> when does it really make sense ? - <antrik> for interactive use (opening new files from within a running - program), I don't think it can be accomplished in a pure terminal - interaction model... - <braunr> and you say "you pass the authority" - <antrik> braunr: it makes sense for interactive applications - <braunr> i thought the point of the powerbox is precisely not to do that - <antrik> no, it's still possible and often reasonable to pass some initial - authority on startup. the powerbox is only necessary when further access - needs to be provided at runtime - <braunr> ok - <neal> the power box enable dynamic delegation of authority, as antrik said - <braunr> ok - <braunr> but how practical is it ? - <neal> applications whose required authority is known apriori and - max(required authority) is approximately min(required authority) can be - handled with static policies - <braunr> don't application sometimes need a lot of additional authority ? - <braunr> ok - <antrik> actally, thinking about it, a powerbox should also be possible on - a simple terminal, if we make sure the application doesn't get full - control of the terminal, but rather allow the powerbox to temporarily - take over input/output without the application being able to - interpose... so not quite a traditional UNIX terminal, but close enough - I'd say - <braunr> the terminal itself maybe ? - <antrik> hm... that would avoid having to implement a more generic - multiplexing approach -- but it would mix things that are normally quite - orthogonal... - <antrik> BTW, I personally believe terminals need to get smarter anyways - :-) - <braunr> ok - <antrik> the traditional fully linear dialog has some nice properties; but - it is also pretty limited, leading to usability problems soon. I have - some vague ideas for an approach that still looks mostly like a linear - dialog, but is actually more structured - - -## IRC, freenode, #hurd, 2013-11-04 - - <braunr> yes the learning curve [of the Hurd] is too hard - <braunr> that's an entry barrier - <braunr> this is why i use well known posix-like (or other well - established) apis in x15 - <braunr> also why i intend to make port rights blend into file descriptors - <teythoon> right - <braunr> well - <braunr> the real reason is efficiency - <braunr> but matching existing practices is very good too - - -## IRC, freenode, #hurd, 2013-11-08 - - <gnufreex> braunr, how is work on x-15 progressing? Is there some site to - check what is new? - <braunr> gnufreex: stalled for 2 months - <braunr> i'm working on the hurd for now, will get back to it later - <braunr> no site - <braunr> well - <gnufreex> so, you hit some design problem, or what? I mean why stalled - <braunr> http://git.sceen.net/rbraun/x15.git/ :p - <gnufreex> Thanks - <braunr> something like that yes - <braunr> i came across - http://darnassus.sceen.net/~rbraun/radixvm_scalable_address_spaces_for_multithreaded_applications.pdf - <gnufreex> I read that, I think I found it on Hurd site. - <braunr> and since x15 aims at being performant and scalable, it seems like - a major feature to bring in - <braunr> but it's not simple to integrate - <gnufreex> So you want to add that? - <braunr> gnufreex: yes - <gnufreex> branur, but what are the problems? - <braunr> ? - <braunr> ah - <braunr> you really want to know ? :) - <gnufreex> Well... yeah - <braunr> you need to know both x15 and radixvm for that - <braunr> for one, refcache, as described in the radixvm paper, doesn't seem - scalable - <braunr> it is in practice in their experiments, but only because they - didn't push some parameters too high - <braunr> so i need to rethink it - <gnufreex> I don't know x15... but I read radixvm paper - <braunr> next, the bsd-like vm used by x15 uses a red-black tree to store - memory areas, which doesn't need external storage - <braunr> radixvm as implemented in xv6 is only used for user processes, not - the kernel - <braunr> which means the kernel allocator is a separate implementation, as - it's done in linux - <braunr> x15 uses the same implementation for both the kernel and user maps - <braunr> which results in a recursion problem - <braunr> because a radix tree uses external nodes that must be dynamically - allocated - <gnufreex> so you would pretty much need to rewrite x15 - <braunr> no - <braunr> just vm/ - <braunr> and $arch/pmap - <braunr> and yes, pmap needs to handle per-core page tables - <braunr> something i wanted to add already but couldn't because of similar - recursion problems - <gnufreex> Yeah, vm system... but what else did you do with x15... it is at - early stage... - <braunr> multithreading - <gnufreex> That doesn't need to be rewriten? - <braunr> no - <gnufreex> Ok... good. - <braunr> physical memory allocation neither - <braunr> only virtual memory - <gnufreex> is x15 in runable state? I mean in virtual machine? - <braunr> you can start it - <braunr> but you won't go far :) - <gnufreex> What do you use as development platform? - <braunr> it basically detects memory and processors, starts idle, migration - and worker threads, and leaves - <gnufreex> Is it compilable on fedora 19 - <braunr> probably - <braunr> i use debian stable - <braunr> and unstable on the hurd - <gnufreex> ok, I will probably try it in KVM... - <braunr> better do it on real hardware too in case you find a bug - <gnufreex> I cant make new partition now... it seems my hard drive is - dying. When I get a new one I will try on real harware. - <braunr> you don't need a new partition - <braunr> the reason radixvm is important is twofold - <braunr> 1/ ipc will probably make use of the core vm operations used by - mmap and munmap - <braunr> 2/ no other system currently provides scalable - mmap/munmap/mprotect - <gnufreex> Yes, that would make x15 pretty special... - <gnufreex> But I read somewhere that you wanted to implement RCU during - summer - <gnufreex> Did you do that? - - -## IRC, freenode, #hurd, 2013-11-12 - - <braunr> neal: about secure operating systems - <braunr> i assume you consider clients providing their own memory a strong - requirement for that, right ? - <neal> no - <neal> I'm less interested in availability - <neal> or performance guarantees - <braunr> ok - <braunr> but - <braunr> i thought it was a requirement to avoid denial of service - <neal> of course - <braunr> then why don't you consider it required ? - <neal> I want something working in a reasonable amount of time :) - <braunr> agreed - <neal> more seriously: - <neal> my primary requirement is that a program cannot access information - that the user has not authorized it to access - <braunr> ok - <neal> the requirement that you are suggesting is that a program be able to - access information that the user has authorized it to access - <neal> this is availability - <braunr> i'm not following - <braunr> what's the difference ? - <neal> assume we have two programs: A and B - <neal> on Unix, if they run under the same uid, they access access each - other files - <neal> I want to fix this - <braunr> ok, that's not explicit authorization - <braunr> but is that what you mean ? - <neal> Now, assuming that A cannot access B's data and vice versa - <neal> we have an availability problem - <neal> A could prevent B from accessing its data - <neal> via a DoS attach - <neal> I'm not going to try to fix that. - <braunr> ok - <braunr> and how do you intend to allow A to access B's data ? - <braunr> i guess the powerbox mentioned in the critique - <braunr> but do you have a more precise description about something - practical to use ? - - -## IRC, freenode, #hurd, 2013-11-14 - -In context of [[hurd/libports]], *Open Issues*, *IRC, freenode, #hurd, -2013-11-14*. - - <braunr> fyi, x15 will not provide port renaming - <braunr> teythoon: also, i'm considering enforcing port names to be as - close as possible to 0 when being allocated as part of the interface - <braunr> what do you think about that ? - <teythoon> braunr: that's probably wise, yes - <teythoon> you could hand out receive ports close to 0 and send ports close - to ~0 - <braunr> teythoon: what for ? - <teythoon> well, if one stores only one kind in an array, it won't waste as - much space - <braunr> this also means you need to separate receive from send rights in - the interface - <braunr> so that you know where to look for them - <braunr> i'm not sure it's worth the effort - <braunr> using the same code for them both looks more efficient - <braunr> the right lookup code is probably one of the hottest path in the - system - <teythoon> right - <neal> one of the nice things about not reusing port names is that it helps - catch bugs - <neal> you don't want to accidently send a message to the wrong recipient - <braunr> how could you, if the same name at different times denotes - different rights ? - <neal> you forget to clean up something - <braunr> if you don't clean, how could you get the same name for a right - you didn't release ? - <neal> that's not hard to do :) - <neal> ah, you cleaned up the port right but not the name - <braunr> ah ok - <neal> destroy the port and forget that a thread is still working on a - response - <neal> the data structure says use the port at index X - <neal> X is reallocated in the mean time - <teythoon> excuse my ignorance, but gnumach *is* reusing port names, isn't - it? - <braunr> that policy is why i'm not sure i want to enforce allocation - policy in the interface :/ - <neal> This is not about a security property of the system - <neal> this is about failing fast - <neal> you want to fail as close to the source of the problem as possible - <braunr> we could make the kernel use different allocation policies for - names, to catch bugs, yes - <neal> make the index X valid again and you've potentially masked the bug - <teythoon> braunr: if you were to merge your radix tree implementation into - gnumach and replace the splay tree with it, would that make using renamed - ports fast enough so we can just rename all receive ports doing away with - the extra lookup like mach-defpager does ? - <braunr> i don't think so - <braunr> the radix tree code is able to compress its size when keys are - close to 0 - <braunr> using addresses would add 1, 2, maybe 3 levels of internal nodes - <braunr> for every right - <braunr> we could use a true integer hash table for that though - <braunr> hm no, hurd packages crash ... :/ - <teythoon> but malloc allocates stuff in a contigious space, so the - pointers should be similar in the most significant bits - <braunr> if you use malloc, yes - <teythoon> sure - <teythoon> but that'd make the radix tree representation compact, no? - <braunr> it could - <braunr> the current code only compresses near 0 - <teythoon> oh - <braunr> better compression could be implemented though - - -## IRC, freenode, #hurd, 2013-11-21 - - <teythoon> have you seen liburcu ? - <braunr> a bit, yes - <teythoon> it might be worth investigating to use it in some servers - <braunr> it is - <teythoon> the proc server comes to mind - <braunr> personally, i think all hurd servers should use rcu - <braunr> libports should use rcu - <teythoon> yes - <braunr> lockless synchronization should be a major feature of x15/propel - <braunr> present even during message passing - - -## IRC, freenode, #hurd, 2013-12-09 - - <braunr> improving our page cache with arc would be great - <braunr> it's on the todo list for x15 :> - <braunr> not sure you referred to virtual memory management though - <braunr> (actually, it's CAR, not ARC that is planned for x15) - - -## IRC, freenode, #hurd, 2013-12-30 - - <braunr> zacts: http://darnassus.sceen.net/~rbraun/x15/qemu_x15.sh - - -## IRC, freenode, #hurd, 2014-01-03 - - <braunr> oh, btw, i've started working on x15 again :> - <teythoon> saw that :) - <braunr> first item on the list: per-cpu page tables - <braunr> the magic that will make ipc extremely scalable :) - <teythoon> i'm worried about your approach tbh - <braunr> too much overhead ? - <teythoon> not on any technical level - <teythoon> but haven - <braunr> ? - <teythoon> 't there been enough reimplementation efforts that got nowhere ? - <braunr> oh that - <teythoon> ^^ - <braunr> well, i have personal constraints and frustrations with the - existing code, and my goal isn't to actually produce anything serious - until it actually gets there - <braunr> which, yes, it might not - <braunr> really, i'm doing it for fun - <teythoon> well sure - <teythoon> that's a damn good reason ;) - <braunr> and if it ever reaches a state where it can actually be used to - run stuff, i would be very happy - <braunr> and considering how it's done, i'm pretty sure things could be - built a lot faster on such a system - <teythoon> but you need to reimplement all the userspace servers as well, - and the libc stuff - <braunr> yes - <teythoon> do you plan to reimplement this from scratch or do you have - plans to 'bootstrap' propel from hurd ? - <braunr> from scratch - <teythoon> well... i'm not sure that this is feasible or even a good - idea. that's what i meant in a nutshell i guess. - <braunr> i'm familiar with that criticism - <braunr> and you may be right - <braunr> this is also why i keep working on the hurd at the same time - <teythoon> we could also talk about making hurd more easily portable - <braunr> portable with regard to what ? - <teythoon> evolving hurd and mach to the point where it might be feasible - to port hurd to another ukernel - <braunr> not so easy - <teythoon> i know - <braunr> i'm not even sure i would want that - <braunr> well, since the hurd isn't optimized at all, why not - <teythoon> why would it neccessarily hinder optimization ? - <braunr> because in practice, it's rare for a microkernel to provide all - the features the hurd would require to run really well - <braunr> the most severe issue being that they either provide asynchronous - ipc, used for signals, or only synchronous ipc, making signal and other - event-driven code hard to emulate (usually requiring separate threads) - - -## IRC, freenode, #hurd, 2014-01-20 - -[[open_issues/translate_fd_or_port_to_file_name]]: - - <teythoon> i wonder if it would not be best to add a description to mach - tasks - <braunr> i think it would - <teythoon> to aid fixing these kind of issues - <braunr> in x15, i actually add descriptions (names) to all kernel objects - <teythoon> that's probably a good idea, yes - <braunr> well, not all, but many - - <braunr> i'd like to push x15 this year - <braunr> it currently is the only design of a truely scalable microkernel - that i know of - <azeem_> push how? - <braunr> spend time on it - <azeem_> k - <azeem_> do you think it will make sense to solicit outside contributions - at one point? - <braunr> yes - <braunr> the roadmap is vm system -> ipc system -> userspace (including RPC - handling) - <braunr> once we can actually do things in userspace, the priority will be - getting a shell with glibc - <braunr> people will be able to help "easily" at that point - <azeem_> just wondering, apart from scalability, did you write it for - performance, for hackability, or something else? - <braunr> it's basically the hurd architecture, including improvements from - the critique, with performance and scalability in mind - <azeem_> ok - <braunr> the main improvements i think of currently are resource - containers, lexical .. resolution, and lists of trusted users with which - to communicate - <braunr> it's strongly oriented for posix compatibility though - <teythoon> sounds nice, i like it already ;) - <azeem_> is it compatible with Mach to some degree? - <braunr> so things like running without an identity will be forbidden in - the default system personality - <braunr> no, not compatible with mach at all - <azeem_> this sounds like it is doing more than Mach did - <azeem_> braunr: ah, ok - <braunr> it's not "x15mach" any more :) - <azeem_> right, I missed out on that - - -### IRC, freenode, #hurd, 2014-01-21 - - <braunr> i also don't write anything that would prevent real-time - <teythoon> b/c that's a potential market for such an operating system ? - <braunr> yes - <teythoon> well, i can't say i don't like the sound of that ;) - <braunr> the ipc interface should be close to that of qnx - - -## IRC, freenode, #hurd, 2014-02-23 - - <cluck> braunr: have you looked at genode? - <cluck> braunr: i sometimes wonder how hard it'd be to port hurd atop it - because i find some similarities with what l4/fiasco/viengos provided - <braunr> cluck: i have, but genode seems a bit too far from posix for our - tastes - <cluck> (and yes, i realize we'd be getting farther from the hw) - <braunr> ah you really mean running the hurd on top of it - <braunr> i personally don't like the idea - <cluck> braunr: well, true, but their noux implementation proves it's not a - dealbreaker - <cluck> braunr: at least initially that'd be the best implementation - approach, no? as time went on integrating hurd servers more tightly at a - lower level makes sense but doing so from the get go would be foolhardy - <cluck> braunr: or am i missing something obvious? - <braunr> cluck: why would it be ? - <cluck> braunr: going by what happened with l4 it's too much code to port - and optimize at once - <braunr> cluck: i don't think it is - <braunr> cluck: problems with l4 didn't have much to do with "too much - code" - <cluck> braunr: i won't debate that, you have more experience than me with - hurd code. anyway that's how i'd go about it, first get it all running - then get it running fast. breakage is bad - <braunr> and you think moving from something like linux or genode to an - implementation closer to hardware won't break things ? - <cluck> braunr: yes, i read the paper, obvious unexpected shortcomings but - even had them not been there the paradigms are too different and creating - proper mappings from one model to the other would at least be time - consuming - <braunr> ye - <braunr> yes - <braunr> i'm convinved the simple approach of a small microkernel with the - proper interfacen along with the corresponding sysdeps layer in glibc - would be enough to get a small hurd like system quickly - <braunr> experience with other systems shows how to directly optimize a lot - of things from the start, without much effort - - <cluck> braunr: sorry. back to our talk, i mentioned genode because of the - nice features it has that'd be useful on hurd - <braunr> cluck: which ones do you refer to ? - <cluck> braunr: the security model is the biggest one - <braunr> how does it differ from the hurd, except for revocation ? - <cluck> braunr: then there's the ease of portability - <braunr> ? - <cluck> braunr: it's more strict - <braunr> how would that help us ? - <cluck> braunr: if hurd was running atop it we'd get extra platforms - supported almost for free whenever they did (since we'd be using the same - primitives) - <braunr> why not choose the underlying microkernel directly ? - <cluck> call me crazy but i believe code reuse is a good thing, i see - little point in duplicating existing code just because you can - <braunr> what part of genode should be reused then ? - <cluck> that's what got me thinking about genode in the first place, - ideologically they share a lot (if not most) of hurd's goals and code - wise they feel close enough to make a merge of sorts not seem crazy talk, - thus my asking if i'm missing something obvious - <braunr> i think the design is incompatible with our goals of posix - compatibility - <cluck> braunr: oh, ok. - <cluck> braunr: i was assuming that wasn't an issue, as i mentioned before - they have noux already and if hurd's servers got ported they'd provide - whatever else that was missing - <braunr> noux looks like a unix server for binary compatibility - <braunr> i'm not sure it is but that's what the description makes me think - <braunr> and if it really, then it's no different than running linux on top - of an hypervisor - <braunr> ok it's not for binary compatibility but it definitely is a - (partial) unix server - <braunr> i much prefer the way the hurd is posix compliant without any - additional layer for compatibility or virtualization - <cluck> braunr: noux is a runtime, as i understand it there's no binary - compatibility just source (ie library/api calls) - <braunr> yes i corrected that just now - <cluck> sorry, i'm having lag issues - <braunr> no worries - <cluck> braunr: anyway, how's x15 coming along? still far from being a - practical replacement? - <braunr> yes .. :( - <braunr> and it's not a replacement - <cluck> (for mach) - <braunr> no - <cluck> huh? - <braunr> it's not a replacement for the hurd - <braunr> err, for mach - <cluck> braunr: i thought you were writing it to be compatible with mach's - interfaces - <braunr> no - <braunr> it used to be that way - <braunr> but no - <cluck> braunr: what changed? - <braunr> mach ipc is too ccmplicated - <braunr> complicated* - <braunr> its supposed benefit (of allowing the creation of computer - clusters for single system images) are outdated and not very interesting - <braunr> it's error prone - <braunr> and it incurrs more overhead than it should - <cluck> no arguing there - <cluck> braunr: are you still targeting being able to run hurd atop x15 or - is it just your pet project now? - <braunr> i don't intend the hurd to run on top of it - <braunr> the reason it's a rewrite is to fix a whole bunch of major issues - in one go - - -## IRC, freenode, #hurd, 2014-03-03 - - <nalaginrut> braunr: x15 can be compiled successfully, is it possible to - run it on Hurd now? - <braunr> nalaginrut: it will never be - <braunr> x15 isn't a drop in mach replacement - <braunr> for now it's stalled until i have more free time :/ - <braunr> i need to rewrite virtual memory, and then implement ipc - <nalaginrut> oh, it's planed for standalone one? - <braunr> it's planned for a hurd clone - <nalaginrut> sounds bigger plan than I thought ;-) - <braunr> it is but not that much actually - <braunr> it's just i have really little free time currently .. - <braunr> and i chose to spend it on the hurd instead - <braunr> it's easier to fix bugs when you have little time, than think and - write big and difficult features like an smp scalable VM system - <nalaginrut> yes, I understand - <nalaginrut> it take huge time to think and design - <nalaginrut> and relative easier to fix the current one - <braunr> well, the whole thing is thought already - <braunr> what's hard is taking care of the details - <nalaginrut> well, you're so self-confident, to my experiences, even if all - the designs are in my mind, issues may make me change the original design - a lot ;-) - <nalaginrut> alright, I saw the key line, everything exists, just assemble - it diff --git a/microkernel/mach/documentation.mdwn b/microkernel/mach/documentation.mdwn index 61e3469b..821753d3 100644 --- a/microkernel/mach/documentation.mdwn +++ b/microkernel/mach/documentation.mdwn @@ -52,8 +52,7 @@ License|/fdl]]."]]"""]] # IRC, freenode, #hurd, 2013-09-15 <teythoon> braunr: btw, are there multiple kernel threads in gnumach? - <teythoon> and is it safe to do a synchronous rpc call to a userspace - server? + <teythoon> and is it safe to do a synchronous rpc call to a userspace server? <braunr> teythoon: there are yes, but few <braunr> teythoon: the main (perhaps only) kernel thread is the page daemon <braunr> and no, it's not safe to do synchronous calls to userspace diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn index 55bf9031..8b137891 100644 --- a/open_issues/glibc.mdwn +++ b/open_issues/glibc.mdwn @@ -1,3454 +1 @@ -[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2012, 2013, 2014, 2015, -2016 Free Software Foundation, Inc."]] -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled [[GNU Free Documentation -License|/fdl]]."]]"""]] - -[[!tag open_issue_glibc]] - -Here's what's to be done for maintaining glibc. - -[[!toc levels=2]] - - -# [[General information|/glibc]] - - * [[Versioning]] - - -# [[Sources|source_repositories/glibc]] - - -# [[Debian Cheat Sheet|debian]] - - -# Configuration - -<!-- - -git checkout reviewed -git log --reverse --topo-order --pretty=fuller --stat=$COLUMNS,$COLUMNS -b -p -C --cc ..sourceware/master --i -/^commit |^merge:|^---$|mach[^i]|hurd|linux|gs:|__assume - ---> - -Last reviewed up to the [[Git mirror's 9a869d822025be8e43b78234997b10bf0cf9d859 -(2014-02-07) sources|source_repositories/glibc]]. - - * <a id=t_hurdsig-fixes>`t/hurdsig-fixes`</a> - - hurdsig.c: In function '_hurd_internal_post_signal': - hurdsig.c:1188:26: warning: 'pending' may be used uninitialized in this function [-Wmaybe-uninitialized] - hurdsig.c:1168:12: note: 'pending' was declared here - - * <a id=t_host-independency>`t/host-independency`</a> - - [[!message-id "87bougerfb.fsf@kepler.schwinge.homeip.net"]], [[!message-id - "20120525202732.GA31088@intel.com"]], commit - 918b56067a444572f1c71b02f18255ae4540b043. [[!GCC_PR 53183]], GCC commit - c05436a7e361b8040ee899266e15bea817212c37. - - * <a id=t_pie-sbrk>`t/pie-sbrk`</a> - - [[gcc/PIE]]. - - * <a id=t_sysvshm>`t/sysvshm`</a> - - ../sysdeps/mach/hurd/shmat.c: In function '__shmat': - ../sysdeps/mach/hurd/shmat.c:57:7: warning: implicit declaration of function '__close' [-Wimplicit-function-declaration] - ../sysdeps/mach/hurd/shmget.c: In function 'get_exclusive': - ../sysdeps/mach/hurd/shmget.c:85:8: warning: variable 'is_private' set but not used [-Wunused-but-set-variable] - ../sysdeps/mach/hurd/shmget.c:102:8: warning: 'dir' may be used uninitialized in this function [-Wmaybe-uninitialized] - ../sysdeps/mach/hurd/shmget.c:102:8: warning: 'file' may be used uninitialized in this function [-Wmaybe-uninitialized] - - * <a id=t_tls>[[`t/tls`|t/tls]]</a> - - * <a id=t_tls-threadvar>[[`t/tls-threadvar`|t/tls-threadvar]]</a> - - * <a id=t_verify.h>`t/verify.h`</a> - - People didn't like this too much. - - Other examples: - - * 11988f8f9656042c3dfd9002ac85dff33173b9bd -- `static_assert` - - * <a id=toolchain_cross-gnu>[[toolchain/cross-gnu]], without `--disable-multi-arch`</a> - - i686-pc-gnu-gcc ../sysdeps/i386/i686/multiarch/strcmp.S -c [...] - ../sysdeps/i386/i686/multiarch/../strcmp.S: Assembler messages: - ../sysdeps/i386/i686/multiarch/../strcmp.S:31: Error: symbol `strcmp' is already defined - make[2]: *** [/media/boole-data/thomas/tmp/gnu-0/src/glibc.obj/string/strcmp.o] Error 1 - make[2]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/glibc/string' - - Might simply be a missing patch(es) from master. - - * <a id=disable-multi-arch>`--disable-multi-arch`</a> - - IRC, freenode, #hurd, 2012-11-22 - - <pinotree> tschwinge: is your glibc build w/ or w/o multiarch? - <tschwinge> pinotree: See open_issues/glibc: --disable-multi-arch - <pinotree> ah, because you do cross-compilation? - <tschwinge> No, that's natively. - <tschwinge> There is also a not of what happened in cross-gnu when I - enabled multi-arch. - <tschwinge> No idea whether that's still relevant, though. - <pinotree> EPARSE - <tschwinge> s%not%note - <tschwinge> Better? - <pinotree> yes :) - <tschwinge> As for native builds: I guess I just didn't (want to) play - with it yet. - <pinotree> it is enabled in debian since quite some time, maybe other - i386/i686 patches (done for linux) help us too - <tschwinge> I though we first needed some CPU identification - infrastructe before it can really work? - <tschwinge> I thought [...]. - <pinotree> as in use the i686 variant as runtime automatically? i guess - so - <tschwinge> I thought I had some notes about that, but can't currently - find them. - <tschwinge> Ah, I probably have been thinking about open_issues/ifunc - and open_issues/libc_variant_selection. - - * <a id=buildX>--build=X</a> - - `long double` test: due to `cross_compiling = maybe` wants to execute a - file, which fails. Thus `--build=X` has to be set. - - * <a id=check>Check what all these are:</a> - - running configure fragment for sysdeps/mach/hurd - checking Hurd header version... ok - running configure fragment for sysdeps/mach - checking for i586-pc-gnu-mig... i586-pc-gnu-mig - checking for mach/mach_types.h... yes - checking for mach/mach_types.defs... yes - checking for task_t in mach/mach_types.h... task_t - checking for thread_t in mach/mach_types.h... thread_t - checking for creation_time in task_basic_info... yes - checking for mach/mach.defs... yes - checking for mach/mach4.defs... yes - checking for mach/clock.defs... no - checking for mach/clock_priv.defs... no - checking for mach/host_priv.defs... no - checking for mach/host_security.defs... no - checking for mach/ledger.defs... no - checking for mach/lock_set.defs... no - checking for mach/processor.defs... no - checking for mach/processor_set.defs... no - checking for mach/task.defs... no - checking for mach/thread_act.defs... no - checking for mach/vm_map.defs... no - checking for mach/memory_object.defs... yes - checking for mach/memory_object_default.defs... yes - checking for mach/default_pager.defs... yes - checking for mach/i386/mach_i386.defs... yes - checking for egrep... grep -E - checking for host_page_size in mach_host.defs... no - checking for mach/machine/ndr_def.h... no - checking for machine/ndr_def.h... no - checking for i386_io_perm_modify in mach_i386.defs... yes - checking for i386_set_gdt in mach_i386.defs... yes - checking whether i586-pc-gnu-mig supports the retcode keyword... yes - - * <a id=stackguard>`sysdeps/i386/stackguard-macros.h`</a> - - See [[t/tls|t/tls]]. - - * <a id=77c84aeb81808c3109665949448dba59965c391e>Verify 77c84aeb81808c3109665949448dba59965c391e against - `~/shared/glibc/make_TAGS.patch`.</a> - - * <a id=HP_SMALL_TIMING_AVAIL>`HP_SMALL_TIMING_AVAIL` not defined anywhere.</a> - - * <a id=CPUCLOCK_WHICH>Unify `CPUCLOCK_WHICH` stuff in `clock_*` files.</a> - - * <a id=tests-clean>Not all tests are re-run in a `make -k tests; make tests-clean; make -k - tests` cycle. For example, after `make tests-clean`:</a> - - $ find ./ -name \*.out - ./localedata/tst-locale.out - ./localedata/sort-test.out - ./localedata/de_DE.out - ./localedata/en_US.out - ./localedata/da_DK.out - ./localedata/hr_HR.out - ./localedata/sv_SE.out - ./localedata/tr_TR.out - ./localedata/fr_FR.out - ./localedata/si_LK.out - ./localedata/tst-mbswcs.out - ./iconvdata/iconv-test.out - ./iconvdata/tst-tables.out - ./stdlib/isomac.out - ./posix/wordexp-tst.out - ./posix/annexc.out - ./posix/tst-getconf.out - ./elf/check-textrel.out - ./elf/check-execstack.out - ./elf/check-localplt.out - ./c++-types-check.out - ./check-local-headers.out - ./begin-end-check.out - - * <a id=t_cpuclock>`CPUCLOCK_WHICH`, `t/cpuclock`</a> - - /media/boole-data/thomas/tmp/gnu-0/src/glibc.obj/rt/librt_pic.a(clock_settime.os): In function `clock_settime': - /media/boole-data/thomas/tmp/gnu-0/src/glibc/rt/../sysdeps/unix/clock_settime.c:113: undefined reference to `CPUCLOCK_WHICH' - /media/boole-data/thomas/tmp/gnu-0/src/glibc/rt/../sysdeps/unix/clock_settime.c:114: undefined reference to `CPUCLOCK_WHICH' - collect2: error: ld returned 1 exit status - make[2]: *** [/media/boole-data/thomas/tmp/gnu-0/src/glibc.obj/rt/librt.so] Error 1 - make[2]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/glibc/rt' - make[1]: *** [rt/others] Error 2 - make[1]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/glibc' - make: *** [all] Error 2 - - * <a id=missing>Missing Interfaces</a> - - We have posted a [[Google Summer of Code project proposal|community/gsoc]]: - - [[!inline pages="community/gsoc/project_ideas/testsuites" show=0 feeds=no - actions=yes]] - - Many are missing for GNU Hurd, some of which have been announced in - [`NEWS`](https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS), others - typically haven't (like new flags to existing functions). Typically, - porters will notice missing functionaly. But in case you're looking for - something to work on, here's a bit of a commented list, otherwise go - looking in `/usr/include/i386-gnu/gnu/stubs.h` on a Debian GNU/Hurd system, - or the respective file from a fresh glibc build. - - `AT_EMPTY_PATH`, `CLOCK_BOOTTIME`, `CLOCK_BOOTTIME_ALARM`, - `CLOCK_REALTIME_ALARM`, `O_PATH`, `O_TMPFILE` - (ffdd31816a67f48697ea4d6b852e58d2886d42ca), - `PTRACE_*` (for example, cbff0d9689c4d68578b6a4f0a17807232506ea27, - b1b2aaf8eb9eed301ea8f65b96844568ca017f8b, - 521c6785e1fc94d1f501743e9a40af9e02797df3), - `RLIMIT_RTTIME`, `SEEK_DATA` (`unistd.h`), `SEEK_HOLE` (`unistd.h`) - `clock_adjtime`, `fallocate`, `fallocate64`, `name_to_handle_at`, - `open_by_handle_at`, - `posix_openpt`, `process_vm_readv`, `process_vm_writev`, - `setns`, `sync_file_range`, [[`mremap`|mremap]] and [[several - `MAP_*`|glibc/mmap]] - - Check also the content of `gnu/stubs.h`, which lists all the functions - marked as stub which only return `ENOSYS`. - - * <a id=chflags>`chflags`</a> - - Patch sent, [[!message-id "20120427012130.GZ19431@type.famille.thibault.fr"]]. - - IRC, OFTC, #debian-hurd, 2012-04-27: - - <Steap> Does anyone have any idea why int main(void) { return - chflags(); } will compile with gcc but not with g++ ? It says - that "chflags" was not declared in this scope. - <Steap> I get the same error on FreeBSD, but including sys/stat.h - makes it work - <Steap> Can't find a solution on Hurd though :/ - <youpi> the Hurd doesn't have chflags - <youpi> apparently linux neither - <youpi> what does it do? - <Steap> change flags :) - <Steap> Are you sure the Hurd does not have chflags ? Because gcc - does not complain - <youpi> there is no chflags function in /usr/include - <youpi> but what flags does it change? - <Steap> According to the FreeBSD manpage, it can set flags such as - UF_NODUMP, UF_IMMUTABLE etc. - <youpi> Hum, there is actually a chflags() definition - <youpi> but no declaration - <youpi> so actually chflags is supported, but the declaration was - forgotten - <youpi> probably because since linux doens't have it, it has never - been a problem up to now - <youpi> so I'd say ignore the error for now, we'll add the - declaration - - * <a id=t_tls-threadvar>[[t/tls-threadvar]]</a> - - * <a id=futimesat>`futimesat`</a> - - If we have all of 'em (check Linux kernel), `#define __ASSUME_ATFCTS`. - - * `futimens` - - IRC, freenode, #hurd, 2014-02-09: - - <youpi> it seems apt 0.9.15.1 has troubles downloading packages - etc., as opposed to apt 0.9.15 - <youpi> ah, that version uses futimens unconditionally - <youpi> and we haven't implemented that yet - <azeem> did somebody file a bug for that apt-get issue? - <youpi> I haven't - <youpi> I'll commit the fix in eglibc - <youpi> but perhaps a bug report would be good for the kfreebsd - case - - * <a id=bits_stat.h>`bits/stat.h [__USE_ATFILE]`: `UTIME_NOW`, `UTIME_OMIT`</a> - - * <a id=__USE_ATFILE>`io/fcntl.h [__USE_ATFILE]`</a> - - Do we support `AT_FDCWD` et al.? - (80b4e5f3ef231702b24d44c33e8dceb70abb3a06.) - - * <a id=t_opendirat>`t/opendirat`: `opendirat` (`scandirat`, `scandirat64`)</a> - - Need changes equivalent to c55fbd1ea768f9fdef34a01377702c0d72cbc213 + - 14d96785125abee5e9a49a1c3037f35a581750bd. - - * <a id=madvise>`madvise`, `MADV_DONTNEED`, `MADV_DONTDUMP`, `MADV_DODUMP`</a> - - [[glibc_madvise_vs_static_linking]]. - - IRC, OFTC, #debian-hurd, 2013-09-09: - - <gg0> does hurd MADV_DONTNEED or MADV_FREE or none? - http://sources.debian.net/src/jemalloc/3.4.0-1/include/jemalloc/jemalloc_defs.h.in#L239 - <gg0> seems it builds by defining JEMALLOC_PURGE_MADVISE_DONTNEED - but i don't know what i'm talking about, so it could build with - JEMALLOC_PURGE_MADVISE_FREE as well - - IRC, OFTC, #debian-hurd, 2013-09-10: - - <youpi> gg0: it implements none, even if it defines DONTNEED (but - not FREE) - - See also: - - gnash (0.8.11~git20130903-1) unstable; urgency=low - - * Git snapshot. - + Embedded jemalloc copy has been replaced by system one. - [...] - - Disable jemalloc on hurd and kfreebsd-*. No longer disabled upstream. - - * <a id=msync>`msync`</a> - - Then define `_POSIX_MAPPED_FILES`, `_POSIX_SYNCHRONIZED_IO`. - - * <a id=epoll>`epoll`, `sys/epoll.h`</a> - - Used by [[wayland]], for example. - - IRC, freenode, #hurd, 2013-08-08: - - <nalaginrut> is there any possible to have kquque/epoll alike - things in hurd? or there is one? - <braunr> nalaginrut: use select/poll - <nalaginrut> is it possible to implement epoll? - <braunr> it is - <braunr> we don't care enough about it to do it - <braunr> (for now) - <nalaginrut> well, since I wrote a server with Guile, and it could - take advantage of epoll, never mind, if there's no, it'll use - select automatically - <nalaginrut> but if someday someone care about it, I'll be - interested on it - <braunr> epoll is a scalability improvement over poll - <braunr> the hurd being full of scalability issues, this one is - clearly not a priority - <nalaginrut> ok - - IRC, freenode, #hurd, 2013-09-26: - - <nalaginrut> if I want to have epoll/kqueue like things, where - should it dwell? kernel or some libs? - <braunr> libs - <pinotree> userland - <braunr> that would be a good project to work on, something i - intended to do (so i can help) but it requires a lot of work - <braunr> you basically need to add a way to explicitely install and - remove polling requests (instead of the currently way that - implicitely remove polling requests when select/poll returns) - <braunr> while keeping the existing way working for some time - <braunr> glibc implements select - <braunr> the hurd io interface shows the select interface - <braunr> servers such as pfinet/pflocal implement it - <braunr> glibc implements the client-side of the call - <nalaginrut> where's poll? since epoll just added edge-trigger in - poll - <braunr> both select and poll are implemented on top of the hurd io - select call (which isn't exactly select) - <braunr> - http://git.sceen.net/hurd/hurd.git/plain/hurd/io.defs - <braunr> this is the io interface - <braunr> - http://git.sceen.net/hurd/glibc.git/tree/hurd/hurdselect.c?h=tschwinge/Roger_Whittaker - <braunr> this is the client side implementation - - IRC, freenode, #hurd, 2014-02-14: - - <desrt> also: do you know if hurd has a modern-day poll() - replacement? ala epoll, kqueue, iocp, port_create(), etc? - <pochu_> last thing I remember was that there was no epoll - equivalent, but that was a few years ago :) - <pochu_> braunr: ^ - * desrt is about to replace gmaincontext in glib with something - more modern - * desrt really very much wants not to have to write a poll() - backend.... - <desrt> it seems that absolutely every system that i care about, - except for hurd, has a new approach here :/ - <desrt> even illumos has solaris-style ports - <azeem> desrt: I suggest you bring up the question on bug-hurd - <azeem> the poll() system call there to satisfy POSIX, but there - might be a better Hurd-specific thing you could use - <azeem> is there* - <desrt> that would be ideal - <desrt> i have to assume that a system that passes to many messages - has some other facilities :) - <desrt> *so many - <desrt> the question is if they work with fds.... - <desrt> bug-hurd doesn't seem like a good place to ask open-ended - questions.... - <azeem> it's the main development lists, it's just old GNU naming - <azeem> list* - <desrt> k. thanks. - <azeem> bug-hurd@gnu.org is the address - * desrt goes to bug... hurd - <desrt> written. thanks. - <braunr> desrt: the hurd has only select/poll - <braunr> it suffers from so many scalability issues there isn't - much point providing one currently - <braunr> we focus more on bug fixing and posix compliance right now - <desrt> fair answer - <braunr> you should want a poll-based backend - <braunr> it's the most portable one, and doesn't suck as much as - select - <braunr> very easy to write - <braunr> although, internally, our select/poll works just like a - bare epoll - <braunr> i.e. select requests are installed, the client waits for - one or more messages, then uninstalls the requests - - IRC, freenode, #hurd, 2014-02-23: - - <desrt> brings me to another question i asked here recently that - nobody had a great answer for: any plan to do kqueue? - <braunr> not for now - <braunr> i remember answering you about that - <desrt> ah. on IRC or the list? - <braunr> that internally, our select/poll implementation works just - like epoll - <braunr> on irc - <braunr> well "just like" is a bit far from the truth - <desrt> well... poll() doesn't really work like epoll :p - <braunr> internally, it does - <braunr> even on linux - <desrt> since both of us have to do the linear scan on the list - <desrt> which is really the entire difference - <braunr> that's the user interface part - <braunr> i'm talking about the implementation - <desrt> ya -- but it's the interface that makes it unscalable - <braunr> i know - <braunr> what i mean is - <braunr> since the implementation already works like a more modern - poll - <braunr> we could in theory add such an interface - <braunr> but epoll adds some complicated detail - <desrt> you'll have to forgive me a bit -- i wasn't around from a - time that i could imagine what a non-modern poll would look like - inside of a kernel :) - <braunr> what i mean with a modern poll is a scalable poll-like - interface - <braunr> epoll being the reference - * desrt is not super-crazy about the epoll interface.... - <braunr> me neither - <desrt> kevent() is amazing -- one syscall for everything you need - <braunr> i don't know kqueue enough to talk about it - <desrt> no need to do 100 epollctls when you have a whole batch of - updates to do - <desrt> there's two main differences - <desrt> first is that instead of having a bunch of separate fds for - things like inotify, timerfd, eventfd, signalfd, etc -- they're - all built in as different 'filter' types - <desrt> second is that instead of a separate epoll_ctl() call to - update the list of monitored things, the kevent() call - (epoll_wait() equivalent) takes two lists: one is the list of - updates to make and the other is the list of events to - return.... so you only do one syscall - <braunr> well, again, that's the interface - <braunr> internally, there still are updates and waits - <braunr> and on a multiserver system like the hurd, this would mean - one system call per update per fd - <braunr> and then one per wait - <desrt> on the implementation side, i think kqueue also has a nice - feature: the kernel somehow has some magic that lets it post - events to a userspace queue.... so if you're not making updates - and you do a kevent() that would not block, you don't even enter - the kernel - <braunr> ok - <desrt> hm. that's an interesting point - <desrt> "unix" as such is just another server for you guys, right? - <braunr> no - <braunr> that's a major difference between the hurd and other - microkernel based systems - <braunr> even multiserver ones like minix - <braunr> we don't have a unix server - <braunr> we don't have a vfs server or even an "fd server" - <desrt> so mach knows about things like fds? - <braunr> no - <braunr> only glibc - <desrt> oh. weird! - <braunr> yes - <braunr> that's the hurd's magic :) - <braunr> being so posix compliant despite how exotic it is - <desrt> this starts to feel like msvcrt :p - <braunr> maybe, i wouldn't know - <braunr> windows is a hybrid after all - <braunr> with multiple servers for its file system - <braunr> so why not - <braunr> anyway - <desrt> so windows doesn't have fds in the kernel either... the C - library runtime emulates them - <braunr> mach has something close to file descriptors - <desrt> which is fun when you get into dll hell -- sometimes you - have multiple copies of the C library runtime in the same program - -- and you have to take care not to use fds from one of them with - th o ther one - <braunr> yes .. - <braunr> that, i knew :) - <braunr> but back to the hurd - <braunr> since fds are a glibc thing here, and because "files" can - be implemented by multiple servers - <braunr> (sockets actually most of the time with select/poll) - <braunr> we have to make per fd requests - <braunr> the implementation uses the "port set" kernel abstraction - <desrt> right -- we could have different "fd" coming from different - places - <braunr> do you know what a mach port is ? - <desrt> not even a little bit - <braunr> hm - <desrt> i think it's what a plane does when it goes really fast, - right? - <braunr> let's say it's a kernel message queue - <braunr> no it's not a sonic boom - <desrt> :) - <braunr> ;p - <braunr> so - <braunr> ports are queues - <desrt> (aside: i did briefly run into mach ports recently on macos - where they modified their kqueue to support them...) - <braunr> queues of RPC requests usually - <desrt> (but i didn't use them or look into them at all) - <braunr> they can be referenced through mach port names, which are - integers much like file descriptors - <braunr> they're also used for replies but, except for weird calls - like select/poll, you don't need to know that :) - <braunr> a port set is one object containing multiple ports - <desrt> sounds like dbus :) - <braunr> the point of a port set is to provide the ability to - perform a single operation (wait for a message) on multiple ports - <desrt> sounds like an epoll fd.... - <desrt> is the port set itself a port? - <braunr> so, when a client calls select, it translates the list of - fds into port names, creates reply ports for each of them, puts - them into a port set, send one select request for each, and does - one blocking wait on the port set - <braunr> no, but you can wait for a message on a port set the same - way you do on a port - <braunr> and that's all it does - <desrt> does that mean that you can you put a port set inside of - another port set? - <braunr> hm maybe - <desrt> i guess in some way that doesn't actually make sense - <braunr> i guess - <desrt> because i assume that the message you sent to each port in - your example is "tell me when you have some stuff" - <braunr> yes - <desrt> and you'd have to send an equivalent message to the port - set.... and that just doesn't make sense - <desrt> since it's not really a thing, per se - <braunr> it would - <braunr> insteaf of port -> port set, it would just be port -> port - set -> port set - <braunr> but we don't have any interface where an fd stands for a - port set - <braunr> what i'm trying to tell here is that - <braunr> considering how it's done, you can easily see that there - has to be non trivial communication - <braunr> each with the cost of a system call - <braunr> and not just any system call, a messaging one - <braunr> mach is clearly not as good as l4 when it comes to that - <desrt> hrmph - <braunr> and the fact that most pollable fds are either unix or - inet/inet6 sockets mean that there will be contention in the - socket servers anyway - <desrt> i've seen some of the crazy things you guys can do as a - result of the way mach works and way that hurd uses it, in - particular - <desrt> normal users setting up little tcp/ip universes for - themselves, and so on - <braunr> yes :) - <desrt> but i guess this all has a cost - <braunr> the cost here comes more from the implementation than the - added abstractions - <braunr> mach provides async ipc, which can partially succeed - <desrt> if i spin up a subhurd, it's using the same mach, right? - <braunr> yes - <desrt> that's neat - <braunr> we tend to call them neighbour hurds because of that - <braunr> i'm not sure it is - <desrt> it puts it half way between linux containers and outright - VMs - <desrt> because you have a new kernel.... ish... - <braunr> well, it is for the same reasons hypervisors are neat - <desrt> but the kernel exists within this construct.... - <braunr> a new kernel ? - <desrt> a new hurd - <braunr> yes - <desrt> but not a new mach - <braunr> exactly - <desrt> ya -- that's very cool - <braunr> it's halfway between hypervisors and containers/jails - <braunr> what matters is that we didn't need to write much code to - make it work - <braunr> and that the design naturally guarantees strong isolation - <desrt> right. that's what i'm getting at - <braunr> unlike containers - <desrt> it shows that the interaction between mach and these set of - crazy things collectively referred to as the hurd is really - proper - <braunr> usually - <braunr> sometimes i think it's not - <braunr> but that's another story :) - <desrt> don't worry -- you can fix it when you port to L4 ;) - <braunr> eh, no :) - <desrt> btw: is this fundamentally the same mach as darwin? - <braunr> yes - <desrt> so i guess there are multiple separate implementations of a - standard set of interfaces? - <braunr> ? - * desrt has to assume that apple wouldn't be using GNU mach, for - example... - <braunr> no it's the same code base - <braunr> they couldn't - <braunr> but only because the forks have diverged a bit - <desrt> ah - <braunr> and they probably changed a lot of things in their virtual - memory implementation - <desrt> so i guess original mach was under some BSDish type thing - and GNU mach forked from that and started adding GPL code? - <braunr> something like that - <desrt> makes sense - <braunr> we have very few "non-standard" mach interfaces - <braunr> but we now rely on them so we couldn't use another mach - either - <braunr> back to the select/poll stuff - * desrt gets a lesson tonight :) - <braunr> it costs, it's not scalable - <braunr> but - <braunr> we have scalability problems in our servers - <braunr> they're old code, they use global locks - <desrt> right. this is the story i heard last time. - <braunr> probably from me - <braunr> poll works good enough for us right now - <braunr> we're more interested in bug fixes than scalability - currently - <desrt> the reason this negative impacts me is because now i need - to write a bunch more code ;p - <braunr> i hope this changes but we still get weird errors that - many applications don't expect and they react badly to those - <braunr> well, poll really is the posix fallback - <desrt> every other OS that we want to support has some sort of new - scalable epoll-type interface or is Windows (which needs separate - code anyway) - <desrt> a very large number of them have kqueue... linux has - epoll... solaris/illumos is the odd one out with this weird thing - that's sort of like epoll - <braunr> i would think you want a posix fallback for such a - commonly used interface - <braunr> hm - <desrt> braunr: hurd is pretty much the only one that doesn't - already have something better.... - <braunr> linux can be built without epoll - <desrt> and the nice thing about all of these things is that every - single one of them gives me an fd that can be polled when any - event is ready - <braunr> i don't see why anyone would do that, but it's a compile - time option ;p - <braunr> yes ... - <braunr> we don't have xxxfd() :) - <desrt> and we want to expose that fd on our API... so people can - chain gmaincontext into other mainloops - <braunr> that's expected - <desrt> so for hurd this means that i will need to spin up a - separate thread doing poll() and communicating back to the main - thread when anything becomes ready - <desrt> i was looking forward to not having to do that :) - <braunr> it matches the unix "everything is a file" idea, and - windows concept of "events" - <braunr> i understand but again, it's a posix fallback - <braunr> you probably want it anyway - <desrt> probably - <braunr> it could help new systems trying to be posix like - <desrt> i honestly thought i'd get away with it, though - <desrt> this is true... - <desrt> CLOCK_MONOTONIC is an easy enough requirement to implement - or fake.... "modern event polling framework" is another story... - - [[clock_gettime]]. - - <braunr> yes, but again, we do have the underlying machinery to add - it - <desrt> i appreciate if your priorities are elsewhere ;) - <braunr> it's just not worth the effort right now - <braunr> although we do have performance and latency improvements - in our patch queues currently - <braunr> if our network stack gets replaced, it would become - interesting - <braunr> we need to improve posix compliance first - <braunr> make more applications not choke on unecpected errors - <braunr> and then we can think of improving scalability - <desrt> +1 vote from me for implementing monotonic time :) - <desrt> (and also pthread_condattr_setclock()) - <braunr> and we probably won't implement the epoll interface ;p - <braunr> yes - <desrt> it's worth noting that there is also a semi-widely - available non-standard extension called - pthread_cond_timedwait_relative_np that you could implement - instead - <desrt> it takes a (relative) timeout instead of an absolute one -- - we can use that if it's available - <braunr> desrt: why would you want relative timeouts ? - <desrt> braunr: if you're willing to take the calculations into - your own hands and you don't have another way to base it on - monotonic time it starts to look like a good alternative - <desrt> and indeed, this is the case on android and macos at least - <braunr> hm - <desrt> not great as a user-facing API of course.... due to the - spurious wakeup possibility and need to retry - <braunr> so it's non standard alternative to a monotonic clock ? - <desrt> no -- these systems have monotonic clocks - <desrt> what they lack is pthread_condattr_setclock() - <braunr> oh right - <desrt> which is documented in POSIX but labelled as 'optional' - <braunr> so relative is implicitely monotonic - <desrt> yes - <desrt> i imagine it would be the same 'relative' you get as the - timeout you pass to poll() - <desrt> since basing anything like this on wallclock time is - absolutely insane - <desrt> (which is exactly why we refuse to use wallclock time on - our timed waits) - <braunr> sure - <braunr> i'm surprised clock_monotonic is even optional in posix - 2008 - <braunr> but i guess that's to give some transition margin for - small embedded systems - <desrt> when you think about it, CLOCK_REALTIME really ought to - have been the optional feature - <desrt> monotonic time is so utterly basic - <braunr> yes - <braunr> and that's how it's normally implemented - <braunr> kernels provide a monotonic clock, and realtime is merely - shifted from it - - * <a id=sys_eventfd.h>`sys/eventfd.h`</a> - - * <a id=sys_inotify.h>`sys/inotify.h`</a> - - * <a id=sys_signalfd.h>`sys/signalfd.h`</a> - - * <a id=sys_timerfd.h>`sys/timerfd.h`</a> - - * <a id=timespec_get>`timespec_get` (74033a2507841cf077e31221de2481ff30b43d51, - 87f51853ce3671f4ba9a9953de1fff952c5f7e52)</a> - - * <a id=waitflags.h>`waitflags.h` (`WEXITED`, `WNOWAIT`, `WSTOPPED`, `WCONTINUED`)</a> - - IRC, freenode, #hurd, 2012-04-20: - - <pinotree> in glibc, we use the generic waitflags.h which, unlike - linux's version, does not define WEXITED, WNOWAIT, WSTOPPED, - WCONTINUED - <pinotree> should the generic bits/waitflags.h define them anyway, - since they are posix? - <youpi> well, we'd have to implement them anyway - <youpi> but otherwise, I'd say yes - <pinotree> sure, but since glibc headers should expose at least - everything declared by posix, i thought they should be defined - anyway - <youpi> that might bring bugs - <youpi> some applications might be #ifdefing them - <youpi> and break when they are defined but not working - <pinotree> i guess they would define them to 0, andd having them to - non-zero values shouldn't break them (since those values don't do - anything, so they would act as if they were 0.. or not?) - <youpi> no, I mean they would do something else, not define them to - 0 - <pinotree> like posix/tst-waitid.c, you mean? - <youpi> yes - - See `posix/tst-waitid.out` failure below. - - * <a id=getconf>`getconf` things (see below the results of `tst-getconf.out`)</a> - - * <a id=getsockopt>`getsockopt`, `setsockopt`</a> - - IRC, freenode, #hurd, 2013-02-14 - - <gnu_srs> Hi, {get,set}sockopt is not supported on Hurd. This shows - e.g. in the gnulib's test-{poll,select} code. - <gnu_srs> Reading - http://hea-www.harvard.edu/~fine/Tech/addrinuse.html there might - be reasons _not_ to implement them, comments? - <pinotree> uh? they are supported on hurd - <gnu_srs> not SO_REUSEPORT for setsockopt() - <pinotree> that isn't the same as claiming "get/setsockopt is not - supported on hurd" - <pinotree> most probably that option is not implemented by the - socket family you are using - <gnu_srs> OK, some options like SO_REUSEPORT then, more info in - the link. - <pinotree> note also SO_REUSEPORT is not posix - <pinotree> and i don't see SO_REUSEPORT mentioned in the page you - linked - <gnu_srs> No, but SO_REUSEADDR - - IRC, freenode, #hurd, 2013-02-23 - - <gnu_srs> as an example, the poll test code from gnulib fails due - to that problem (and I've told you before) - <pinotree> gnu_srs: what's the actual failure? - <pinotree> can you provide a minimal test case showing the issue? - <gnu_srs> pinotree: A smaller test program: - http://paste.debian.net/237495/ - <pinotree> gnu_srs: setting SO_REUSEADDR before binding the socket - works... - <pinotree> and it seems it was a bug in the gnulib tests, see - http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=6ed6dffbe79bcf95e2ed5593eee94ab32fcde3f4 - <gnu_srs> pinotree: You are right, still the code I pasted pass on - Linux, not on Hurd. - <pinotree> so? - <pinotree> the code is wrong - <pinotree> you cannot change what bind does after you have called - it - * pinotree → out - <gnu_srs> so linux is buggy? - <braunr> no, linux is more permissive - <braunr> (at least, on this matter) - - * <a id=getcontext>`getcontext`/`makecontext`/`setcontext`/`swapcontext`</a> - - Support for these functions within the Hurd threadvar environment has - been added, but for multi-threaded applications ([[libpthread]]), it is - a bit clunky: as a practical requirement, a thread's stack size always - has to be equal to `PTHREAD_STACK_DEFAULT`, 2 MiB, and also has to be - naturally aligned. The idea is still to [[get rid of Hurd threadvars - and replace them with TLS|t/tls-threadvar]]. - - Aside from [[gccgo]], the following packages might make use of these - functions, searching on <http://codesearch.debian.net/> for - `\b(get|set|make|swap)context\s*\(` on 2013-05-18: boost1.49, - chromium-browser, gtk-vnc, guile-1.8, iceape, icedove, iceweasel, - libgc, libsigsegv, luatex, mono, nspr, pth, ruby1.8, texlive-bin, uim, - and more. - - IRC, OFTC, #debian-hurd, 2013-09-08: - - <pinotree> oh, and even ruby2.0 suffers because of fixed-stack - threads - <youpi> yes, we definitely need to finish fixing it - <youpi> my current work is in our glibc repo, youpi/tls-threadvar - <pinotree> | *** makecontext: a stack at 0xbc000 with size 0x40000 - is not usable with threadvars - <pinotree> all 8 failing tests with that - <youpi> maybe we can hand-disable the use of contexts in ruby for - now? - <pinotree> gg0: ↑ :) - <gg0> after the pseudo-patch i RFCed, i don't deserve to say - anything else about that :) - <pinotree> i mean, feel free to investigate and "fix" ruby2.0 as - above :) - <gg0> eh maybe i'd just be able to hand-disable failing - thread-related _tests_ :) - <gg0> i'm still hoping some real developer picks and actually fixes - it, seems it's not enough interesting though - <azeem> 21:37 < youpi> yes, we definitely need to finish fixing it - <gg0> afaiu youpi is working on threadvars-tls migration, which - would mean fixing them all. i just meant fixing ruby, which would - mean having puppet btw - <youpi> gg0: "actually fixing" means fixing threadvars-tls - migration - <youpi> "just fixing" ruby can be done by simply disabling context - use in ruby - - IRC, OFTC, #debian-hurd, 2013-09-10: - - <gg0> this one fixes make test by disabling context and giving more - time to timing related tests http://paste.debian.net/plain/37977/ - <gg0> make test-all is another story - <youpi> gg0: AIUI, the sleep part should get fixed by the next - glibc upload, which will include the getclk patch - <youpi> but the disabling context part could be good to submit to - the debian ruby package, mentioning that this is a workaround for - now - <gg0> unfortunately still not enough, test-all still fails - <youpi> does it make the package not build? - <gg0> test-all is the second part of what we call tests - <gg0> they build and package (they produce all ruby packages), - after that they run debian/run-test-suites.bash which is make - test + make test-all - <gg0> well after or during the build doesn't matter, it's their - testsuite - <gg0> ok just failed: - <gg0> TestBug4409#test_bug4409 = Illegal instruction - <gg0> make: *** [yes-test-all] Error 132 - <gg0> what to do with Illegal instruction? - <gg0> just found 2 words that make everybody shut up :p - <pinotree> same as above: debug it - <teythoon> gg0: have you confirmed that this is reproducible? I've - once had a process die with SIGILL and it was not and I figured - it might have been a (qemu?) glitch - <gg0> seems i'm running tests which are disabled on _all_ archs, - better so - <gg0> well, this should be reproducible. i just got it on a qemu, i - could try to reproduce it on real hardware but as just said, i - was testing tests disabled by maintainer so completely useless - <teythoon> gg0: yeah, I'm running all my hurd instances on qemu/kvm - as well, I meant did you get this twice in a row? - <gg0> to be honest i got another illegal instruction months ago but - don't recall doing what - <gg0> nope not twice, i've commented it out. then run the remaining - and then found out i should not have done what i was doing - <gg0> but i could try to reproduce it - <gg0> ok now i recall i got it another one few hours ago on real - hardware, from logs: - <gg0> TestIO#test_copy_stream_socket = Illegal instruction - <gg0> teythoon: on real hardware though - <gg0> and this is the one i should debug once it finishes, still - running - - IRC, freenode, #hurd, 2013-09-11: - - <gg0_> ../sysdeps/mach/hurd/jmp-unwind.c:53: _longjmp_unwind: - Assertion `! __spin_lock_locked (&ss->critical_section_lock)' - failed. - <gg0_> and - <gg0_> ../libpthread/sysdeps/mach/pt-thread-halt.c:51: - __pthread_thread_halt: Unexpected error: (ipc/send) invalid - destination port. - <tschwinge> gg0_: Which libpthread source are these? Stock Debian - package? - <gg0_> tschwinge: everything debian, ruby rebuilt with - http://paste.debian.net/plain/38519/ which should disable - *context - - IRC, OFTC, #debian-hurd, 2013-09-11: - - <gg0_> wrt ruby, i'd propose a patch that disables *context and - comments out failed tests (a dozen). most of them are timing - related, don't always fail - <gg0_> if they failed gracefully, we could leave them enabled and - just ignoring testsuite result, but most of them block testsuite - run when fail - <gg0_> anyone against? any better idea (and intention to implement - it? :p)? - <gg0_> youpi: is disabling some tests acceptable? ^ - <youpi> it'd be good to at least know what is failing - <youpi> so as to know what impact hiding these failures will have - <youpi> remember that hiding bugs usually means getting bitten by - them even harder later :) - <gg0_> many of them use pipes - <gg0_> here the final list, see commented out ones - http://paste.debian.net/plain/38426 - <gg0_> and as said some don't always fails - <gg0_> test_copy_stream_socket uses a socket - <youpi> note that we can still at least build packages with notest - <youpi> at least to get the binaries uploaded - <youpi> disabling *context should however really be done - <youpi> and the pipe issues are concerning - <youpi> I don't remember other pipe issues - <youpi> so maybe it's a but in the ruby bindings - <gg0_> i just remember they didn't die, then something unknown - fixed it - <youpi> I see something frightening in io.c - <youpi> #if BSD_STDIO - <youpi> preserving_errno(fseeko(f, lseek(fileno(f), - (off_t)0, SEEK_CUR), SEEK_SET)); - <youpi> #endif - <youpi> this looks very much like a workaround for an odd thing in - BSD - <youpi> it happens that that gets enabled on hurd too, since - __MACH__ is defined - <youpi> you could try to drop these three lines, just to see - <youpi> this is very probably very worth investigating, at any rate - <youpi> even just test_gets_limit_extra_arg is a very simple test, - that I fail to see why it should ever fail on hurd-i386 - <youpi> starting debugging it would be a matter of putting printfs - in io.c, to check what gets called, with what parameters, etc. - <youpi> just a matter of taking the time to do it, it's not very - complex - <gg0_> youpi: are you looking at 1.8? no BSD_STDIO here - <youpi> yes, 1.8 - <gg0_> 1.9.3.448 - <gg0_> landed to sid few days ago - <youpi> ah, I have 1.87 - <youpi> +. - <gg0_> my favourites are TestIO#test_copy_stream_socket and - TestIO#test_cross_thread_close_fd -> Illegal instruction - <gg0_> TestIO#test_io_select_with_many_files sometimes Illegal - instruction, sometimes ruby1.9.1: - ../sysdeps/mach/hurd/jmp-unwind.c:53: _longjmp_unwind: Assertion - `! __spin_lock_locked (&ss->critical_section_lock)' failed. - - [[thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock]]? - - <gg0_> trying to debug illegal instruction - http://paste.debian.net/plain/38585/ - <gg0_> (yes, i'm not even good at gdbing) - <gg0_> any hint? - <gg0_> oh found out there's an intree .gdbinit, that might - complicate things - - IRC, OFTC, #debian-hurd, 2013-09-13: - - <gg0_> where should it be implemented MAP_STACK? plus, is it worth - doing it considering migration to tls, wouldn't it be useless? - <gg0_> sysdeps/mach/hurd/mmap.c i should reduce stupid questions - frequency from daily to weekly basis - - IRC, OFTC, #debian-hurd, 2013-09-14: - - <gg0_> say i managed to mmap 0x200000-aligned memory - <gg0_> now i get almost the same failed tests i get disabling - *context - <gg0_> that would mean they don't depend on threading - - IRC, freenode, #hurd, 2013-09-16: - - <gg0> i get many ../sysdeps/mach/hurd/jmp-unwind.c:53: - _longjmp_unwind: Assertion `! __spin_lock_locked - (&ss->critical_section_lock)' failed. - <gg0> by running ruby testsuite, especially during test_read* tests - http://sources.debian.net/src/ruby1.9.1/1.9.3.448-1/test/ruby/test_io.rb#L972 - <gg0> read/write operations with pipes - <braunr> gg0: that's weird - <braunr> gg0: debian glibc ? - <gg0> braunr: yep, debian 2.17-92 - <gg0> sometimes assertion above, sometimes tests in question get - stuck reading - <gg0> it would be nice reproducing it w/o ruby - <gg0> probably massive io on pipes could do the job - <gg0> also more nice finding someone who finds it interesting to - fix :p - <gg0> ruby is rebuilt with http://paste.debian.net/plain/40755/, no - *context - <gg0> pipe function in tests above creates one thread for write, - one for read - http://sources.debian.net/src/ruby1.9.1/1.9.3.448-1/test/ruby/test_io.rb#L26 - <tschwinge> gg0: About the jmp-unwind assertion failure: is it be - chance this issue: - <http://www.gnu.org/software/hurd/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.html>? - I didn't look in detail. - <braunr> tschwinge: that's what i thought too about the assertion, - which is why i find it strange - <gg0> asserting it's not locked then locking it doesn't exclude - race conditions - - IRC, OFTC, #debian-hurd, 2013-09-17: - - <gg0> youpi: i guess no one saw it anymore since - tg-thread-cancel.diff patch - <gg0> it = - http://www.gnu.org/software/hurd/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.html - <gg0> this one comes from sysdeps/mach/hurd/jmp-unwind.c:53 though - <gg0> another assertion to remove? - <youpi> gg0: it's not exactly the same: in hurd_thread_cancel we - hold no lock at all at the assertion point - <youpi> in jmp-unwind.c, we do hold a lock - <youpi> and the assertion might be actually true because all other - threads are supposed to hold the first lock before taking the - other one - <youpi> you could check for that in other places - <youpi> and maybe it's the other place which wouldhave to be fixed - <youpi> also look for documentation which would say that - - IRC, freenode, #hurd, 2013-09-17: - - <braunr_> gg0: is that what we do ?? - <gg0> braunr: well, i was looking at - http://sources.debian.net/src/eglibc/2.17-92/debian/patches/hurd-i386/tg-thread-cancel.diff - <gg0> which afaics fixes - http://www.gnu.org/software/hurd/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.html - <gg0> the one i get now is - http://sources.debian.net/src/eglibc/2.17-92/sysdeps/mach/hurd/jmp-unwind.c#L53 - <gg0> 09:12 < youpi> gg0: it's not exactly the same: in - hurd_thread_cancel we hold no lock at all at the assertion point - <gg0> 09:13 < youpi> in jmp-unwind.c, we do hold a lock - <gg0> 09:13 < youpi> and the assertion might be actually true - because all other threads are supposed to hold the first lock - before taking the other one - <braunr> gg0: that assertion is normal - <braunr> it says there is a deadlock - <braunr> ss->critical_section_lock must be taken before ss->lock - <gg0> you mean ss->lock before ss->critical_section_lock - <braunr> no - <gg0> ah ok got it - <braunr> that's a bug - <braunr> longjmp - <braunr> ugh - <braunr> you could make a pass through the various uses of those - locks and check what the intended locking protocol should be - <braunr> i inferred ss->critical_section_lock before ss->lock from - hurd_thread_cancel - <braunr> this might be wrong too but considering this function is - used a lot, i doubt it - <gg0> (no, i hadn't got it, i was looking at jmp-unwind.c where - lock is before critical_section_lock) - <gg0> could we get useful info from gdb'ing the assertion? - <tschwinge> gg0: Only if you first get an understanding why it is - happening, what you expect to happen instead/why it shall not - happen/etc. Then you can perhaps use GDB to verify that. - <gg0> i can offer an irc interface if anyone is interested, it's - ready, just to attach :) - <gg0> this is the test - http://sources.debian.net/src/ruby1.9.1/1.9.3.448-1/test/ruby/test_io.rb#L937 - <gg0> pipe function creates two threads - http://sources.debian.net/src/ruby1.9.1/1.9.3.448-1/test/ruby/test_io.rb#L26 - <gg0> Attaching to pid 15552 - <gg0> [New Thread 15552.1] - <gg0> [New Thread 15552.2] - <gg0> (gdb) - - IRC, freenode, #hurd, 2013-09-21: - - <youpi> gg0: it seems the assert (! __spin_lock_locked - (&ss->critical_section_lock)); is bogus - <youpi> but it'd be good to catch a call trace - <youpi> well, it may not be bogus, in case that lock is only ever - taken by the thread itself - <youpi> in that case, inside longjmp_unwind we're not supposed to - have it already - <youpi> ok, that's what we had tried to discuss with Roland - <youpi> it can happen when playing with thread cancelation - <braunr> youpi: the assertion isn't exactly bogus - <braunr> the lock ordering is - <youpi> braunr: which one are you talking about? - <youpi> the one in hurd_thread_cancel looks really wrong - <youpi> and some parts of the code keep the critical section lock - without ss->lock held, so I don't see how lock ordering can help - - IRC, OFTC, #debian-hurd, 2013-09-22: - - <gg0> how much does this patch suck on a scale from 1 to 10? - http://paste.debian.net/plain/44810/ - <youpi> well, the stack allocation issue will go away once I get - the threadvars away - <youpi> I'm working on it right now - <youpi> about the lib paths, it makes sense to add the gnu case, - but i386-gnu shouldn't be put in the path - <gg0> that's great - <gg0> so seems the wrong moment for what i've already done - ie. asking terceiro what he thinks about patch above :/ - <gg0> any distro-independent way to get libc.so and libm.so path? - <gg0> ruby as last resource takes them from "ldd ruby" - <pinotree> gg0: should work fine then - <gg0> well it does. but gnu doesn't have a case so it hits default - which is broken - http://bugs.ruby-lang.org/projects/ruby-trunk/repository/revisions/40235/entry/test/dl/test_base.rb - <gg0> btw even linux and kfreebsd with debian multipath have broken - cases but they don't hit default and get fixed by ldd later - <pinotree> why it is broken? are arguments passed to that script? - <gg0> i'm not sure about what propose. a broken case so it doesn't - hit default like linux and kfbsd - <gg0> yes they are :/ - <pinotree> and which ones are? who executes that script and which - arguments does it pass to it? - <gg0> other ruby scripts which have nothing to do with libc/libm - <pinotree> well, if they pass arguments which should be the paths - to libc and libm, they must be getting such paths, aren't they? - <gg0> they don't. arguments are other ruby scripts, don't know why, - maybe something else broken before - <gg0> but that would mean that before there's a smarter path - detection way, i doubt - <pinotree> then add the case for hurd, but setting both libc and - libm as nil - <pinotree> so they will be fetched again - <gg0> yep and would really ugly - <gg0> +be - <gg0> "please commit this one which wrongly sets paths." - <gg0> an alternative would be removing default case - <gg0> or pointing it out by proposing ldd in hurd case might make - them review the whole detection - <gg0> by setting correct paths like in patch above it wouldn't - break a possible hurd-amd64, it would work due to ldd - <youpi> gg0: that's why I said the patch is fine, but without the - i386-gnu part of the path - <youpi> just like it happens to be on linux & kfreebsd - <gg0> i might take ldconfig -p output - <gg0> to make it uselessly correct from start - <gg0> http://bugs.ruby-lang.org/issues/8937 - <pinotree> note thar ruby 1.8 is EOL - <pinotree> *that - <gg0> -- If you're reporting a bug in both Ruby 1.9/2.0 and Ruby - 1.8: ruby-trunk, and write like "this bug can be reproduced in - Ruby 1.8 as well." -- - <gg0> i suspect this one won't be the only one i'll file. unless - upcoming youpi's tls and braunr's thread destruction patches fix - all ruby tests - <pinotree> did you check ruby2.0 too, btw? - <gg0> switched to ruby2 few hours ago. i pointed out 2nd part of - testsuite is not enabled, probably terceiro will enable it soon - <gg0> by applying my patch above we'd completely fix current - ruby2.0 build (yes because tests are not completely enabled) - <pinotree> what you run those extra tests? - <gg0> - http://anonscm.debian.org/gitweb/?p=collab-maint/ruby1.9.1.git;a=blob;f=debian/run-test-suites.bash - <gg0> make test + make test-all - <gg0> (test-all is 2nd part) - <gg0> many are problematic. i didn't finish yet to suppress them - one-by-one. one i suppress, another one pops up - <gg0> either get stuck or well known assertion - <pinotree> check those that get stuck :) - <gg0> which kind of check? - <pinotree> "check" as in "debug" - <gg0> btw i tested puppet few days ago (with ruby1.8), it seems to - be working, at least at trasferring files from master - <gg0> don't know about any advanced usage - <pinotree> ruby 1.8 is going to die soon, so testing things against - it is not totally useful - <gg0> so you assume 1.8 is less broken than 1.9/2.0, right? - <pinotree> no - <gg0> i just can see it's been built without tests itself too - <pinotree> erm no - <gg0> well ok, if i can be wrong, i'll be wrong - <gg0> i say that after a quick check time ago, might be wrong - <pinotree> `getbuildlogs ruby1.8 last hurd-i386`, see the last - build log - <gg0> ah from pkg-kde-tools - <gg0> i hate kde :) - <pinotree> no? - <gg0> no what? - <pinotree> devscripts: /usr/bin/getbuildlog - <gg0> pkg-kde-tools: /usr/bin/pkgkde-getbuildlogs - <pinotree> which is not what i said - <gg0> wait that's what apt-file found - <gg0> maybe i should update it - <gg0> is it so recent? - <pinotree> no - <pinotree> i just added an 's' more at the end of the command, but - typing getbu<tab> could have been helpful anyway... - <gg0> yeah just got it - <gg0> my fault not to have tried to run it before looking for it - <pinotree> and btw, i don't see what hating kde has to do with - tools developed by qt/kde debian packagers - <gg0> j/k i simply don't use kde, never used and apt-file search - told me it was from pkg-kde-tools - <gg0> btw build log says "make test" fails, doesn't even start. and - its failure doesn't block the build - <pinotree> exactly - <gg0> s/make test/make test-all/ - <gg0> "make test" (aka "1st part" above) doesn't run. i guess it's - missing in packaging - - IRC, freenode, #hurd, 2013-09-22: - - <braunr> youpi: i mean the lock order where the assertion occurs is - reserved compared to the one in hurd_thread_cancel - <braunr> (and the one in hurd_thread_cancel is the same used in - hurd condition-related functions) - <youpi> "reserved" ? - <braunr> reversed - <braunr> :) - <youpi> by "the assertion occurs", you mean gg0's spot? - <braunr> yes - <youpi> well , the assertion also happens in hurd_thread_cancel - <braunr> it does oO - <braunr> i didn't see that - <youpi> but otherwise yes, it's completely bogus that we have both - locking in different orders - <youpi> could you submit the fix for jmp-unwind.c to upstream? - <braunr> what fix ? - <youpi> reversing the lock order - <braunr> ah, simply that - <youpi> (well, provided that hurd_thread_cancel is right) - <braunr> that's what i suggested to gg0 - <braunr> to check where those locks are held and determine the - right order - - IRC, OFTC, #debian-hurd, 2013-09-28: - - <gg0_> now we'd just need tls - <gg0_> http://bugs.ruby-lang.org/issues/8937 - <gg0_> well, it would pass makecheck at least. makecheckall would - keep hanging on threads/pipes tests i guess, unless tls/thread - destruction patches fix them - - IRC, OFTC, #debian-hurd, 2013-10-05: - - <youpi> so what is missing for ruby2.0, only disabling use of - context for now, no? - <pinotree> i'm not tracking it closely, gg0_ is - <gg0_> maybe terceiro would accept a patch which only disables - *context, "maybe" because he rightly said changes must go - upstream - <gg0_> anyway with or without *context, many many tests in - makecheckall fail by making it hang, first with and without - assertion you removed, now they all simply hang - <gg0_> youpi: what do we want to do? if you're about finishing tls - migration (as i thought a couple of weeks ago), i won't propose - anything upstream. otherwise i could but that will have to be - reverted upstream once you finish - <gg0_> about tests, current ruby2.0 doesn't run makecheckall, only - makecheck which succeeds on hurd (w/o context) - <gg0_> if anyone wants to give it a try: - http://paste.debian.net/plain/51089 - <gg0_> first hunk makes makecheck (not makecheckall) succeed and - has been upstreamed, not packaged yet - <pinotree> what about makecheckall for ruby2.0? - <gg0_> 16:58 < gg0_> anyway with or without *context, many many - tests in makecheckall fail by making it hang, first with and - without assertion you removed, now they all simply hang - <pinotree> i for a moment thought it as for 1.9.1, ok - <pinotree> these hangs should be debugged, yes - <gg0_> nope, tests behavior doesn't change between 1.9 and 2.0. i - started suppressing tests onebyone on 2.0 as well and as happened - on 1.9, i gave up cause there were too many - <gg0_> yep a smart mind could start debugging them, starting from - patch above pasted by a lazy one owner - <gg0_> one problem is that one can't reproduce them by isolate - them, they don't fail. start makecheckall then wait for one fail - <gg0_> now after my stupid report, someone like pinotree could take - it over, play with it for half an hour/an hour (which equals to - half a gg0's year/a gg0's year - <gg0_> ) - <gg0_> and fix them all - - <gg0_> 17:05 < gg0_> youpi: what do we want to do? if you're about - finishing tls migration (as i thought a couple of weeks ago), i - won't propose anything upstream. otherwise i could but that will - have to be reverted upstream once you finish - <youpi> gg0_: I don't really know what to answer - <youpi> that's why I didn't answer :) - <gg0_> youpi: well then we could upstream context disable and keep - it disabled even if you fix tls. ruby won't be as fast as it - would be with context but i don't think anyone will complain - about that. then once packaged, if terceiro doesn't enable - makecheckall, we will have ruby2.0 in main - <youpi> that can be a plan yes - <gg0_> btw reverting it upstream should not be a problem eventually - <youpi> sure, the thing is remembering to do it - <gg0_> filed http://bugs.ruby-lang.org/issues/8990 - <gg0_> please don't fix tls too soon :) - <gg0_> s/makecheck/maketest/g - - IRC, OFTC, #debian-hurd, 2013-10-08: - - <gg0_> ok. *context disabled http://bugs.ruby-lang.org/issues/8990 - - <gg0> bt full of an attached stuck ruby test - http://paste.debian.net/plain/53788/ - <gg0> anything useful? - <youpi> uh, is that really all? - <youpi> there's not much interesting unfortunately - <youpi> did you run thread apply all bt full ? - <youpi> (not just bt full) - <gg0> no just bt full - <gg0> http://paste.debian.net/plain/53790/ - <gg0> wait, there's a child - <gg0> damn ctrl-c'ing while it was loading symbols made it crash :/ - <gg0> restarted testsuite - <gg0> isn't it interesting that failed tests fail only if testsuite - runs from beginning, whereas if run singularly, they succeed? - <gg0> as it got out of whatever resources - <gg0> youpi: http://paste.debian.net/plain/53798/ - <youpi> the interesting part is actually right at the top - <youpi> it's indeed stuck in the critical section spinlock - <youpi> question being what is keeping it - <youpi> iirc I had already checked in the whole glibc code that all - paths which lock critical_section_lock actually release it in - all cases, but maybe I have missed some - <youpi> (I did find some missing paths, which I fixed) - <gg0> i guess the same check you and braunr talk about in - discussion just before this anchor - http://darnassus.sceen.net/~hurd-web/open_issues/glibc/#recvmmsg - <youpi> yes, but the issue we were discussing there is not what - happens here - <youpi> we would see another thread stuck in the other way roudn, - otherwise - <gg0> no way to get what is locking? - <youpi> no, that's not recorded - <gg0> and what about writing it somewhere right after getting the - lock? - <youpi> one will have to do that in all spots taking that lock - <youpi> but yes, that's the usual approach - <gg0> i would give it try but eglibc rebuild takes too much time, - that conflicts with my laziness - <gg0> i read even making locks timed would help - - IRC, OFTC, #debian-hurd, 2013-10-09: - - <gg0> so correct order would be: - <gg0> __spin_lock (&ss->lock); // locks sigstate - <gg0> __spin_lock (&ss->critical_section_lock); - <gg0> [do critical stuff] - <gg0> __spin_unlock (&ss->critical_section_lock); - <gg0> __spin_unlock (&ss->lock); // unlocks sigstate - <gg0> ? - - <gg0> 21:44 < gg0> terceiro: backported to 2.0 (backport to 1.9 is - waiting) https://bugs.ruby-lang.org/issues/9000 - <gg0> 21:46 < gg0> that means that if you take a 2.0 snapshot, - it'll build fine on hurd (unless you introduce maketestall as in - 1.9, that would make it get stuck like 1.9) - <gg0> 21:48 < terceiro> gg0: nice - <gg0> 21:48 < terceiro> I will try to upload a snapshot as soon as - I can - <gg0> 21:52 < gg0> no problem. you might break my "conditional - satisfaction" by adding maketestall. better if you do that on - next+1 upload so we'll have at least one 2.0 built :) - - <gg0> would it be a problem granting me access to a porter box to - rebuild eglibc+ruby2.0? - <gg0> i'm already doing it on another vm but host often loses power - <pinotree> you cannot install random stuff on a porterbox though - <gg0> i know i'd just need build-deps of eglibc+ruby2.0 i guess - <gg0> (already accessed to porter machines in the past, account - lele, mips iirc) - <gg0> ldap should remember that - <gg0> don't want to disturb anyone else work btw. if it's not a - problem, nice. otherwise no problem - <pinotree> please send a request to admin@exodar.debian.net so it - is not forgotten - <gg0> following this one would be too "official"? - http://dsa.debian.org/doc/guest-account/ - <pinotree> hurd is not a release architecture, so hurd machines are - not managed by DSA - <gg0> ok - <pinotree> the general procedure outlines is ok though, just need - to be sent to the address above - <gg0> sent - <gg0> (1st signed mail with mutt, in the worst case i've attached - passphrase :)) - <youpi> gg0: could you send me an ssh key? - <pinotree> no alioth account? - <youpi> yes, but EPERM - <gg0> youpi: sent to youpi@ - <youpi> youpi@ ? - <gg0> (... which doesn't exist :/) - <gg0> sthibault@ - <youpi> please test gg0-guest@exodar.debian.net ? - <youpi> (I'd rather not adduser the ldap name, who knows what might - happen when you get your DD account) - <gg0> i'm in. thanks - <youpi> you're welcome - <gg0> ldap users need to be adduser'ed? - <youpi> I'm not getting your ldap user account from ud-replicate, - at least - <gg0> (btw i never planned to apply nm, i'd be honoured but i - simply think not to deserve it) - <youpi> never say never ;) - <gg0> bah i like failing. that would be a success. i can't :) - <gg0> gg0-guest@exodar:~$ dchroot - <gg0> E: Access not authorised - <gg0> I: You do not have permission to access the schroot service. - <gg0> I: This failure will be reported. - <youpi> ah, right, iirc I need to add you somewhere - <youpi> gg0: please retry? - <gg0> works - <youpi> good - <gg0> are there already eglibc+ruby2.0 build-deps? - <youpi> yes - <gg0> oh that means i should do something myself now :) - <youpi> yep, that had to happen at some point :) - <gg0> my laziness thanks: "at some point" is better than "now" :) - - IRC, freenode, #hurd, 2013-10-10: - - <gg0> ok just reproduced the - former. ../sysdeps/mach/hurd/jmp-unwind.c:53 waits - <braunr> 20:37 < braunr> gg0: does ruby create and destroy threads - ? - <gg0> no idea - <gg0> braunr: days ago you and youpi talked about locking order - (just before this anchor - http://darnassus.sceen.net/~hurd-web/open_issues/glibc/#recvmmsg) - <braunr> oh right - <gg0> <youpi> could you submit the fix for jmp-unwind.c to - upstream? - <braunr> it didn't made it in the todo list - <gg0> so correct order is in hurd_thread_cancel, right? - <braunr> sorry about that - <braunr> we need to make a pass to make sure it is - <gg0> that means locking first ss->critical_section_lock _then_ - ss->lock - <gg0> correct? - <braunr> but considering how critical hurd_thread_cancel is, i - expect so - - <gg0> i get the same deadlock by swapping locks - <gg0> braunr: youpi: fyi ^ - <gg0> 20:51 < braunr> 20:37 < braunr> gg0: does ruby create and - destroy threads ? - <gg0> how could i check it? - <braunr> gg0: ps -eflw - <youpi> gg0: that's not surprising, since in the b acktrace you - posted there isn't another thread locked in the other order - <youpi> so it's really that somehow the thread is already in - critical sesction - <braunr> youpi: you mean there is ? - <braunr> ah, it's not the same bug - <youpi> no, in what he posted, no other thread is stuck - <youpi> so it's not a locking order - <youpi> just that the critical section is actually busy - <gg0> youpi: ack - <gg0> braunr: what's the other bug? ext2fs one? - <braunr> gg0: idk - <gg0> braunr: thanks. doesn't show threads (found -T for that) but - at least doesn't limit columns number if piped (thanks to -w) - <braunr> it does - <braunr> there is a TH column - <gg0> ok thread count. -T gives more info - - IRC, freenode, #hurd, 2013-10-24: - - <youpi> ruby2.0 builds fine with the to-be-uploaded libc btw - <gg0> youpi: without d-ports patches? surprise me :) - <youpi> gg0: plain main archive source - <gg0> you did it. surprised - <gg0> ah ok you just pushed your tls. great! - <braunr> tls will fix a lot of things - - IRC, OFTC, #debian-hurd, 2013-11-03: - - <youpi> gg0: - <youpi> #252 test_fork.rb:30:in `<top (required)>': core dumped - [ruby-core:28924] - <youpi> FAIL 1/949 tests failed - <youpi> with the to-be-uploaded glibc - <gg0> why does it coredump? - <gg0> that's the test i had workarounded by increasing sleep from 1 - to 3 but i don't recall it coredump'ed - <gg0> *recall if - <gg0> "sleep 1" at bootstraptest/test_fork.rb:33 - <youpi> how can I run the test alone? - - IRC, OFTC, #debian-hurd, 2013-11-04: - - <youpi> gg0: ^ - <gg0> it should not take much - <gg0> run $ make OPTS=-v test - <gg0> found out how to minimize - <gg0> mkdir _youpi && cp bootstraptest/{runner,test_fork}.rb _youpi - <gg0> then run $ ./miniruby -I./lib -I. -I.ext/common - ./tool/runruby.rb --extout=.ext -- --disable-gems - "./_youpi/runner.rb" --ruby="ruby2.0 -I./lib" -q -v - <gg0> youpi: that should work - <youpi> #1 test_fork.rb:1:in `<top (required)>': No such file or - directory - /usr/src/ruby1.9.1-1.9.3.448/ruby2.0 - -I/usr/src/ruby1.9.1-1.9.3.448/lib -W0 bootstraptest.tmp.rb - [ruby-dev:32404] - <gg0> seems it can't find /usr/src/ruby1.9.1-1.9.3.448/ruby2.0 - <youpi> well it's ruby1.9.1 indeed :) - <youpi> ok, got core - <gg0> replace 2.0 with 1.9, check what you have in rootdir - <gg0> k - <youpi> Mmm, no, there's no core file - <gg0> does stupidly increasing sleep time work? - <youpi> nope - <gg0> without *context it runs "make test" fine. real problems come - later with "make test-all" - <gg0> wrt test_fork, is correspondence between signals correct? i - recall i read something about USR1 not implemented - <youpi> USR1 is implemented, it's SIGRT which is not implemented - <gg0> my next wild guess is that that has something to do with - atfork, whatever that means - <gg0> it makes 2 forks: one sleeps for 1 sec then kills -USR1 - itself, the second traps USR1 in getting current time. in the - meanwhile parent sleeps for 2 secs - - IRC, OFTC, #debian-hurd, 2013-11-07: - - <gg0> ruby2.0 just built on unstable - - IRC, OFTC, #debian-hurd, 2013-11-09: - - <gg0> youpi: just found out a more "official" way to run one test - only - http://anonscm.debian.org/gitweb/?p=collab-maint/ruby1.9.1.git;a=blob;f=debian/README.porters;h=94aff7dd3ecd9f748498f2e285b4a4313b4b8f36;hb=HEAD - <gg0> btw still getting coredumps? - - IRC, OFTC, #debian-hurd, 2013-11-13: - - <gg0> wrt the other test test_fork i suppose you made it not to - segfault anymore, it simply does fail - <youpi> I haven't taken any particular care - <youpi> didn't have any time to deal with it - - IRC, OFTC, #debian-hurd, 2013-11-14: - - <gg0> btw patches to disable *context have been backported to 1.9 - as well so next 1.9 point release should have *context disabled - <gg0> as 2.0 have - <gg0> *has - <gg0> i guess you'd like to get them reverted now - <gg0> youpi: ^ - <youpi> after testing that *context work, yes - - * `sigaltstack` - - IRC, freenode, #hurd, 2013-10-09: - - <gnu_srs1> Hi, is sigaltstack() really supported, even if it is - defined as well as SA_ONSTACK? - <braunr> probably not - <braunr> well, - <braunr> i don't know actually, mistaking with something else - <braunr> it may be supported - <pinotree> iirc no - <gnu_srs1> pinotree: are you sure? - <pinotree> this is what i remember - <pinotree> if you want to be sure that $foo works, just do the - usual way: test it yourself - <gnu_srs1> found it: hurd/TODO: *** does sigaltstack/sigstack - really work? -- NO - <pinotree> well TODO is old and there were signal-related patches - by jk in the meanwhile, although i don't think they would have - changed this lack - <pinotree> in any case, test it - <gnu_srs1> anybody fluent in assembly? Looks like this code - destroys the stack: http://paste.debian.net/54331/ - <braunr> gnu_srs1: why would it ? - <braunr> it does something special with the stack pointer but it - just looks like it aligns it to 16 bytes, maybe because of sse2 - restrictions (recent gcc align the stack already anyway) - <gnu_srs1> Well, in that case it is the called function: - http://paste.debian.net/54341/ - <braunr> how do you know there is a problem with the stack in the - first place ? - <gnu_srs1> tracing up to here, everything is OK. then esp and ebp - are destroyed. - <gnu_srs1> and single stepping goes backward until it segfaults - <braunr> "destroyed" ? - <gnu_srs1> zero if I remember correctly now. the x86 version built - for is i586, should that be changed to i486? - <braunr> this shouldn't change anything - <braunr> and they shouldn't get to 0 - <braunr> use gdb to determine exactly which instruction resets the - stack pointer - <gnu_srs1> how to step into the assembly part? using 's' steps - through the function since no line information: - <gnu_srs1> Single stepping until exit from function - wine_call_on_stack, - <gnu_srs1> which has no line number information. - <braunr> gnu_srs1: use break on the address - <gnu_srs1> how do i get the address of where the assembly starts? - - * <a id=recvmmsg>`recvmmsg`/`sendmmsg` (`t/sendmmsg`)</a> - - From [[!message-id "20120625233206.C000A2C06F@topped-with-meat.com"]], - Roland McGrath: *They are generally useful interfaces and there is - nothing intrinsically Linuxoid about them. At least when not given a - timeout, they could be implemented in terms of sendmsg/recvmsg. So - perhaps we ought to have a sysdeps/posix implementation that the Hurd - would use instead of stubs (and folks can consider adding new RPCs). - Then perhaps the Linux fallback case should be that instead of stubs, - too.* - - * <a id=SOCK_CLOEXEC>`SOCK_CLOEXEC`</a> - - IRC, freenode, #hurd, 2013-09-02: - - <gnu_srs1> Do we support accept4 with the SOCK_CLOEXEC flag? - <gnu_srs1> According to the code in sysdeps/mach/hurd/accept4.c - that case is not covered - <gnu_srs1> (only O_NONBLOCK, not SOCK_NONBLOCK??)) - <pinotree> gnu_srs1: we do - <pinotree> but only for accept4, not for socket and socketpair - <gnu_srs1> pinotree: cannot find the case for O_CLOEXEC covered in - __libc_accept4() - <pinotree> gnu_srs1: no, you need SOCK_* - <gnu_srs1> The only code for accept4() is in sysdeps/mach/hurd/ and - it uses O_* for flags ? - <pinotree> flags = sock_to_o_flags (flags); - <pinotree> tried checking it? - <gnu_srs1> Aha, tks:-D - <pinotree> and you don't need an explicit case of O_CLOEXEC, since - it is handled in other ways - - [[!message-id "1378154151.21738.15.camel@G3620.my.own.domain"]]. - - IRC, freenode, #hurd, 2013-09-03: - - <gnu_srs> any ideas about the SOCK_CLOEXEC issue? - <pinotree> didn't i tell already about it? - <gnu_srs> I did not find any hurd related code in tschwinges - branches. - <pinotree> you didn't check deep then... - <gnu_srs> so why does socket/socketpair not return ENOSYS then? - <pinotree> why should it, since they are implemented? - <braunr> ... - <gnu_srs> for socket/socketpair? - <braunr> gnu_srs: enosys means no system call - <gnu_srs> s/ENOSYS/EINVAL/ - <gnu_srs> see the mail to the bug-hurd/debian-hurd ML for more info - <gnu_srs> and tschwinges reply - <pinotree> which is what i knew already? - <gnu_srs> pinotree: please reply on the mailing list on the EINVAL - vs EPROTOTYPE issue to clarify things - <pinotree> gnu_srs: - https://sourceware.org/ml/libc-alpha/2013-02/msg00092.html - <pinotree> gnu_srs: things were clear already... - <gnu_srs> pinotree: I've read that patch and still pflocal/pf.c - returns EPROTOTYPE not changed by the __socket wrapper in eglibc - <pinotree> gnu_srs: what about realizing SOCK_CLOEXEC and friends - are NOT posix? - <gnu_srs> since socket/socketpair does not return EINVAL the dbus - code has to be patched then? - <pinotree> pflocal should never ever get such flags mixed to the - protocol, so any invalid value of protocol correctly returns - EPROTOTYPE - <gnu_srs> this is the question I need answered: Which way to go? - <pinotree> all of them - <gnu_srs> ? - <pinotree> - applications should not assume that because you have - accept4 (which is not posix) then SOCK_CLOEXEC and SOCK_NONBLOCK - (flags for it) are usable to socket and socketpair - <pinotree> - glibc should (as the idea of my patch) handle - implementations providing SOCK_* but not supporting them for - socket/socketpair - <pinotree> - finally the hurd part of glibc could implement them - <gnu_srs> to conclude: should I send a bug report for dbus then? - <gnu_srs> pinotree: yes or no? - <pinotree> gnu_srs: *shrug* i wrote it above, so an *upstream* - report (not a debian one) - - IRC, freenode, #hurd, 2013-09-06: - - <gnu_srs> I've found another error code issue, now in glib2.0 (and - dbus). Are you really sure the error code - <gnu_srs> for protocol of pflocal/pf.c should be - EPROTONOSUPPORT. The code expects EINVAL for a protocol with - <gnu_srs> SOCK_CLOEXEC, which is a flag. Maybe pf.c should add - this case and return EINVAL instead of - <gnu_srs> submitting bug reports upstream. Yes, I know this is not - POSIX, but it is defined for Hurd too, - <gnu_srs> currently only supported for accept4, not socket or - socketpair. - <pinotree> gnu_srs: no, and i explained already why it is wrong - this way - <pinotree> pflocal shouldn't even get such flags - <pinotree> (pflocal or any other server implementing socket_create) - <gnu_srs> (20:19:35) pinotree: pflocal shouldn't even get such - flags - <gnu_srs> then the glibc wrapper code is missing to catch this - flag:( - <gnu_srs> youpi: ? - <pinotree> gnu_srs: because, as told many times, socket and - socketpair do not support such flags - <pinotree> given they don't do, they filter nothing - <pinotree> and no, you need to file bugs upstream, since having - SOCK_* and accept4 does not imply at all that socket and - socketpair support them - - IRC, freenode, #hurd, 2013-09-07: - - <gnu_srs> A correction from yesterdays discussion: - s/EPROTONOSUPPORT/EPROTOTYPE - - IRC, freenode, #hurd, 2013-09-10: - - <gnu_srs> for dbus2.0 I found out that the third SOCK_CLOEXEC case - needs a patch too (more working tests), - <gnu_srs> the updated patch is at http://paste.debian.net/37948/ if - you have the time, otherwise I'll do it. - <pinotree> gnu_srs: which is what i wrote in my bug report... - <gnu_srs> Yes you wrote that, but the patch is not updated yet? - <pinotree> it refers to a different socket access, recently added, - which is not used by default - <gnu_srs> I got two more tests running when adding that patch:-/ - <pinotree> tests of what? - <gnu_srs> run-test.sh and run-test-systemserver.sh:P - <pinotree> tests of what? - <pinotree> i don't have the universal knowledge of the files in all - the sources - <gnu_srs> dbus-1.6.14/test/name-test/* - - [[!message-id "523A3D6C.2030200@gmx.de"]]. - - IRC, OFTC, #debian-hurd, 2013-09-19: - - <pinotree> tschwinge: ehm, regarding the SOCK_* patches for - socket/socketpair, didn't we talk about them when i worked on - eglibc 2.17? - - * `mlock`, `munlock`, `mlockall`, `munlockall` - - IRC, freenode, #hurd, 2014-01-09: - - <gnu_srs> Hi, is mlock, mlockall et al implemented? - <braunr> i doubt it - <braunr> mlock could be, but mlockall only partially - - * [[glibc_IOCTLs]] - - * Support for `$ORIGIN` in the dynamic linker, `ld.so` - - IRC, freenode, #hurd, 2014-02-23: - - <sjamaan> - https://www.gnu.org/software/hurd/user/jkoenig/java/report.html - says $ORIGIN patches have been added to Hurd. Have those hit the - mainline codebase? - - [[user/jkoenig/java]], [[user/jkoenig/java/report]]. - - <sjamaan> It doesn't seem to work here, but perhaps I'm missing - something (I'm using the prebuilt Debian/Hurd 2014-02-11 VM - image) - <sjamaan> objdump -x says the value of RPATH is $ORIGIN - <sjamaan> But it doesn't load a library I placed in the same dir as - the binary - <braunr> sjamaan: i'm not sure - <braunr> sjamaan: what are you trying to do ? - - IRC, freenode, #hurd, 2014-02-24: - - <sjamaan> braunr: I am working on a release of the CHICKEN Scheme - compiler. Its test suite is currently failing on the stand-alone - deployment tests. Either it should work and use $ORIGIN, or the - test should be disabled, saying Hurd is not supported for - stand-alone deployment-directories - <sjamaan> braunr: The basic idea is to be able to create "appdirs" - like on OS X or PC-BSD, containing all the dependencies a program - needs, which can then simply be untarred - <braunr> sjamaan: ok so you do need $ORIGIN - <sjamaan> yeah - <sjamaan> iiuc, so does Java. Does Java work on Hurd? - <braunr> we had packages at the time jkoenig worked on it - <braunr> integration of patches may have been incomplete, i wasn't - there at the time and i'm not sure - <sjamaan> So it's safest to claim it's unsupported, for now? - <braunr> yes - <sjamaan> Thank you, I'll do that and revisit it later - - * `mig_reply_setup` - - IRC, freenode, #hurd, 2014-02-24: - - <teythoon> braunr: neither hurd, gnu mach or glibc provides - mig_reply_setup - <teythoon> i want to provide this function, where should i put it ? - <teythoon> i found some mach source that put it in libmach afaic - <teythoon> - ftp://ftp.sra.co.jp/.a/pub/os/mach/extracted/mach3/mk/user/libmach/mig_reply_setup.c - <braunr> teythoon: what does it do ? - <teythoon> braunr: not much, it just initializes the reply message - <teythoon> libports does this as well, in the - ports_manage_port_operations* functions - <braunr> teythoon: is it a new function you're adding ? - <teythoon> braunr: yes - <teythoon> braunr: glibc has a declaration for it, but no - implementation - <braunr> teythoon: i think it should be in glibc - <braunr> maybe in mach/ - - * [[POSIX file record locking|file_locking]] - - * <a name="execve_relative_paths">`execve` with relative paths</a> - - [[!GNU_Savannah_bug 28934]], [[user/pochu]], [[!message-id - "4BFA500A.7030502@gmail.com"]]. - - IRC, freenode, #hurd, 2014-03-05: - - <teythoon> youpi: what about the exec_filename patch series? [...] - <youpi> Roland was disagreeing with it - - * <a name="mount">`mount`/`umount`</a> - - IRC, freenode, #hurd, 2014-03-01: - - <gnu_srs1> Hi, how to handle packages depending on mount.h, et al? - On Hurd mount/umount is supplied by hurd is not in libc? - <azeem> gnu_srs1: mount or mount.h? - <gnu_srs1> mount.h et al - <gnu_srs1> man 2 mount - <azeem> what is the question then? - <gnu_srs1> some packages expect the mount 2 functionality - available, not by the external command mount/umonut - <gnu_srs1> umount* - <gnu_srs1> azeem: one example is fuse - <teythoon> gnu_srs1: that is correct - <teythoon> gnu_srs1: i put a small hacks entry in the list about - moving the mount/umount functionality from our utilities to the - libc - - * <a name="posix_timers">POSIX Timers</a> - - `timer_create`, `timer_delete`, [[`clock_gettime`|clock_gettime]], and - so on. - - * `fd_to_filename` - - See [[translate_FD_or_port_to_file_name]]. - - For specific packages: - - * <a id=octave>[[octave]]</a> - - * <a id=t_cleanup_kernel-features.h>Create `t/cleanup_kernel-features.h`.</a> - - * <a id=Secure_file_descriptor_handling>[[Secure_file_descriptor_handling]].</a> - - * <a id=sendfile>In `sysdeps/unix/sysv/linux/Makefile`, there are a bunch of - `-DHAVE_SENDFILE` -- but we do have `sendfile`, too.</a> - - Define `__ASSUME_SENDFILE` to 1 in `kernel-features.h`, if `sendfile` - works. - - * <a id=pthreadoverwrite>`/usr/include/pthread.h` overwrite issue</a> - - `make`, after editing `nss/nss_db/db-initgroups.c`: - - [...] - make[2]: Leaving directory `/media/erich/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker/resolv' - make subdir=nss -C nss ..=../ others - make[2]: Entering directory `/media/erich/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker/nss' - /usr/bin/install -c -m 644 ../include/pthread.h /usr/include/pthread.h - /usr/bin/install: cannot remove `/usr/include/pthread.h': Permission denied - make[2]: *** [/usr/include/pthread.h] Error 1 - make[2]: Leaving directory `/media/erich/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker/nss' - make[1]: *** [nss/others] Error 2 - make[1]: Leaving directory `/media/erich/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker' - make: *** [all] Error 2 - - See [[!message-id "871uv99c59.fsf@kepler.schwinge.homeip.net"]]. Passing - `install_root=/INVALID` to `make`/`make check` is a cheap cure. For `make - install`, prepending an additional slash to `install_root` (that is, - `install_root=//[...]`) is enough to obfuscate the Makefile rules. - - * <a id=syslog.c>`sysdeps/unix/sysv/linux/syslog.c`</a> - - * <a id=fsync>`fsync` on a pipe</a> - - IRC, freenode, #hurd, 2012-08-21: - - <braunr> pinotree: i think gnu_srs spotted a conformance problem in - glibc - <pinotree> (only one?) - <braunr> pinotree: namely, fsync on a pipe (which is actually a - socketpair) doesn't return EINVAL when the "operation not supported" - error is returned as a "bad request message ID" - <braunr> pinotree: what do you think of this case ? - <pinotree> i'm far from an expert on such stuff, but seems a proper E* - should be returned - <braunr> (there also is a problem in clisp falling in an infinite loop - when trying to handle this, since it uses fsync inside the error - handling code, eww, but we don't care :p) - <braunr> basically, here is what clisp does - <braunr> if fsync fails, and the error isn't EINVAL, let's report the - error - <braunr> and reporting the error in turn writes something on the - output/error stream, which in turn calls fsync again - <pinotree> smart - <braunr> after the stack is exhausted, clisp happily crashes - <braunr> gnu_srs: i'll alter the clisp code a bit so it knows about our - mig specific error - <braunr> if that's the problem (which i strongly suspect), the solution - will be to add an error conversion for fsync so that it returns - EINVAL - <braunr> if pinotree is willing to do that, he'll be the only one - suffering from the dangers of sending stuff to the glibc maintainers - :p - <pinotree> that shouldn't be an issue i think, there are other glibc - hurd implementations that do such checks - <gnu_srs> does fsync return EINVAL for other OSes? - <braunr> EROFS, EINVAL - <braunr> fd is bound to a special file which does not - support synchronization. - <braunr> obviously, pipes and sockets don't - <pinotree> - http://pubs.opengroup.org/onlinepubs/9699919799/functions/fsync.html - <braunr> so yes, other OSes do just that - <pinotree> now that you speak about it, it could be the failure that - the gnulib fsync+fdatasync testcase have when being run with `make - check` (although not when running as ./test-foo) - <braunr> hm we may not need change glibc - <braunr> clisp has a part where it defines a macro IS_EINVAL which is - system specific - <braunr> (but we should change it in glibc for conformance anyway) - <braunr> #elif defined(UNIX_DARWIN) || defined(UNIX_FREEBSD) || - defined(UNIX_NETBSD) || defined(UNIX_OPENBSD) #define IS_EINVAL_EXTRA - ((errno==EOPNOTSUPP)||(errno==ENOTSUP)||(errno==ENODEV)) - <pinotree> i'd rather add nothing to clisp - <braunr> let's see what posix says - <braunr> EINVAL - <braunr> so right, we should simply convert it in glibc - <gnu_srs> man fsync mentions EINVAL - <braunr> man pages aren't posix, even if they are usually close - <gnu_srs> aha - <pinotree> i think checking for MIG_BAD_ID and EOPNOTSUPP (like other - parts do) will b enough - <pinotree> *be - <braunr> gnu_srs: there, it finished correctly even when piped - <gnu_srs> I saw that, congrats! - <braunr> clisp is quite tricky to debug - <braunr> i never had to deal with a program that installs break points - and handles segfaults itself in order to implement growing stacks :p - <braunr> i suppose most interpreters do that - <gnu_srs> So the permanent change will be in glibc, not clisp? - <braunr> yes - - IRC, freenode, #hurd, 2012-08-24: - - <gnu_srs1> pinotree: The changes needed for fsync.c is at - http://paste.debian.net/185379/ if you want to try it out (confirmed - with rbraun) - <youpi> I agree with the patch, posix indeed documents einval as the - "proper" error value - <pinotree> there's fdatasync too - <pinotree> other places use MIG_BAD_ID instead of EMIG_BAD_ID - <braunr> pinotree: i assume that if you're telling us, it's because - they have different values - <pinotree> braunr: tbh i never seen the E version, and everywhere in - glibc the non-E version is used - <gnu_srs1> in sysdeps/mach/hurd/bits/errno.h only the E version is - defined - <pinotree> look in gnumach/include/mach/mig_errors.h - <pinotree> (as the comment in errno.h say) - <gnu_srs1> mig_errors.h yes. Which comment: from errors.h: /* Errors - from <mach/mig_errors.h>. */ and then the EMIG_ stuff? - <gnu_srs1> Which one is used when building libc? - <gnu_srs1> Answer: At least in fsync.c errno.h is used: #include - <errno.h> - <gnu_srs1> Yes, fdatasync.c should be patched too. - <gnu_srs1> pinotree: You are right: EMIG_ or MIG_ is confusing. - <gnu_srs1> /usr/include/i386-gnu/bits/errno.h: /* Errors from - <mach/mig_errors.h>. */ - <gnu_srs1> /usr/include/hurd.h:#include <mach/mig_errors.h> - - IRC, freenode, #hurd, 2012-09-02: - - <antrik> braunr: regarding fsync(), I agree that EOPNOTSUPP probably - should be translated to EINVAL, if that's what POSIX says. it does - *not* sound right to translate MIG_BAD_ID though. the server should - explicitly return EOPNOTSUPP, and that's what the default trivfs stub - does. if you actually do see MIG_BAD_ID, there must be some other - bug... - <braunr> antrik: right, pflocal doesn't call the trivfs stub for socket - objects - <braunr> trivfs_demuxer is only called by the pflocal node demuxer, for - socket objects it's another call, and i don't think it's the right - thing to call trivfs_demuxer there either - <pinotree> handling MAG_BAD_ID isn't a bad idea anyway, you never know - what the underlying server actually implements - <pinotree> (imho) - <braunr> for me, a bad id is the same as a not supported operation - <pinotree> ditto - <pinotree> from fsync's POV, both the results are the same anyway, ie - that the server does not support a file_sync operation - <antrik> no, a bad ID means the server doesn't implement the protocol - (or not properly at least) - <antrik> it's usually a bug IMHO - <antrik> there is a reason we have EOPNOTSUPP for operations that are - part of a protocol but not implemented by a particular server - <pinotree> antrik: even if it could be the case, there's no reason to - make fsync fail anyway - <antrik> pinotree: I think there is. it indicates a bug, which should - not be hidden - <pinotree> well, patches welcome then... - <antrik> thing is, if sock objects are actually not supposed to - implement the file interface, glibc shouldn't even *try* to call - fsync on them - <pinotree> how? - <pinotree> i mean, can you check whether the file interface is not - implemented, without doing a roundtrip^ - <pinotree> ? - <antrik> well, the sock objects are not files, i.e. they were *not* - obtained by file_name_lookup(), but rather a specific call. so glibc - actually *knows* that they are not files. - <braunr> antrik: this way of thinking means we need an "fd" protocol - <braunr> so that objects accessed through a file descriptor implement - all fd calls - <antrik> now I wonder though whether there are conceivable use cases - where it would make sense for objects obtained through the socket - call to optionally implement the file interface... - <antrik> which could actually make sense, if libc lets through other - file calls as well (which I guess it does, if the sock ports are - wrapped in normal fd structures?) - <braunr> antrik: they are - <braunr> and i'd personally be in favor of such an fd protocol, even if - it means implementing stubs for many useless calls - <braunr> but the way things are now suggest a bad id really means an - operation is simply not supported - <antrik> the question in this case is whether we should make the file - protocol mandatory for anything that can end up in an FD; or whether - we should keep it optional, and add the MIG_BAD_ID calls to *all* FD - operations - <antrik> (there is no reason for fsync to be special in this regard) - <braunr> yes - <antrik> braunr: BTW, I'm rather undecided whether the right approach - is a) requiring an FD interface collection, b) always checking - MIG_BAD_ID, or perhaps c) think about introducing a mechanism to - explicitly query supported interfaces... - - IRC, freenode, #hurd, 2012-09-03: - - <braunr> antrik: querying interfaces sounds like an additional penalty - on performance - <antrik> braunr: the query usually has to be done only once. in fact it - could be integrated into the name lookup... - <braunr> antrik: once for every object - <braunr> antrik: yes, along with the lookup would be a nice thing - - [[!message-id "1351231423.8019.19.camel@hp.my.own.domain"]]. - - * <a id=t_no-hp-timing>`t/no-hp-timing`</a> - - IRC, freenode, #hurd, 2012-11-16 - - <pinotree> tschwinge: wrt the glibc topgit branch t/no-hp-timing, - couldn't that file be just replaced by #include - <sysdeps/generic/hp-timing.h>? - - * <a id=flockfile>`flockfile`/`ftrylockfile`/`funlockfile`</a> - - IRC, freenode, #hurd, 2012-11-16 - - <pinotree> youpi: uhm, in glibc we use - stdio-common/f{,try,un}lockfile.c, which do nothing (as opposed to eg - the nptl versions, which do lock/trylock/unlock); do you know more - about them? - <youpi> pinotree: ouch - <youpi> no, I don't know - <youpi> well, I do know what they're supposed to do - <pinotree> i'm trying fillig them, let's see - <youpi> but not why we don't have them - <youpi> (except that libpthread is "recent") - <youpi> yet another reason to build libpthread in glibc, btw - <youpi> oh, but we do provide lockfile in libpthread, don't we ? - <youpi> pinotree: yes, and libc has weak variants, so the libpthread - will take over - <pinotree> youpi: sure, but that in stuff linking to pthreads - <pinotree> if you do a simple application doing eg main() { fopen + - fwrite + fclose }, you get no locking - <youpi> so? - <youpi> if you don't have threads, you don't need locks :) - <pinotree> ... unless there is some indirect recursion - <youpi> ? - <pinotree> basically, i was debugging why glibc tests with mtrace() and - ending with muntrace() would die (while tests without muntrace call - wouldn't) - <youpi> well, I still don't see what a lock will bring - <pinotree> if you look at the muntrace implementation (in - malloc/mtrace.c), basically fclose can trigger a malloc hook (because - of the free for the FILE*) - <youpi> either you have threads, and it's need, or you don't, and it's - a nop - <youpi> yes, and ? - <braunr> does the signal thread count ? - <youpi> again, in linux, when you don't have threads, the lock is a nop - <youpi> does the signal thread use IO ? - <braunr> that's the question :) - <braunr> i hope not - <youpi> IIRC the signal thread just manages signals, and doesn't - execute the handler itself - <braunr> sure - <braunr> i was more thinking about debug stuff - <youpi> can't hurt to add them anyway, but let me still doubt that it'd - fix muntrace, I don't see why it would, unless you have threads - <pinotree> that's what i'm going next - <pinotree> pardon, it seems i got confused a bit - <pinotree> it'd look like a genuine muntrace bug (muntrace → fclose → - free hook → lock lock → fprint (since the FILE is still set) → malloc - → malloc hook → lock lock → spin) - <pinotree> at least i got some light over the flockfile stuff, thanks - ;) - <pinotree> youpi: otoh, __libc_lock_lock (etc) are noop in the base - implementation, while doing real locks on hurd in any case, and on - linux only if nptl is loaded, it seems - <pinotree> that would explain why on linux you get no deadlock - <youpi> unless using nptl, that is? - <pinotree> hm no, even with pthread it works - <pinotree> but hey, at least the affected glibc test now passes - <pinotree> will maybe try to do investigation on why it works on linux - tomorrow - - [[!message-id "201211172058.21035.toscano.pino@tiscali.it"]]. - - In context of [[libpthread]]. - - IRC, freenode, #hurd, 2013-01-21 - - <braunr> ah, found something interesting - <braunr> tschwinge: there seems to be a race on our file descriptors - <braunr> the content written by one thread seems to be retained - somewhere and another thread writing data to the file descriptor will - resend what the first already did - <braunr> it could be a FILE race instead of fd one though - <braunr> yes, it's not at the fd level, it's above - <braunr> so good news, seems like the low level message/signalling code - isn't faulty here - <braunr> all right, simple explanation: our IO_lockfile functions are - no-ops - <pinotree> braunr: i found that out days ago, and samuel said they were - okay - <braunr> well, they're not no-ops in libpthreads - <braunr> so i suppose they replace the default libc stubs, yes - <pinotree> so the issue happens in cthreads-using apps? - <braunr> no - <braunr> we don't have cthreads apps any more - <braunr> and aiui, libpthreads provides cthreads compatibility calls to - libc, so everything is actually using pthreads - <braunr> more buffer management debugging needed :/ - <pinotree> hm, so how can it be that there's a multithread app with no - libpthread-provided file locking? - <braunr> ? - <braunr> file locking looks fine - <braunr> hm, the recursive locking might be wrong though - <braunr> ./sysdeps/mach/hurd/bits/libc-lock.h:#define - __libc_lock_owner_self() ((void *) __hurd_threadvar_location (0)) - <braunr> nop, looks fine too - <braunr> indeed, without stream buffering, the problem seems to go away - <braunr> pinotree: it really looks like the stub IO_flockfile is used - <braunr> i'll try to make sure it's the root of the problem - <pinotree> braunr: you earlier said that there's some race with - different threads, no? - <braunr> yes - <braunr> either a race or an error in the iostream management code - <braunr> but i highly doubt the latter - <pinotree> if the stub locks are used, then libpthread is not - loaded... so which different threads are running? - <braunr> that's the thing - <braunr> the libpthread versions should be used - <pinotree> so the application is linked to pthread? - <braunr> yes - <pinotree> i see, that was the detail i was missing earlier - <braunr> the common code looks fine, but i can see wrong values even - there - <braunr> e.g. when vfprintf calls write, the buffer is already wrong - <braunr> i've made similar tests on linux sid, and it behaves as it - should - <pinotree> hm - <braunr> i even used load to "slow down" my test program so that - preemption is much more likely to happen - <pinotree> note we have slightly different behaviour in glibc's libio, - ie different memory allocation ways (mmap on linux, malloc for us) - <braunr> the problem gets systematic on the hurd while it never occurs - on linux - <braunr> that shouldn't matter either - <pinotree> ok - <braunr> but i'll make sure it doesn't anyway - <braunr> this mach_print system call is proving very handy :) - <braunr> and also, with load, unbuffered output is always correct too - <pinotree> braunr: you could try the following hack - http://paste.debian.net/227106/ - <braunr> what does it do ? - <pinotree> (yes, ugly as f**k) - <braunr> does it force libio to use mmap ? - <braunr> or rather, enable ? - <pinotree> provides a EXEC_PAGESIZE define in libio, so it makes it use - mmap (like on linux) instead of malloc - - * <a id=t_pagesize>`t/pagesize`.</a> - - <braunr> yes, the stub is used instead of the libpthreads code - <braunr> tschwinge: ^ - <braunr> i'll override those to check that it fixes the problem - <braunr> hm, not that easy actually - <pinotree> copy their files from libpthreads to sysdeps/mach/hurd - <pinotree> hm right, in libpthread they are not that split as in glibc - <braunr> let's check symbol declaration to understand why the stubs - aren't overriden by ld - <braunr> _IO_vfprintf correctly calls @plt versions - <braunr> i don't know enough about dynamic linking to see what causes - the problem :/ - <braunr> youpi: it seems our stdio functions use the stub IO_flockfile - functions - <youpi> really? I thought we were going through cthreads-compat.c - <braunr> yes really - <braunr> i don't know why, but that's the origin of the "duplicated" - messages issue - <braunr> messages aren't duplicated, there is a race that makes on - thread reuse the content of the stream buffer - <braunr> one* - <youpi> k, quite bad - <braunr> at least we know where the problem comes from now - <braunr> youpi: what would be the most likely reason why weak symbols - in libc wouldn't be overriden by global ones from libpthread ? - <youpi> being loaded after libc - <braunr> i tried preloading it - <braunr> i'll compare with what is done on wheezy - <youpi> you have the local-dl-dynamic-weak.diff patch, right? - <braunr> (on squeeze, the _IO_flockfile function in libc seems to do - real work unlike our noop stub) - <braunr> it's the debian package, i have all patches provided there - <braunr> indeed, on linux, libc provides valid IO_flock functions - <braunr> ./sysdeps/pthread/flockfile.c:strong_alias (__flockfile, - _IO_flockfile) - <braunr> that's how ntpl exports it - <braunr> nptl* - <pinotree> imho we should restructure libpthread to be more close to - nptl - <braunr> i wish i knew what it involves - <pinotree> file structing for sources and tests, for example - <braunr> well yes obviously :) - <braunr> i've just found a patch that does exactly that for linuxthreads - <pinotree> that = fix the file locking? - <braunr> in addition to linuxthreads/lockfile.c (which we also - equivalently provide), there is - linuxthreads/sysdeps/pthread/flockfile.c - <braunr> no, restructiring - <braunr> restructuring* - <braunr> i still have only a very limited idea of how the glibc sources - are organized - <pinotree> the latter is used as source file when compiling flockfile.c - in stdio-common - <braunr> shouldn't we provide one too ? - <pinotree> that would mean it would be compiled as part of libc proper, - not libpthread - <braunr> yes - <braunr> that's what both linuxthreads and nptl seem to do - <braunr> and the code is strictly the same, i.e. a call to the internal - _IO_lock_xxx functions - <youpi> I guess that's for the hot-dlopen case - <youpi> you need to have locks properly taken at dlopen time - <braunr> youpi: do you mean adding an flockfile.c file to our sysdeps - will only solve the problem by side effect ? - <braunr> and that the real problem is that the libpthread versions - aren't used ? - <youpi> yes - <braunr> ok - <braunr> youpi: could it simply be a versioning issue ? - <youpi> could be - <braunr> it seems so - <braunr> i've rebuilt with the flockfile functions versioned to 2.2.6 - (same as in libc) and the cthreads_compat functions are now used - <braunr> and the problem doesn't occur any more with my test code - <braunr> :) - <youpi> could you post a patch? - <braunr> i need a few info before - <youpi> it'd be good to check which such functions are hooked - <braunr> i suppose the version for functions declared in libpthreads - shouldn't change, right ? - <youpi> yes - <braunr> ok - <youpi> they didn't have a vresion before - <braunr> shall i commit directly ? - <youpi> so it should be fine - <braunr> well, they did - <braunr> 2.12 - <youpi> yes, but please tell me when it's done - <braunr> sure - <youpi> so I can commit that to debian's eglibc - <youpi> I mean, before we integrated libpthread build into glibc - <youpi> so they never had any version before 2.12 - <braunr> ok - <youpi> basically we need to check the symbols which are both in - libpthread and referenced in libc - <youpi> to make sure they have the same version in the reference - <braunr> ok - <youpi> only weak references need to be checked, others would have - produced a runtime error - <braunr> youpi: done - <braunr> arg, the version i mention in the comment is wrong - <braunr> i suppose people understand nonetheless - <youpi> probably, yes - <braunr> ah, i can now appreciate the headache this bug hunting gave me - these last days :) - - IRC, freenode, #hurd, 2013-01-22 - - <youpi> braunr: commited to debian glibc - <youpi> btw, it's normal that the program doesn't terminate, right? - <youpi> (i.e. it's the original bug you were chasing) - <braunr> youpi: about your earlier question (yesterday) about my test - code, it's expected to block, which is the problem i was initially - working on - <youpi> ok, so all god - <youpi> +o - - * <a id=t_pagesize2>`t/pagesize`</a> - - IRC, freenode, #hurd, 2012-11-16 - - <pinotree> tschwinge: somehow related to your t/pagesize branch: due to - the fact that EXEC_PAGESIZE is not defined on hurd, libio/libioP.h - switches the allocation modes from mmap to malloc - - [[!message-id "87mxd9hl2n.fsf@kepler.schwinge.homeip.net"]]. - - IRC, freenode, #hurd, 2013-01-21 - - <braunr> why is it a hack ? - <pinotree> because most probably glibc shouldn't rely on EXEC_PAGESIZE - like that - <braunr> ah - <pinotree> there's a mail from roland, replying to thomas about this - issue, that this use of EXEC_PAGESIZE to enable mmap or not is just - wrong - <braunr> ok - <pinotree> (the above is - http://thread.gmane.org/87mxd9hl2n.fsf@kepler.schwinge.homeip.net ) - <braunr> thanks - <pinotree> (just added the reference to that in the wiki) - <braunr> pinotree: btw, what's wrong with using malloc instead of mmap - in libio ? - <pinotree> braunr: i'm still not totally sure, most probably it should - be slightly slower currently - <braunr> locking contention ? - <braunr> pinotree: - http://www.sourceware.org/ml/libc-alpha/2006-11/msg00061.html - <braunr> pinotree: it looks to me there is now no valid reason not to - use malloc - <braunr> the best argument for mmap is that libio requires zeroed - memory, but as the OP says, zeroing a page is usually more expensive - than a small calloc (even on kernel that keep a list of zeroed pages - for quick allocations, frequent mmaps() often make this list empty) - <pinotree> braunr: mmap allocations in libio are rounded to the page - size - <braunr> well they have to - - * <a id=LD_DEBUG>`LD_DEBUG`</a> - - IRC, freenode, #hurd, 2012-11-22 - - <pinotree> woot, `LD_DEBUG=libs /bin/ls >/dev/null` prints stuff and - then sigsegv - <tschwinge> Yeah, that's known for years... :-D - <tschwinge> Probably not too difficult to resolve, though. - - * IRC, OFTC, #debian-hurd, 2013-08-16: - - <pinotree> http://paste.debian.net/25934/ ← _hurd_thread_sigstate calls - malloc, boom - - * <a id=conformtest>`conformtest`</a> - - IRC, OFTC, #debian-hurd, 2013-09-22: - - <youpi> btw, I noticed that glibc has a head conformance test which we - happily fail quite a bit :) - <youpi> it's not so awful, we don't have twice as many failures as - linux, but not so far - <pinotree> youpi: do you mean "header" for "head", right? - <youpi> err, where ? :) - <pinotree> <youpi> btw, I noticed that glibc has a head conformance - test which we happily fail quite a bit :) - <youpi> ah, yes - <pinotree> noticed that too - <youpi> I had a quick look at the POSIX part, some things are probably - not too hard to change (e.g. exposing pthread_kill in signal.h) - <youpi> others will by quite hard to fix (short type instead of int - type for some flock structure field) - <youpi> s/by/be/ - - * `truncate`/`ftruncate` - - Hurd fixed with 2013-10-03 commit 6c3825f2b750bf9b913c6ea986739e648c470603, - glibc still to be done? - - IRC, freenode, #hurd, 2013-10-01: - - <pinotree> libdiskfs/node-drop.c: assert (np->dn_stat.st_size == 0); ← - this one? - <pinotree> iirc you constantly get that when building ustr - <braunr> is ustr a package ? - <pinotree> yes - <pinotree> iirc the ustr tests are mostly disk-intensive - - IRC, freenode, #hurd, 2013-10-02: - - <braunr> i've traced the problem up to truncate - <braunr> which gets a negative size - <braunr> shouldn't take long to find out where it comes from now - <pinotree> it seems our truncate doesn't handle negative values well though - <braunr> EINVAL The argument length is negative or larger than the - maximum file size. - <braunr> i still have to see whether it comes from the user (unlikely) or - if it's an internal inconsistency - <braunr> i suspect some code wrongly handles vm_map failures - <braunr> leading to that inconsistency - <braunr> pinotree: looks like glibc doesn't check for length >= 0 - <pinotree> yeah - <braunr> servers should do it nonetheless - <pinotree> should we fix glibc, libdiskfs/libnetfs/libtrivfs/etc, or both? - <braunr> it appears a client does the truncate - <braunr> i'd say both - <braunr> can you take the glibc part ? :) - <pinotree> i was going to do the hurd part... :p - <pinotree> ok, i'll pick libc - <braunr> well i'm doing it already - <braunr> i want to write a test case first - <braunr> to make sure that's the problem - <pinotree> already on the hurd part, you mean? - <braunr> yes - <pinotree> ok - <braunr> ok looks like it - <braunr> i can't reproduce the assertion but it does make ext2fs freeze - <braunr> pinotree: http://darnassus.sceen.net/~rbraun/test_ftruncate.c - <pinotree> merci - <braunr> pinotree: ustr builds - <pinotree> wow - <braunr> the client code (ustr) seems to perform a ftruncate with size - ((size_t)-1) whereas lengths are signed .. - <braunr> i'll check other libraries and send a patch soon - - IRC, freenode, #hurd, 2013-10-03: - - <braunr> youpi: i've committed a fix to hurd that checks for negative sizes - when truncating files - <braunr> this allows building the ustr package without making ext2fs choke - on an assertion - <braunr> pinotree is preparing a patch for glibc - <braunr> see truncate/ftruncate - <braunr> with an off_t size parameter, which can be negative - <braunr> EINVAL The argument length is negative or larger than the - maximum file size. - <braunr> hurd servers were not conforming to that before my change - - * `t/ptrmangle`: `PTR_MANGLE`/`PTR_DEMANGLE` - - * <https://sourceware.org/glibc/wiki/PointerEncryption> - - * See also [[t/tls|t/tls]]. - - * b7f2d27dbd85f6a0966dc389ad4f8205085b7ae8 `ARM: Add pointer encryption - support.` may help to find all the places that need to be touched when - adding support. - - * <a id=baselinechanges>Verify baseline changes, if we need any follow-up changes:</a> - - * a11ec63713ea3903c482dc907a108be404191a02 - * 7e2b0c8562b35155820f87b5ff02a8b6850344cc - * 8c0677fe5d91b7269364ca08fa08ed09e4c2d8c9 - * 5a2a1d75043138e696222ced4560de2fb90b8024 - * 5ae958d74180e2572d198bd7872c86f391de6da7 - * 5b08ac571ff8e94fe96511a532f0d20997de5f52 - * 3d04ff3a5d3ce3616837e1d15e03b6e1b360cf26 - * b2ef2c014b9c66995a3eb4f310ae7c5c510279bf - * 63c4ed22b5048c8701d8806026c23cc95f0df756 - * ac2b484c02b01307ab6bbe5d45ddbf16d64edf8c - * e35fcef8b739ed24e083ff8a3078ac14e101cf67 - * 6fb8cbcb58a29fff73eb2101b34caa19a7f88eba - * 8a492a675e566dc1e666df0a86cbf541442cb179 - * 5dbc3b6cc0b759bf4b22d851ccb9cbf3e3cbc6ef - * c86434ccb576a3ce35b5a74f72b9f03bd45b522a - * d22e4cc9397ed41534c9422d0b0ffef8c77bfa53 - * 15bac72bac03faeb3b725b1d208c62160f0c3ad7 - * c08fb0d7bba4015078406b28d3906ccc5fda9d5a - * 10b3bedcb03386cc280113f552479793e4bac35f - * 754f7da38b0904b4b989d3500cc8dd5be625cf6a - * 3cdaa6adb113a088fdfb87aa6d7747557eccc58d - * 962dba7828cf251a9025ccb43bc6effa30379b72 - * 3162f12e58c3a848db883916843b332b9f8c9d39 - * 1c06ba3100847da6bd1f2e011dc24fa8debd9615 - * 84b9230c404aed4fd3a7bb3d045ca367043dde8c - * 090555538d4347a52807ba9f08cf20ed13206afe - * 817328eea788c746131cf151b64fd250200da333 - * c3758feebf7c8786231465da664743c6f0ec79cc - * 1ac7a2c7b448c851eb8976fcc290a906a4075203 - * c21cc9bcb38a87ff638d1099ca871d94a2192b31 - * 6484ba5ef092b62b7d2112c0d976dbd6d1a40fde - * b8b4863d78bf26b39918fc753b03ed98ef262903 - * b76b818e6fe2061e778b3a9bbe63c554c3f9b3c1 - * 8e9f92e9d5d7737afdacf79b76d98c4c42980508 -- `_dl_map_object` in - `sysdeps/mach/hurd/dl-sysdep.c` - * 0e516e0e14f2f9783a21cd1727bc53776341f857 - * a1fb5e3ebe9d38b5ae6c5bfbfaa04882d52355bc - * cf7c9078a5acdbb435498ace92cd81009637a971 - * db753e2cfb2051ebf20dc089f87c5b1297cc2cff - * 4a531bb0b3b582cb693de9f76d2d97d970f9a5d5 -- looks good. - * 5bd6dc5c2c68fe98691db9b40f87d9b68ea9565b - * 451f001b50870604e1f2daef12f04f9f460d3997 + - a85b5cb4d4a5fc56e2b38638d270bf2daa67eb6c -- BZ10484. `nptl/Versions - [libc] (GLIBC_PRIVATE): Export __libc_alloca_cutoff`. We don't even - define it yet. Also see - [[glibc___libc_alloca_cutoff_should_be_lowered]]. - * 1086d70d916fd0eb969b3d89ff88abd35f6a5c34 - * cfa28e560ef69372b9e15e9a2d924a0fbcfc7bca - * 8cf8ce1702c354a8266e3cfa6ab54c2467d1873f - * 68dc949774cb651d53541df4abdc60327f7e096b - * 70181fddf1467996bea393d13294ffe76b8a0853 - * a77e8cbc394ab098aa1fc3f0a6645a38348d21ca - * 32465c3ea007065acd8ca8199f130cdf4068130d - * 18ba70a559c52719fd94a713cc380514d9d19125 - * 620a05296fe3380b7441ba7720e8b25c48a8c28c - * [low] e6c61494125126d2ba77e5d99f83887a2ed49783 -- `Fix memory leak in - TLS of loaded objects.` Do we need to replicate `nptl/allocatestack.c` - hunk? - * 6e04cbbe79f5965809fdbf1f28d7ae8b4af74d31 + - 1bfbe0d335d3fc44a492648b974a0db19975f6d8 -- `Fix - pathconf(_PC_BUF_SIZE).` - * 28377d1bf58625172a1734b92e835591d4d23a18 -- `Optimize fdopendir a bit.` - * 7fb90fb89bbdf273ab7ab96517fe1b156cd7aee1 + - 6fb2dde3f1aa3a1419cb6c2dfa53dd1d506722a4 -- `Fix Linux getcwd for long - paths` - * f574184a0e4b6ed69a5d9a3234543fba6d2a7367 -- `Fix sched_setscheduler - call in spawn implementation` - * 3b85df27870a47ed1db84e948e37a5a50a178a92 + - f50ef8f1efdd1f2b040acbb8324604f168e8832a -- sysconf - * 68a3f91fcad464c4737c1eaed4ae0bf539801fb2 -- `Fix reporting of invalid - timeouts in emulated pselect` - * ea389b12b3b65c4a7fa91fa76f8c99867eb37865 -- `strndup -> __strndup`; - strndupa? - * 7e4afad5bcf49e03c3b987399c6a8f66a9018660 -- `Nicer output for negative - error numbers in strerror_r`. Change needed for - `sysdeps/mach/_strerror.c`? - * 7ea72f99966a65a56aedba817ee2413ff9b1f23c + - adcd5c15d2a37794d021104160b425ff61f88219 -- `Always fill output buffer - in XPG strerror function`. Change needed for - `sysdeps/mach/xpg-strerror.c`? - * a91710475294c66d0005bdaae0919d36ef8ce3d2 -- sotruss ([[debugging]], - [[profiling]]). Does it work? - * b1ebd700c5295a449f8d114740f0d1fb6e6b2eb5 + - 80e2212d8e59933a1641f029ebd360526ff0e074 + - 4997db742946d08be4378cf91221f558f928bc73 -- `Don't document si_code - used for raise()`. Also for `bits/siginfo.h`? - * 11988f8f9656042c3dfd9002ac85dff33173b9bd -- pldd, Does it work? - Probably not: needs `/proc/[PID]/auxv`, `/proc/[PID]/exe`, - `/proc/[PID]/mem` ([[!tag open_issue_hurd]], - [[hurd/translator/procfs]]). - * 9113ea1f3f29b3aee710efc829e85a9772bcb836 -- `--experimental-malloc`. - Watch what happens. - * 4e34ac6a1e256f40ab0d8eeed37aa1ea83440e76 -- `-defsym=_begin=0`. Watch - what happens. Native build: apparently OK. - * f781ef4015504e8a1da649c266584976238aa079 (`--with-default-link`) + - 1b74661a6b93a892ecb1c717dedeedba5c2a976c + - fd5e21c75d8e9221d766f4bc922a237265514ec2. Watch what happens. Native - build: `use-default-link = no`. - * de283087c74f720cf8a7171972e72b5fa2b45e79 (`Handle Lustre filesystem`), - 4e5f31c847982997c856f03bbc35134e9fd0f61f (`Handle ext4 in - {,f}pathconf`). What about stuff like that for us? - * d30cf5bb00bfb286ff14d931fb69f5b53724bcdc (`Find readelf with - AC_CHECK_TOOL`). Aren't there more in other configure.in and Makefile - files? - * 7a03a9c8c4b37b88ac5e82b557d974f3161ddaf9 (`Add read barriers in - cancellation initialization`). Is this needed in other places, too? - * [low] 5744c68d78f6ca6c6500e2c8d3d85b3a31f4ed2a (`Align x86 TCB to 64 - bytes`). Probably we have hidden somewhere such a constant, too (in - libpthread). - * d96de9634a334af16c0ac711074c15ac1762b23c + - ecb1482ffd85fd3279642b1dc045aa867ad4d415 (`Try shell in posix_spawn* - only in compat mode`). Change looks good, but what about - `SPAWN_XFLAGS_TRY_SHELL` for us? - * 3ce1f2959437e952b9db4eaeed2407424f11a4d1 (`Make several tool features - mandatory and simplify the code.`). Generally looks good. - * `locale/global-locale.c`: Apparently, no one is using - `_HURD_THREADVAR_LOCALE`. But it is exported via - `hurd/threadvar.h`. - * `mach/devstream.c`: reversed. Fixed in - `t/repair-mach_devstream.c`. - * `malloc/arena.c`: should be OK. - * `Remove support for !USE___THREAD`. - d063d164335938d557460bebaa7cfe388157b627 (generally looks good; - `csu/errno-loc.c` (should be OK); `include/errno.h` (fixed)) + - (de82006d43e198fd162807c9adc720c7ebd728a3 + - 037e9fe21c92216ef7032ea2796781ec27ca182a) + - 995a80dfbcb443ead5aa22682c884ec5c827a2ea (discussing) + - bc7e1c3667b577ad418f7520df2a7dbccea04ee9 (should be ok). - * [OK] 22a89187139a9083ca73989bfd11597e0f85cb61 (`malloc: Remove all - kinds of unused configuration options and dead code.`). `NO_STARTER` - changes (should be OK). - * [high] `pagesize`, 02d46fc4b969e25e4ba0c54aa95fa98d7279bd05 (`Simplify - malloc initialization`); aebae0537dcb408100b88c6b7647a7e858c43237, - [[!sourceware_PR 11929]]. Is this all kosher for us? See - [[!message-id "87mxd9hl2n.fsf@kepler.schwinge.homeip.net"]]. - * [OK] 83cd14204559abbb52635006832eaf4d2f42514a (`Remove --wth-tls - option, TLS support is required`). - * a7c8e6a1478de9f990b11e5e853318ccbe4330f2 (`Fix invalid conversion in - __cmsg_nxthdr`). Probably just a C++ thing and not relevant for us; - see [[!message-id "87r52nk1kx.fsf@kepler.schwinge.homeip.net"]]. - * [low] `mmap`, 110946e473b38fc3896212e416d9d7064fecd5b7. Kosher with - respect to our [[glibc/mmap]] peculiarities? - * [OK] `__attribute__ ((__leaf__))`, `BZ #13344`, - aa78043a4aafe5db1a1a76d544a833b63b4c5f5c + - 49a43d80ec5c97cf6136b1ee2687414773b2d5aa + - 3871f58f065dac3917eb18220a479e9591769c8c + - 9beb2334930db81ceada5aa6051fe5ac0554db32 + - 0ffc4f3ebaace42cd545db55a2ac50b6e0cc7d89 + - edc5984d4d18296d7aa3d8f4ed8f7336a743170e + - 57769839788e2c62b68d9dfbf4b35052321278ba. - <http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html>. - * [low] `conformtest`, 3134156779108fe8b46e0f4cd60d837572faaa93 + - 4efeffc1d583597e4f52985b9747269e47b754e2 + - d94a4670800de6e8f088b8630ad5142866127980 -- should probably mirror - `bits/siginfo.h` changes. - * [low] stack guard, 6c6a98c983c44b440ae66d2aa8f32529a9dd7bfe, - [[!message-id "4F3BE241.9090409@mentor.com"]] -- anything needed for - us? - * [low] `libc-lockP.h` 9463518d0d314d7bd0160315e0ef30e15be08985 -- - probably should do similar changes, also to the generic file. - * [low] `bits/socket.h`/`bits/socket_type.h` [[!message-id - "Pine.LNX.4.64.1203090206420.18868@digraph.polyomino.org.uk"]] - 02a6f887cb3e2c048937111eb4cf150d397609de -- probably should do the same - for the generic version as used by GNU Hurd. - * [low] CFI for `_start`, 6a1bd2a100c958d30bbfe8c9b8f9071d24b7c3f4, - [[!message-id "20120316180551.GA6291@host2.jankratochvil.net"]] -- what - about other architectures? - * `linkobj/libc.so`, 510bbf14b4f25fec8ee3a2d24de3f24bdbf84333 -- need to - adapt for (conditional?) Sun RPC reversion (if that was the original - cause for the patch)? - * [low] `Add __fsword_t and use it in bits/statfs.h`, - 3e5aef87d76cfa7354f2b0d82b96e59280720796, [[!message-id - "20120517134700.GA19046@intel.com"]] -- only updates one copy of - `bits/statfs.h`; update the others, too, for consistency. - * [low] 789bd351b45f024b7f51e4886bf46b8e887ab6da: remove - `libc_hidden_def` in `sysdeps/mach/hurd/accept4.c`? - * 0948c3af9dfb3bc1312d6bed2f3a6bfd4e96eef4, - b80af2f40631871cf53a5e39d08d5d5516473b96, - 04570aaa8ad88caad303f8afe469beb4cf851e17 `_dl_initial_dtv`: OK? - * [very low] ea4d37b3169908615b7c17c9c506c6a6c16b3a26 `Implement - POSIX-generic sleep via nanosleep rather than SIGARLM.`: any benefit - using that one (with `sysdeps/mach/nanosleep.c`) instead of - `sysdeps/mach/sleep.c`? - * ea4d37b3169908615b7c17c9c506c6a6c16b3a26 -- IRC, freenode, #hurd, - 2012-11-20, pinotree: »tschwinge: i agree on your comments on - ea4d37b3169908615b7c17c9c506c6a6c16b3a26, especially since mach's - sleep.c is buggy (not considers interruption, extra time() (= RPC) - call)«. - * ba384f6ed9275f3966505f2375b56d169e3dc588, - 0409959c86f6840510851a851a1588677a2e537b, - e57b0c6100e63bfd816ae59339452eafc81f1d3a `C++11 thread_local - destructors support`. Anything needed to be done in our [[libpthread]] - and configured for us in [[GCC]]? Probably need to replicate the - `nptl/pthread_create.c` change, and fix - `stdlib/Makefile`:`$(objpfx)tst-tls-atexit`. - - +++ include/link.h - @@ -302,6 +302,9 @@ struct link_map - + /* Number of thread_local objects constructed by this DSO. */ - + size_t l_tls_dtor_count; - - +++ include/stdlib.h - @@ -100,6 +100,11 @@ extern int __cxa_atexit (void (*func) (void *), void *arg, void *d); - +extern int __cxa_thread_atexit_impl (void (*func) (void *), void *arg, - + void *d); - +extern void __call_tls_dtors (void); - +libc_hidden_proto (__call_tls_dtors); - - +++ nptl/pthread_create.c - @@ -311,6 +311,9 @@ start_thread (void *arg) - [after the thread function returns] - + /* Call destructors for the thread_local TLS variables. */ - + __call_tls_dtors (); - - +++ stdlib/Makefile - +$(objpfx)tst-tls-atexit = $(common-objpfx)nptl/libpthread.so \ - + $(common-objpfx)dlfcn/libdl.so - - +++ stdlib/cxa_thread_atexit_impl.c - - +++ stdlib/exit.c - __run_exit_handlers (int status, struct exit_function_list **listp, - bool run_list_atexit) - { - + /* First, call the TLS destructors. */ - + __call_tls_dtors (); - - +gcc-4.7 tst-tls-atexit.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wno-parenth - +gcc-4.7 -nostdlib -nostartfiles -o [...]/tschwinge/Roger_Whittaker.build/stdlib/tst-tls-atexit [...]/tschwinge/Roger_Whittaker.build/nptl/lib - +gcc-4.7: error: [...]/tschwinge/Roger_Whittaker.build/nptl/libpthread.so: No such file or directory - +make[2]: *** [[...]/tschwinge/Roger_Whittaker.build/stdlib/tst-tls-atexit] Error 1 - +gcc-4.7 tst-tls-atexit-lib.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wno-par - +tst-tls-atexit-lib.c: In function 'do_foo': - +tst-tls-atexit-lib.c:35:3: warning: implicit declaration of function '__cxa_thread_atexit_impl' [-Wimplicit-function-declaration] - * a600e5cef53e10147932d910cdb2fdfc62afae4e `Consolidate Linux and POSIX - libc_fatal code.` -- is `backtrace_and_maps` specific to Linux? - - IRC, freenode, #hurd, 2014-02-06: - - <braunr> why wouldn't glibc double free detection code also print - the backtrace on hurd ? - <youpi> I don't see any reason why - <youpi> except missing telling glibc that it's essentially like on - linux - - * 288f7d79fe2dcc8e62c539f57b25d7662a2cd5ff `Use __ehdr_start, if - available, as fallback for AT_PHDR.` -- once we require Binutils 2.23, - can we simplify [[glibc's process startup|glibc/process]] - (initialization of `_dl_phdr` and `_dl_phnum`)? As these are only used - for `[!SHARED]`, can we completely remove them (that is, the `phdr` and - `phdrsz` members) from `hurd_startup_data`, and simplify - [[hurd/interface/exec_startup_get_info]], or do we still require these - for the `[SHARED]` case? - * fab7ce3f5b4060bf62659e8b58529de4156b5a2f `Link extra-libs consistently - with libc and ld.so.` Alright for us? Probably have to adjust - [libpthread]/Makefile. - * b8c61b4b1d6afb69190169764c1b141f4659e48b `Remove trailing whitespace - from mach/*.sub.` Update `mach/Makefile`: generated - `mach/errsystems.c` is no longer checked in as of - 66e3dda448406399136e6f144a1b46679d5b2613. Rule had been disabled in - 421f82e5cc8f81ab003247d771bcecbad799be85, then re-enabled in - 8e3cc80f6d4f69ce003c82d3561ac324692792ad, but comment not removed. - * [low] 61dd6208fb1e59a423b6dfa712a3c896c34b2590 `New API to set default - thread attributes`. Implement in libpthread ([[!taglink - open_issue_libpthread]])? - * [high] e4608715e6e1dd2adc91982fd151d5ba4f761d69 `CVE-2013-2207, BZ - #15755: Disable pt_chown. -- [[!message-id - "51E8D4C1.9000705@redhat.com"]]; do we need it (`--enable-pt_chown`)? - cdfc721b8d2d5079325ea9f0beb5673d72b4cdd0. - * 91ce40854d0b7f865cf5024ef95a8026b76096f3 `CVE-2013-4237, BZ #14699: - Buffer overflow in readdir_r` -- [[!message-id - "519220C7.6050705@redhat.com"]]; do we need corresponding changes to - Hurd sysdep files? - * 8cc3269f95fa7faa8f448d741f68cbc40efbf4ee `Flesh out 4.4 bits/socket.h - with SOCK_CLOEXEC, SOCK_NONBLOCK.`, - e041fb8b6557882b6710a655a97bbf3541b56b54 `Replace generic bits/socket.h - with 4.4 file.` -- `sysdeps/mach/hurd/bits/socket.h` differs from the - generic `bits/socket.h` now only in the values of - [[`SOCK_CLOEXEC`|secure_file_descriptor_handling]] and - `SOCK_NONBLOCK`. If possible (no conflicts), would it make sense to - transition to the latter file, continuing to accept the former values - as deprecated for some time? - * [high] 6a97b62a5b4f18aea849d6f4d8de58d1469d2521 `Fix unsafe compiler - optimization` -- have to revert, see [[!sourceware_PR 15605]]. For - analysis/fix also look at 384ca551743318bd9c9e24a496d6397f2e3f2a49. - * 6c82a2f8d7c8e21e39237225c819f182ae438db3 `Coordinate IPv6 definitions - for Linux and glibc` -- alright for us? - * c61b4d41c9647a54a329aa021341c0eb032b793e `POINTER_CHK_GUARD` -- see - [[t/tls|t/tls]]. - * 5f855e3598a576c35e54623a13b256f3e87fcd4d `Fix erroneous (and circular) - implied pattern rule for linkobj/libc.so.` -- alright for us? - * [high] 7b7bab1391a3b16fff7e325e2c8a36b68eacba90 [Hurd] `Add fork hooks - for pthread_atfork` -- is that from a topic branch that can then be - annihilated? Verify emails. Verify no further changes in topic - branch. - * [high] 43d5c02c72bdaf59a8e0d4b06f2ae87e42269cbd `Fix build on hurd` -- - is that from a topic branch that can then be annihilated? Verify - emails. Verify no further changes in topic branch. - * 69a17d9d245dc3551792e95e1823cc2d877592f3 `Patch [1/4] - async-signal safe TLS.` -- do we also need an implementation of this? - (Not yet called from anywhere?) Now used in - 7f507ee17aee720fa423fa38502bc3caa0dd03d7 `Async-signal safe TLS`. - 7f507ee17aee720fa423fa38502bc3caa0dd03d7 has been reverted in - 73d61e4f6c65da714c0f8a3a233725322553ceba. - 1f33d36a8a9e78c81bed59b47f260723f56bb7e6, - 063b2acbce83549df82ab30f5af573f1b9c4bd19, - b627fdd58554bc36bd344dc40a8787c4b7a9cc46, - e81c64bba13d2d8b2a4e53254a82cc80f27c8497 have been reverted in - dd654bf9ba1848bf9ed250f8ebaa5097c383dcf8. - 35e8f7ab94c910659de9d507aa0f3e1f8973d914 has been reverted in - 8b6785f0836011cace9a77f3c24e51a7379238a0. - 69a17d9d245dc3551792e95e1823cc2d877592f3 has been reverted in - bf06bcee84d4c19a99925c0f58026a8cbd87a688. - a494421f5268df333c589d71104a39bb6a9cff19 has been reverted in - f482dbbec775bf72eb6510b6091fca141893c466. - * [low] In various commits, `menual/*.texi` files have been annotated - regarding MTASC-safety properties. The focus has not necessarily been - on Hurd, though. - * *baseline* - - -## Update - -`baseline`, `t/regenerate_configure` (could now be removed), -`t/master_backports`, `t/eglibc_backports`, `t/host-independency`, -`tschwinge/Roger_Whittaker` - - -# Build - -Here's a log of a glibc build run; this is from our [[Git repository's -f68531785b6d85fb0b405747688f93471b6a964f (2015-01-23; -9a869d822025be8e43b78234997b10bf0cf9d859 (2014-02-07)) -plus 6a97b62a5b4f18aea849d6f4d8de58d1469d2521 reverted, -`id:"87a9fvguwq.fsf@schwinge.name"`, -`_SERVERS_STARTUP` hard-coded to `/servers/startup` in `sysdeps/mach/hurd/reboot.c` -sources|source_repositories/glibc]], run on laplace.SCHWINGE. - - $ export LC_ALL=C - $ ../Roger_Whittaker/configure --prefix=/usr --disable-profile --disable-multi-arch --build=i486-gnu --host=i486-gnu CC=gcc-4.7 CXX=g++-4.7 2>&1 | tee log_build - [...] - $ make install_root=/INVALID 2>&1 | tee log_build_ - [...] - -This takes up around 600 MiB, and runs for [[TODO min|performance#measure]] on -kepler.SCHWINGE and [[19 min|performance#measure]] on laplace.SCHWINGE. - -<!-- - - $ (make install_root=/INVALID && touch .go-install) 2>&1 | tee log_build_ && test -f .go-install && (make install_root="$PWD".install install && touch .go-test) 2>&1 | tee log_install && test -f .go-test && ln -s /usr/lib/i386-*gnu/libstdc++.so.6 /lib/i386-*gnu/libgcc_s.so.1 mach/libmachuser.so.1 hurd/libhurduser.so.0.3 ./ && make -k install_root=/INVALID check fast-check=yes 2>&1 | tee log_test - ---> - - -## Analysis - - $ toolchain/logs/process glibc build fetch laplace.SCHWINGE - -TODO. - - * baseline - fd5bdc0924e0cfd1688b632068c1b26f3b0c88da..2ba92745c36eb3c3f3af0ce1b0aebd255c63a13b - (or probably Samuel's mmap backport) introduces: - - ../sysdeps/mach/hurd/mmap.c: In function '__mmap': - ../sysdeps/mach/hurd/mmap.c:54:15: warning: comparison between pointer and integer [enabled by default] - ../sysdeps/mach/hurd/mmap.c:66:21: warning: comparison between pointer and integer [enabled by default] - ../sysdeps/mach/hurd/mmap.c:143:13: warning: comparison between pointer and integer [enabled by default] - ../sysdeps/mach/hurd/mmap.c:165:24: warning: comparison between pointer and integer [enabled by default] - - * baseline - fd5bdc0924e0cfd1688b632068c1b26f3b0c88da..2ba92745c36eb3c3f3af0ce1b0aebd255c63a13b - introduces: - - nscd_gethst_r.c: In function '__nscd_get_nl_timestamp': - nscd_gethst_r.c:112:4: warning: implicit declaration of function 'time' [-Wimplicit-function-declaration] - - This was already present before: - - nscd_gethst_r.c: In function 'nscd_gethst_r': - nscd_gethst_r.c:426:5: warning: implicit declaration of function '__close' [-Wimplicit-function-declaration] - - * baseline - 2ba92745c36eb3c3f3af0ce1b0aebd255c63a13b..7a270350a9bc3110cd5ba12bbd8c5c8c365e0032 - introduces: - - tst-relsort1.c:6:1: warning: function declaration isn't a prototype [-Wstrict-prototypes] - - * baseline - fc56c5bbc1a0d56b9b49171dd377c73c268ebcfd..cbc818d0ee66065f3942beffdca82986615aa19a - introduces - - +gcc-4.6 tst-printf-round.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wno-parentheses -Wstrict-prototypes -I../include -I[...]/tschwinge/Roger_Whittaker.build-gcc-4. - +tst-printf-round.c: In function 'do_test': - +tst-printf-round.c:203:11: warning: passing argument 3 of 'test_hex_in_one_mode' discards 'const' qualifier from pointer target type [enabled by default] - +tst-printf-round.c:139:1: note: expected 'const char **' but argument is of type 'const char * const*' - +tst-printf-round.c:208:8: warning: passing argument 3 of 'test_hex_in_one_mode' discards 'const' qualifier from pointer target type [enabled by default] - +tst-printf-round.c:139:1: note: expected 'const char **' but argument is of type 'const char * const*' - +tst-printf-round.c:216:8: warning: passing argument 3 of 'test_hex_in_one_mode' discards 'const' qualifier from pointer target type [enabled by default] - +tst-printf-round.c:139:1: note: expected 'const char **' but argument is of type 'const char * const*' - +tst-printf-round.c:224:8: warning: passing argument 3 of 'test_hex_in_one_mode' discards 'const' qualifier from pointer target type [enabled by default] - +tst-printf-round.c:139:1: note: expected 'const char **' but argument is of type 'const char * const*' - - gcc-4.6 test-wcschr.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wno-parentheses -Wstrict-prototypes -I../include -I[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486 - +In file included from test-wcschr.c:2:0: - +../string/test-strchr.c: In function 'check1': - +../string/test-strchr.c:249:3: warning: passing argument 1 of 'stupid_STRCHR' from incompatible pointer type [enabled by default] - +../string/test-strchr.c:77:1: note: expected 'const wchar_t *' but argument is of type 'char *' - +../string/test-strchr.c:249:22: warning: initialization from incompatible pointer type [enabled by default] - +../string/test-strchr.c:252:5: warning: passing argument 2 of 'check_result' from incompatible pointer type [enabled by default] - +../string/test-strchr.c:92:1: note: expected 'const wchar_t *' but argument is of type 'char *' - +../string/test-strchr.c:252:5: warning: passing argument 4 of 'check_result' from incompatible pointer type [enabled by default] - +../string/test-strchr.c:92:1: note: expected 'const wchar_t *' but argument is of type 'char *' - - -# Install - -TODO. - - $ make install_root="$PWD".install install 2>&1 | tee log_install - [...] - -This takes up around 100 MiB, and runs for [[TODO min|performance#measure]] on -kepler.SCHWINGE and [[3 min|performance#measure]] on laplace.SCHWINGE. - - -## Analysis - - $ toolchain/logs/process glibc install fetch laplace.SCHWINGE - -TODO. - - -# Testsuite - - $ make -k install_root=/INVALID check fast-check=yes 2>&1 | tee log_test - [...] - -This runs for [[TODO min|performance#measure]] on kepler.SCHWINGE and [[10 -min|performance#measure]] on laplace.SCHWINGE. - -Specifying `fast-check=yes` disables the `conformtest` which ran for 1.75 h (out -of 2.75 h total) on coulomb.SCHWINGE, doesn't pass anyway, and clearly isn't -our most critical issue to solve. -`elf/tst-xmmymm.out` is another candidate to disable: needs 90 min to run. - - -## Analysis - - $ toolchain/logs/process glibc test fetch laplace.SCHWINGE - -Failures, mostly in order of appearance: - - * `check-abi`, `check-abi-libmachuser`, `check-abi-libhurduser`, - `check-abi-libBrokenLocale`, `check-abi-libm`, `check-abi-libdl`, - `check-abi-libcrypt`, `check-abi-libresolv`, `check-abi-librt`, - `check-abi-libnsl`, `check-abi-libutil`, `check-abi-libc`, `check-abi-ld`, - `c++-types.data` - - Reference files are missing. - - * `math/test-float.out`, `math/test-double.out` - - A handful of ULP failures. - - * `math/test-ldouble`, `math/test-ildoubl`, `math/test-ifloat`, - `math/test-idouble` - - SIGSEGV. Or SIGILL. - - * `stdlib/tst-secure-getenv.out` - - open (/proc/self/exe): No such file or directory - - Needs [[`/proc/self/exe`|hurd/translator/procfs/jkoenig/discussion]]. - - * `stdlib/tst-strtod-round.out` - - strtold (-0x0.7p-16445) returned -0x0.0000000000008p-16385 not -0x0.000000000000001p-16385 (FE_DOWNWARD) - strtold (-0x0.7p-16494) returned -0x0.0000000000008p-16385 not -0x0.000000000000001p-16385 (FE_DOWNWARD) - - * `stdio-common/bug22.out` - - Timed out: killed the child process - - Known problem. - - * `libio/tst-atime.out`, `dirent/tst-fdopendir.out` - - [[!message-id "201305102256.56636.toscano.pino@tiscali.it"]]. - - `libio/tst-atime.out`: - - atime has not changed - - Due to `ext2fs --no-atime`. - - * IRC, OFTC, #debian-hurd, 2013-05-08 - - <youpi> bah, tst-atime failure :) - <pinotree> do you have its output? - <youpi> well it's very simple - <youpi> I have the noatime option on / :) - <pinotree> oh - <youpi> fortunately fsysopts works :) - <pinotree> the test checks whether ST_NOATIME is in the mount - options, maybe it would be a good idea to provide it - <youpi> yes - <pinotree> unfortunately it isn't in posix, so i'm not sure whether - adding it to the general bits/statvfs.h would be welcome - <pinotree> or whether we should fork it, like it is done for linux - <pinotree> oh no, we fork it already - <pinotree> \o/ - - `dirent/tst-fdopendir.out`: - - directory atime changed - - Due to `ext2fs --atime` (default). - - * `libio/tst-fopenloc.check`, `posix/bug-regex31-mem`, - `posix/tst-fnmatch-mem`, `misc/tst-error1-mem` - - Memory not freed: - ----------------- - Address Size Caller - 0x0807e268 0x8000 at 0x10c71c4 - - Caused by different memory allocation way in libio, see - [[!message-id "87mxd9hl2n.fsf@kepler.schwinge.homeip.net"]] - - * `dlfcn/bug-atexit3.out` - - Originally: - - dlopen failed: libstdc++.so.6: cannot open shared object file: No such file or directory - - See [[!message-id "20090420002344.11798.qmail@s461.sureserver.com"]]. - Hacked around with `ln -s /usr/lib/i386-*gnu/libstdc++.so.6 - /lib/i386-*gnu/libpthread-stubs.so.0 /lib/i386-*gnu/libgcc_s.so.1 ./`. - This is a bug in the glibc test harness. Should probably use some - `configure` magic akin to the `fixincludes` stuff (`gcc-4.4 - -print-file-name=libstdc++.so.6`, etc.). - - Even if that that is being worked around, the tests nowadays - ([[packaging_libpthread]]) fail with: - - dlopen failed: [...]/libc.so.0.3: version `GLIBC_2.13_DEBIAN_31' not found (required by [...]/libstdc++.so.6) - - * `dlfcn/tststatic.out`, `dlfcn/tststatic2.out`, `dlfcn/tststatic3.out`, - `dlfcn/tststatic4.out`, `dlfcn/tststatic5.out` - - SIGSEGV. - - `LD_LIBRARY_PATH` doesn't contain the `mach` and `hurd` directories; yet - the test shouldn't just SIGSEGV. - - * `dirent/opendir-tst1.out`, `dirent/tst-fdopendir2.out` - - `dirent/opendir-tst1.out`: - - `opendir' succeeded on a FIFO??? - - `dirent/tst-fdopendir2.out`: - - fdopendir with normal file descriptor did not fail - - `opendir` and `fdopendir` do not return `ENOTDIR` if `fd` is not a - directory. - - * `posix/tst-waitid.out` - - Intermittent. - - SIGCHLD for stopped status 0 - SIGCHLD for stopped pid -1 - SIGCHLD for killed code 1 - SIGCHLD for killed status 0 - SIGCHLD for killed pid -1 - - * `posix/bug-glob2.out` - - Intermittent. - - Timed out: killed the child process - - * `posix/annexc.out` - - Failure ignored by the glibc testsuite. - - * `posix/tst-getconf.out` - - Ends with: - - getconf POSIX_ALLOC_SIZE_MIN /: [...]/posix/getconf: pathconf: /: Invalid argument - - It fails because of unimplemented pathconf cases: `_PC_ALLOC_SIZE_MIN`, - `_PC_REC_INCR_XFER_SIZE`, `_PC_REC_MAX_XFER_SIZE`, `_PC_REC_MIN_XFER_SIZE`, - `_PC_REC_XFER_ALIGN`, `_PC_SYMLINK_MAX`, `_PC_2_SYMLINKS`. - - `_CS_GNU_LIBPTHREAD_VERSION` is provided by libpthread when compiled as - add-on. - - * `posix/tst-sysconf.out` - - Fails with: - - sysconf(_SC_BARRIERS) must be 200809L - sysconf(_SC_READER_WRITER_LOCKS) must be 200809L - sysconf(_SC_SEMAPHORES) must be 200809L - sysconf(_SC_SPIN_LOCKS) must be 200809L - sysconf(_SC_THREAD_ATTR_STACKADDR) must be 200809L - sysconf(_SC_THREAD_ATTR_STACKSIZE) must be 200809L - sysconf(_SC_THREADS) must be 200809L - sysconf(_SC_TIMEOUTS) must be 200809L - - That, I presume, is in response to our `sysdeps/mach/hurd/bits/posix_opt.h` - file, which uses *200112L* values. - `nptl/sysdeps/unix/sysv/linux/bits/posix_opt.h` uses *200809L* values. - - * `posix/tst-vfork3-mem` - - + 0x0804cee0 Alloc 10 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389] - + 0x0804cf90 Alloc 11 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963] - + 0x0804cfa8 Alloc 12 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] - + 0x00000008 Alloc 17 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] - + 0x0804cee0 Alloc 18 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389] - + 0x0804cf90 Alloc 19 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963] - + 0x0804cfa8 Alloc 20 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] - + 0x00000008 Alloc 25 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] - + 0x0804cee0 Alloc 26 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389] - + 0x0804cf90 Alloc 27 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963] - + 0x0804cfa8 Alloc 28 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] - + 0x00000008 Alloc 33 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] - + 0x0804cee0 Alloc 34 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389] - + 0x0804cf90 Alloc 35 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963] - + 0x0804cfa8 Alloc 36 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] - + 0x00000008 Alloc 41 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] - + 0x0804cee0 Alloc 42 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389] - + 0x0804cf90 Alloc 43 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963] - + 0x0804cfa8 Alloc 44 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] - + 0x00000008 Alloc 49 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] - + 0x0804cee0 Alloc 50 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389] - + 0x0804cf90 Alloc 51 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963] - + 0x0804cfa8 Alloc 52 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] - + 0x00000008 Alloc 57 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] - + 0x0804cee0 Alloc 58 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389] - + 0x0804cf90 Alloc 59 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963] - + 0x0804cfa8 Alloc 60 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] - + 0x00000008 Alloc 65 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] - + 0x0804cee0 Alloc 66 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389] - + 0x0804cf90 Alloc 67 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963] - + 0x0804cfa8 Alloc 68 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] - + 0x00000008 Alloc 73 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] - + 0x0804cee0 Alloc 74 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389] - + 0x0804cf90 Alloc 75 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963] - + 0x0804cfa8 Alloc 76 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] - + 0x00000008 Alloc 81 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] - + 0x0804cee0 Alloc 82 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389] - + 0x0804cf90 Alloc 83 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963] - - 0x0804c8d8 Free 84 was never alloc'd 0x10955fc - - 0x0804c960 Free 87 was never alloc'd 0x115672f - - 0x0804c9b8 Free 88 was never alloc'd 0x1156737 - - Memory not freed: - ----------------- - Address Size Caller - 0x0804cfa8 0x73 at 0x10df0c8 - 0x00000008 0 at 0x10df0c8 - - Perhps because we implement `vfork` in terms of `fork` (`posix/vfork.c`)? - - * `posix/tst-pathconf.out` - - pathconf on directory failed: (os/kern) successful - - * `io/test-lfs.out` - - /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build/io/test-lfs: cannot write test string to large file: Invalid argument - - * `io/tst-futimesat.out` - - file created - futimesat failed - - `futimesat` is a stub. - - * `misc/tst-pselect.o` - - tst-pselect.c: In function 'do_test': - tst-pselect.c:33:17: error: 'SA_NOCLDWAIT' undeclared (first use in this function) - - * `gmon/tst-sprofil.out` - - Floating point exception - - * `nss//libnss_test1.so` - - [...]/nss/nss_test1.os: In function `_nss_test1_getpwent_r': - [...]/nss/nss_test1.c:60: undefined reference to `pthread_mutex_lock' - [...]/nss/nss_test1.c:85: undefined reference to `pthread_mutex_unlock' - - * `rt/tst-shm.out` - - read file outside of SHMDIR directory: (os/kern) successful - - * `rt/tst-timer.out` - - No message. - - * `rt/tst-timer2.o` - - tst-timer2.c: In function 'do_test': - tst-timer2.c:33:23: error: 'SIGRTMIN' undeclared (first use in this function) - - * `rt/tst-aio2`, `rt/tst-aio3`, `rt/tst-aio9`, `rt/tst-aio10`, - `rt/tst-mqueue3`, `rt/tst-mqueue5.o`, `rt/tst-mqueue6`, `rt/tst-mqueue8`, - `rt/tst-timer3`, `rt/tst-timer4.o`, `rt/tst-timer5.o`, `rt/tst-cpuclock2`, - `rt/tst-cputimer1.o`, `rt/tst-cputimer2.o`, `rt/tst-cputimer3.o`, - `elf/tst-thrlock` - - [...]/rt/tst-aio2.o: In function `do_test': - [...]/rt/tst-aio2.c:62: undefined reference to `pthread_barrier_init' - [...]/rt/tst-aio2.c:94: undefined reference to `pthread_barrier_wait' - [...]/rt/tst-aio2.o: In function `thrfct': - [...]/rt/tst-aio2.c:35: undefined reference to `pthread_barrier_wait' - - tst-mqueue5.c: In function 'rtmin_handler': - tst-mqueue5.c:50:14: error: 'SIGRTMIN' undeclared (first use in this function) - - [...]/rt/tst-mqueue6.o: In function `do_test': - [...]/rt/tst-mqueue6.c:127: undefined reference to `pthread_attr_init' - [...]/rt/tst-mqueue6.c:149: undefined reference to `pthread_attr_setguardsize' - [...]/rt/tst-mqueue6.c:211: undefined reference to `pthread_attr_setguardsize' - [...]/rt/tst-mqueue6.c:262: undefined reference to `pthread_attr_destroy' - [...]/rt/tst-mqueue6.c:128: undefined reference to `pthread_attr_setguardsize' - [...]/rt/tst-mqueue6.o: In function `fct': - [...]/rt/tst-mqueue6.c:79: undefined reference to `pthread_self' - [...]/rt/tst-mqueue6.c:79: undefined reference to `pthread_getattr_np' - [...]/rt/tst-mqueue6.c:88: undefined reference to `pthread_attr_getguardsize' - [...]/rt/tst-mqueue6.c:95: undefined reference to `pthread_attr_destroy' - [...]/rt/tst-mqueue6.c:95: undefined reference to `pthread_attr_destroy' - - [...]/elf/tst-thrlock.o: In function `do_test': - [...]/elf/tst-thrlock.c:38: undefined reference to `pthread_create' - [...]/elf/tst-thrlock.c:48: undefined reference to `pthread_join' - - * `rt/tst-aio8.out` - - r = -1, e = 1073741902 (Function not implemented) - - Should work with [[!message-id - "201209302353.51055.toscano.pino@tiscali.it"]] in libpthread. - - * `debug/tst-chk1.out` - - Intermittent. Timeout. Unknown. - - * `debug/tst-chk2.out`, `debug/tst-chk3.out`, `debug/tst-lfschk2.out`, - `debug/tst-lfschk3.out` - - Unknown. - - * `debug/tst-chk4.out`, `debug/tst-chk5.out`, `debug/tst-chk6.out`, - `debug/tst-lfschk4.out`, `debug/tst-lfschk5.out`, `debug/tst-lfschk6.out` - - [...]/debug/tst-chk4: [...]/libc.so.0.3: version `GLIBC_2.13_DEBIAN_31' not found (required by [...]/libstdc++.so.6) - [...]/debug/tst-chk4: [...]/libc.so.0.3: version `GLIBC_2.13_DEBIAN_31' not found (required by [...]/libgcc_s.so.1) - - * `debug/tst-longjmp_chk2.out` - - SIGSEGV. - - not on alternate stack - in signal handler - on alternate stack - out of signal handler - on alternate stack - - It says *alternate stack*. - - * `inet/tst-ether_line.o` - - tst-ether_line.c: In function 'do_test': - tst-ether_line.c:19:19: error: 'ETH_ALEN' undeclared (first use in this function) - - Will either need a `hurd/netinet/if_ether.h` that includes - `<net/if_ether.h>`, or can do that in the generic `netinet/if_ether.h`? - See also [[!sourceware_PR 11142]]. - - * `login/tst-grantpt.out` - - posix_openpt(O_RDWR) failed - errno 1073741902 (Function not implemented) - - `posix_openpt` is a stub. - - grantpt(): expected: return = -1, errno = 1073741846 - got: return = -1, errno = -303 - - `grantpt` (actually `ptsname_r`), does not fail with `ENOTTY` when the `fd` - does not refer to a PTY master. - - * `elf/tst-auxv.out` - - SIGSEGV. - - * `elf/tst-stackguard1-static.out`, `elf/tst-stackguard1.out` - - differences 0 defaults 0 - stack guard canaries are not randomized enough - nor equal to the default canary value - - Sometimes times out. - - * `elf/tst-ptrguard1-static.o`, `elf/tst-ptrguard1.o` - - In file included from tst-ptrguard1-static.c:1:0: - tst-ptrguard1.c: In function 'con': - tst-ptrguard1.c:42:24: error: 'tcbhead_t' has no member named 'pointer_guard' - tst-ptrguard1.c: In function 'do_test': - tst-ptrguard1.c:65:29: error: 'tcbhead_t' has no member named 'pointer_guard' - tst-ptrguard1.c:104:30: error: 'tcbhead_t' has no member named 'pointer_guard' - - See [[t/tls|t/tls]]. - - * `elf/tst-tls9-static.out` - - SIGSEGV. - - * `elf/tst-audit1.out`, `elf/tst-audit2.out`, `elf/tst-audit8.out` - - SIGKILL. - - * `elf/tst-null-argv.out` - - Inconsistency detected by ld.so: ../sysdeps/mach/hurd/dl-sysdep.c: 338: open_file: Assertion `!(flags & ~(0x0001 | 0x00400000))' failed! - - * `elf/check-textrel.out` - - $BUILDDIR/libc.so.dyn: *** text relocations used - - * `elf/check-execstack.out` - - $BUILDDIR/libc.so.phdr: *** executable stack signaled - - * `elf/check-localplt.out` - - Around 500 or so `Extra PLT reference`. - - * `check-local-headers.out` - - A lot. Including `/usr/include/device/*.h`, `/usr/include/mach/*.h`, - `/usr/include/hurd/*.h`. - - * `debug/tst-longjmp_chk2.out`, `debug/tst-longjmp_chk3.out`, - `debug/tst-longjmp_chk4.out`, `debug/tst-longjmp_chk5.out`, - `debug/tst-backtrace2.out`, `debug/tst-backtrace3.out`, - `debug/tst-backtrace4.out`, `debug/tst-backtrace5.out` - `debug/tst-backtrace6.out` - - All say: `Obtained backtrace with 0 functions`. - -Earlier failures; no longer seen: - - * `test-assert-perr.out` - - Fails intermittently. Unknown. - - * `test-multiarch.out` - - Needs [[`/proc/cpuinfo`|hurd/translator/procfs/jkoenig/discussion]] - providing the `flags` line. - - * `elf/tst-array*` - - No longer fail with GCC 4.7. - [[!message-id "50950082.1070906@df1tl.local.here"]]. - - * `io/ftwtest`, `posix/globtest`, `iconvdata/iconv-test`, `intl/tst-gettext`, - `malloc/tst-mtrace`, `elf/tst-pathopt`, `iconvdata/tst-tables`, - `grp/tst_fgetgrent`, - `posix/wordexp-tst`, `localedata/bug-setlocale1.out`, `posix/tst-getconf` - - /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486.O/io/ftwtest: error while loading shared libraries: libmachuser.so.1: cannot open shared object file: No such file or directory - - Looking into `localedata/bug-setlocale1.c`, it is clear what it going on: - only the root of the build directory is added for `--library-path`, but - none of the other directories that are additionally used. This is a bug in - the glibc test harness. Hacked around by `ln -s mach/libmachuser.so.1 - hurd/libhurduser.so.0.3 ./`. Hopefully the other instances are similar. - - * `assert/test-assert.out` - - Fails sometimes... - - * `math/test-fenv.out` - - Used to fail (is listed in Debian eglibc-2.13-21's - `expected-results-i486-gnu-libc`), but something between - 22bcba37dd3b782b1a1ec7bf51da468e48f4d2eb and - 005b7594ffe209639dd1ef2b9ed9a4c22307dec1 causes it to passe -- very likely - Jérémie's signaling work. - - * `elf/tst-unused-dep.out` (1f393a11f65dcaa1952bdcaf0317a65a5f8aff9d, - [[!sourceware_PR 13706]], [[!message-id "4F4210C1.1090704@redhat.com"]]) - - Unused direct dependencies: - /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.6-486/dlfcn/libdl.so.2 - - As of 8958805c11c741d9211e20612c86271d906c9a0b, this test now passes -- - correct? - - * `stdlib/bug-getcontext.out` - - getcontext failed, errno: 1073741902. - - Fixed, implemented in `t/context_functions`. - - * `resource/bug-ulimit1.out` - - Result of ulimit (UL_SETFSIZE, 10000): 0 - Result of ulimit(UL_GETFSIZE): 10000 - - Buggy `sysdeps/unix/bsd/ulimit.c` return values. - - Fixed, [[!message-id "201211182342.51619.toscano.pino@tiscali.it"]]. - -Compared to Debian: - - $ bash ~/tmp/glibc/debian/eglibc-2.13/debian/testsuite-checking/convertlog.sh log_test > log_test.filtered - $ bash ~/tmp/glibc/debian/eglibc-2.13/debian/testsuite-checking/compare.sh ~/tmp/glibc/debian/eglibc-2.13/debian/testsuite-checking/expected-results-i486-gnu-libc log_test.filtered diff --git a/recent_changes.mdwn b/recent_changes.mdwn index 594a0390..8b137891 100644 --- a/recent_changes.mdwn +++ b/recent_changes.mdwn @@ -1,14 +1 @@ -[[!meta copyright="Copyright © 2008 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="Recent Changes"]] - -[[!inline pages="internal(recent_changes/change_*)" template=recentchanges -show=0]] @@ -10,7 +10,7 @@ License|/fdl]]."]]"""]] [[!meta title="UNIX"]] -*UNIX* is a [[kernel]] implementation. +*UNIX* is a [[kernel]] implementation developed in Bell Labs, starting in the 1970's, by a group of programmers including Dennis Ritchie & Ken Thompson. # Concepts diff --git a/user/MutoShack.mdwn b/user/MutoShack.mdwn new file mode 100644 index 00000000..791e3d64 --- /dev/null +++ b/user/MutoShack.mdwn @@ -0,0 +1,3 @@ +I'm Muto. I'm a Free Software user and creator. I love the Hurd & have created this account just in case I decide to edit the wiki. + +You can find my static, JS-free blog at <https://muto.ca> (which contains various contact links if you'd like to talk about the Hurd with me). |