From 47e4d194dc36adfcfd2577fa4630c9fcded005d3 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 27 Oct 2013 19:15:06 +0100 Subject: IRC. --- community/gsoc/2013/nlightnfotis.mdwn | 15 + community/gsoc/project_ideas/object_lookups.mdwn | 63 +++ faq/sata_disk_drives/discussion.mdwn | 18 + glibc/process.mdwn | 2 +- hurd/authentication.mdwn | 226 +++++++++- hurd/console.mdwn | 20 +- hurd/console/discussion.mdwn | 47 ++ hurd/libfuse.mdwn | 19 + hurd/porting/guidelines.mdwn | 20 +- hurd/running/virtualbox.mdwn | 39 +- hurd/subhurd/discussion.mdwn | 34 ++ hurd/translator.mdwn | 1 + hurd/translator/auth.mdwn | 3 +- hurd/translator/discussion.mdwn | 26 +- hurd/translator/ext2fs.mdwn | 38 +- hurd/translator/fifo.mdwn | 6 + hurd/translator/magic.mdwn | 262 ++++++++++- hurd/translator/mtab/discussion.mdwn | 482 ++++++++++++++++++++- hurd/translator/proc.mdwn | 29 ++ hurd/translator/procfs/jkoenig/discussion.mdwn | 82 ++++ hurd/translator/term.mdwn | 207 +++++++++ hurd/translator/tmpfs/discussion.mdwn | 37 ++ microkernel/mach/deficiencies.mdwn | 307 +++++++++++++ microkernel/mach/gnumach/boot_trace.mdwn | 22 + open_issues/64-bit_port.mdwn | 7 + open_issues/anatomy_of_a_hurd_system.mdwn | 8 + open_issues/boehm_gc.mdwn | 19 + open_issues/code_analysis/discussion.mdwn | 56 ++- open_issues/dbus.mdwn | 112 +++++ .../debugging_gnumach_startup_qemu_gdb.mdwn | 34 +- open_issues/emacs.mdwn | 17 +- open_issues/exec_memory_leaks.mdwn | 25 ++ ...t2fs_libports_reference_counting_assertion.mdwn | 13 +- open_issues/gdb_qemu_debugging_gnumach.mdwn | 19 - open_issues/gdb_signal_handler.mdwn | 71 +++ open_issues/git-core-2.mdwn | 107 +++++ open_issues/glibc.mdwn | 319 ++++++++++++++ open_issues/glibc/t/tls-threadvar.mdwn | 37 ++ open_issues/gnumach_page_cache_policy.mdwn | 60 +++ open_issues/hurd_101.mdwn | 38 ++ open_issues/hurd_init.mdwn | 8 + .../libpthread/t/fix_have_kernel_resources.mdwn | 64 +++ open_issues/lsof.mdwn | 40 +- open_issues/mach-defpager_swap.mdwn | 21 + open_issues/multiprocessing.mdwn | 6 +- open_issues/performance.mdwn | 4 +- open_issues/performance/io_system/read-ahead.mdwn | 10 + .../performance/microkernel_multi-server.mdwn | 183 +++++++- open_issues/pthread_atfork.mdwn | 86 ++++ open_issues/smp.mdwn | 8 + open_issues/strict_aliasing.mdwn | 15 +- ..._spin_lock_locked_ss_critical_section_lock.mdwn | 2 + open_issues/time.mdwn | 14 + open_issues/wine.mdwn | 15 +- unix/process.mdwn | 8 +- 55 files changed, 3338 insertions(+), 93 deletions(-) create mode 100644 hurd/translator/term.mdwn delete mode 100644 open_issues/gdb_qemu_debugging_gnumach.mdwn diff --git a/community/gsoc/2013/nlightnfotis.mdwn b/community/gsoc/2013/nlightnfotis.mdwn index a9176f51..83e97bc7 100644 --- a/community/gsoc/2013/nlightnfotis.mdwn +++ b/community/gsoc/2013/nlightnfotis.mdwn @@ -3035,3 +3035,18 @@ But not the [[open_issues/libpthread_dlopen]] issue? and we wanna prove that go violates this rule right? That the stack pointer is not pointing at the initial stack yes + + +# IRC, freenode, #hurd, 2013-10-09 + + braunr: The crash is not in the assembly code, but in the called + function from it: + pthread_sigmask (how=2, set=0xf9cac , + oset=oset@entry=0x0) at ./pthread/pt-sigmask.c:29 + 29 struct __pthread *self = _pthread_self (); + Program received signal SIGSEGV, Segmentation fault. + gnu_srs: ok so, same problem as in gcc go + changing the stack pointer prevents libpthread from correctly + fetching thread-specific data (including _pthread_self()) correctly + this will be fixed when threadvards are finally replaced with true + tls diff --git a/community/gsoc/project_ideas/object_lookups.mdwn b/community/gsoc/project_ideas/object_lookups.mdwn index 88ffc633..ca586dea 100644 --- a/community/gsoc/project_ideas/object_lookups.mdwn +++ b/community/gsoc/project_ideas/object_lookups.mdwn @@ -69,3 +69,66 @@ In context of [[!message-id "20130918081345.GA13789@dalaran.sceen.net"]]. braunr: That's called protected payload. braunr: The idea is that the kernel appends data to the message in flight. + + +## IRC, freenode, #hurd, 2013-10-24 + + 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) + teythoon: that is a big interface change + how so + optimizing libihash and libpthread should already be a good start + well how do you intend to add this information ? + ok, "big" is overstatement, but still, it's a low level interface + change that would probably break a lot of things + store a pointer in the port structure in gnumach, make that + accessible somehow + yes but how ? + interesting question indeed + my plan for x15 is to make this "label" part of received messages + which means you need to change the format of messages + that is what i call a big change + ok, so we need to provide an update path + but once done, the change to hurd will be minimal, patching + libports should cover most of that + normally yes + so this amounts to messing with gnumach and mig and designing a + clever way to make the update process safe + + libihash is known to show high collision rates + right, libihash + it could use an integer hash function on the keys to distribute + them better + i think that's already what it tries to do + so merely using a better hash algorithm such as murmur should do + the job + or use another data structure altogether + no, it does no hashing of its own on the keys + are you sure ? + well, it uses only prime numbers as sizes, and computes key % + size + well that's hashing .. :) + but this is not really a good hash + yes + isn't that what i said ? + right + ok, I didn't get that ;) + also, the sizes start quite small, 3, 7, 19... + and each time the hash table is grown, all items will have to be + updated + which is why we could consider another data structure + or, for starters, to thin out that list of sizes + my personal preference being radix trees + I assume you have an implementation handy? + yes + cool :D + but good hashing is excellent too + radix trees have their own issues + braunr: http://burtleburtle.net/bob/hash/integer.html + i use thomas wang's hashing function in x15 + or rather, my own personal c utility library, since x15 doesn't + hash anything currently + but murmur is better + we prefer distribution over hashing performances + https://131002.net/siphash/ diff --git a/faq/sata_disk_drives/discussion.mdwn b/faq/sata_disk_drives/discussion.mdwn index e9da8560..d05566b6 100644 --- a/faq/sata_disk_drives/discussion.mdwn +++ b/faq/sata_disk_drives/discussion.mdwn @@ -238,3 +238,21 @@ License|/fdl]]."]]"""]] i'll stick with ide for now, but at least setting sata with libvirt was quite easy to do so we can easily switch later + + +## IRC, freenode, #hurd, 2013-10-22 + + youpi: do I need to do anything to enable the ahci driver? + gnumach 1.4 should include it, right? + it should, yes + make sure to put your board in ahci mode, not raid mode + (and not ata mode) + youpi: hm, I will try to do so + youpi: does the driver print anything to the console? + teythoon: yes, AHCI SATA 00:04.0 BAR 0xfebf1000 IRQ 11 + youpi: well, the bios has two modes of operation, 'raid' and + 'ide', I selected 'ide' + ergl + youpi: hm, I think my board has no ahci controller, linux uses + the sata_via module to talk to it :/ + ah :/ diff --git a/glibc/process.mdwn b/glibc/process.mdwn index ded2e1f7..c8a1ce79 100644 --- a/glibc/process.mdwn +++ b/glibc/process.mdwn @@ -13,7 +13,7 @@ The GNU Hurd uses a similar concept to [[UNIX processes|unix/process]]. As a [[Mach task|microkernel/mach/task]] only implements a part of a UNIX process, there is additional work to be done, for example for [[signal]]s, -[[environment_variable]]s, [[file_descriptor]]s. +[[environment_variable]]s, [[file_descriptor]]s, [[hurd/authentication]]. # Startup diff --git a/hurd/authentication.mdwn b/hurd/authentication.mdwn index 2d6084bf..36d18fbb 100644 --- a/hurd/authentication.mdwn +++ b/hurd/authentication.mdwn @@ -1,18 +1,22 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2013 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] -UIDs on the Hurd are separate from processes. A process has +UIDs on the Hurd are separate from [[glibc/process]]es. A process has [[capabilities|capability]] designating so-called UID vectors that are implemented by an [[translator/auth]] server. This makes them easily [[virtualizable|virtualization]]. +The standard POSIX interfaces to a [[glibc/process]]' UID management are +implemented in [[glibc]]. + When a process wishes to gain access to a resource provided by a third party (e.g., a file system) and that party wishes to authenticate the client so as to implement some identity-based access control ([[IBAC]]) policy, @@ -25,3 +29,217 @@ naming a newly authenticated session with the server and the server is delivered the client's designated UID vector. For more details, see section 2.3 of the [[critique]]. + + +# Open Issues + +[[!tag open_issue_hurd]] + + +## IRC, freenode, #hurd, 2013-09-28 + + mhmm + this process has no uid + isn't it a security issue that processes can remove their identity + ? + i really don't like that we allow processes to loose their + identity ... + braunr: y not? I think that's a killer feature + one that is notoriously absent in unices + not exactly + gaining rights to switch your identity is ok + since you have proven that you are allowed to do it + now, if you can remove your identity, you can create "ghost" + processes + processes that can spend their day causing denial of services + without the possibility for the administrator to know who is responsible + the unix "way" of dealing with DoS is to warn and ban users after + they violated the rules + we need to have at least that possibility + perhaps we need to add an "initial" uid + otoh the unix way of dropping privileges is hardly being able to + do so at all ;) + teythoon: ? + on unix, you need privileges to drop your identity :) + i understand it involves security risks, but that's understandable + the thing is, we actually don't care about dropping privileges + we care about gaining them + you cannot drop your identity, you can just use another one + exactly + that's what i want + and the way the hurd does it is superior + let's keep that + processes that should run with least privileges can simply have + their own user/group as it's done on unix + then how do you obtain such a uid/gid? + teythoon: you gain the right, use it to prove who you can be, and + ask an identity switch + identities would then be managed at server side (in proc for + example) + I know how it's done on the Hurd, but who creates them for you? + the password server + well no + the password server gives you the right you need to prove who you + can be + then i'd assume you'd ask the proc server for the switch + but who creates the uid for you in the first place, who sets up + a passwd entry + the administrator ? + what bothers me is that it goes directly against the main goal of + the hurd + indeed + but i think it's a better compromise of freedom/order + I always thought that the ability to drop the unix-like + credentials is really nice + + +### IRC, freenode, #hurd, 2013-09-29 + + braunr: dropping privileges doesn't unregister a process from the + proc server... so it shouldn't be too hard to find out who is + responsible. however, there are more effective ways to create ghost + processes -- a special executable skipping the ordinary bootstrap won't + be registered with proc at all... + however, that would be a non-issue if we had proper resource + accounting + antrik: I do not believe that this is correct. every mach task + will eventually be picked up by the proc server + eventually being next time someone fork(2)s or so + but if noone uses proc_child to claim the new process ones + child, it will not be presented by the proc server as unix process (aiui) + teythoon: not sure what you mean by "pick up" + of course proc will see the process when listing all tasks on the + system; but it will have no additional knowlegde about it + (which is the whole purpose of proc) + + +### IRC, freenode, #hurd, 2013-09-30 + + antrik: proc should be redesigned to fix these issues + in particular, the way that proc lists mach tasks to show them to + the rest of the system is something i find deeply disturbing + hurd processes should be forced to go through proc + braunr: well, if we are talking about fundamentally fixing things, + I believe the central proc server is not a good idea in the first place + :-) + I believe hierarchical management of resource management and + information flow -- cf. nghurd and genode -- is a much better approach + antrik: i agree with hierarchical management of resources, but i + don't see why this prevents a central proc server + i.e. one proc server per hurd instance + + +### IRC, freenode, #hurd, 2013-10-06 + + braunr: hierarchical management of resources doesn't prevent a + central proc server of course; but a central proc server would fit really + ill with hierarchical management of permissions... + + +### IRC, freenode, #hurd, 2013-10-07 + + antrik: does proc manage permissions ? + braunr: well, it manages some permissions... like who is allowed + to send signals + hm... or perhaps proc is not involved in signal delivery itself? + don't remember. but at any rate, proc decides whether it hands out + privileged task ports + antrik: yes, it decides whether or not a client is allowed to + obtain the message port of another task + antrik: but i don't see why this is a problem + what we have now is one proc server per hurd instance + how is that not both central (inside the hurd instance) and + hierarchical with regard to resource management ? + braunr: we are probably talking past each other + all I'm saying is that in an ideal world, there should not be a + central server deciding who is allowed to see and/or control other + processes + antrik: how should it be structured then ? + i mean, how would you see it ? + child processes should be fully controlled by their parent -- + including outside communication + (like in genode AIUI) + isn't that conflicting with the unix design ? + antrik: maybe I'm saying silly stuff since I don't have all the + background, but seems problematic to me with SUID/SGID programs + antrik: in which a child can be more privilegied than the parent + kilobug: that's part of my question too + and it's even "worse" with Hurd's addauth in which any process + can be given additional rights in runtime, but not its parent + braunr: one of the conclusions from ngHurd was that suid as such + is problematic. it makes more sense to have privileged services actually + run by the privileged user, and only requested by the unprivileged one + using RPC + admittedly, I'm not sure how this interacts with UNIX + compatibility ;-) + kilobug: in the genode approach, the parent would control that as + well + in unix, the idea of parent processes doesn't imply much + parents merely exist to reap resources from their children + and as templates when forking + yeah, but that's one of the major shortcomings of UNIX in my + book... + sure + i'm just thinking out loud + if we want to maintain posix compatibility, it seems reasonable to + keep it that way + despite the shortcomings + does that imply a centralized proc server anyway ? + I suspect we could similate suid in the hierarchical design, only + that the resources would be accounted to the user under whose ID the + process runs, rather than to the one who invoked it + i also have a hard time seeing what the completely hierarchical + model brings compared to what the hurd does (isolating system instances) + and I don't think we need a central proc server. it could probably + be done similar to the VFS: each process implements the interfaces, + passing on to the children as appropriate + braunr: it's much easier to isolate parts of the system for + security and/or customisation + that's actually one of the things discussed in the "critique" + IIRC... + i'm not sure + anyway, processes implementing the interface looks bad to me + that's already a problem with the current hurd + using normal client processes as servers means we rely on them to + behave nicely + you have a point there: while untrusted filesystems can be ignored + easily, ignoring untrusted proc providers would be problematic... + (I don't think it's strictly necessary to know about other user's + processes; but we could hardly keep a UNIX feel without it...) + other users' + i feel the hierarchical model may imply some unnecessary burden + capabilities along with resource containers look much more + flexible + and not less secure + children would share the same container as their parent by + default, unless they obtain the right to use another or create their own + braunr: decoupling control from resource ownership is *always* + problematic. that's pretty much the major takeaway from ngHurd + discussions (and the major reason why Coyotos was abandoned as a base for + ngHurd) + if a process runs on your resources, you should have full control + over it. anything else faciliates DRM & Co. + antrik: i see + nonetheless, i don't see the point of that restriction, since the + simplest way to avoid drms in the first place is not using them + and that restriction makes posix compatibility hard to provide + I'm not sure it's really all that hard... + IIRC genode is aiming at POSIX compatibility + I'm not sure it's any harder than with the current Hurd + architecture + i didn't see anything like that + they provide posix compatibility by running legacy systems on top + of it + well, namely linux + hm... they have some UNIX compatibility at least... perhaps not + aiming at full POSIX. don't remember the details + Linux on genode? that's news to me... I know they do run genode on + Linux + anyway, i'll probably stick with the close unix approach for x15 + http://genode.org/documentation/general-overview/ + In an preliminary study, a user-level version of the Linux kernel + (L4Linux) was successfully ported to the Genode OS Framework running on a + L4 kernel. This study suggests that Genode combined with an appropriate + kernel or hypervisor is suited as a virtual-machine hosting platform. + hm... that's boring though ;-) + isn't it :) diff --git a/hurd/console.mdwn b/hurd/console.mdwn index 55581870..10c74bf9 100644 --- a/hurd/console.mdwn +++ b/hurd/console.mdwn @@ -1,5 +1,5 @@ [[!meta copyright="Copyright © 2002, 2003, 2004, 2005, 2006, 2007, 2009, 2011, -2012 Free Software Foundation, Inc."]] +2012, 2013 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -37,8 +37,8 @@ where the numbered nodes represent virtual consoles and their contents are all alike. As the following graph shows, the console, input and display nodes are the -interfaces used by the terminal server, input driver and display drivers -respectively. +interfaces used by the [[terminal server|translator/term]], input driver and +display drivers respectively. +------------------+ +-----------------+ | Input driver | | Terminal Server | @@ -67,7 +67,8 @@ respectively. +----------------+ +-----------------+ The input driver takes scancodes from the in-kernel kbd queue, translates them -into characters and writes them to the input node. Then the terminal server +into characters and writes them to the input node. Then the [[terminal +server|translator/term]] reads the console node taking the characters out of the console server. Each of theese actions is actually an RPC handled by the translator on @@ -110,7 +111,8 @@ Additional information about the console can be found in the [Hurd Console Tutor **_The new Hurd console features:_** -**A console server**, which provides a number of virtual consoles to term servers, with a full set of terminal capabilities. +**A console server**, which provides a number of virtual consoles to [[term +servers|translator/term]], with a full set of terminal capabilities. The console server supports any encoding supported by iconv, but uses Unicode internally. The default encoding is ISO8859-1, another useful variant is UTF-8. @@ -307,7 +309,13 @@ If you use mutt, install `mutt-utf8` package. For lynx, edit `/etc/lynx.cfg`, ma If you use other applications, try to search with google for "application-name utf8" or "application-name unicode". Often you find what you need. The issues are the same for the GNU/Hurd and GNU/Linux systems, so most of the information can be shared, except how to setup the system console to support Unicode, of course. -The `console-server` watches for new hurdio terms (devices translated with `/hurd/term`) and adds them to `/dev/vcs` automatically. What this means is, if you create a new tty with `MAKEDEV`, and then attach something to it, it will now appear in `/dev/vcs`. When a term is disconnected from, it disappears from `/dev/vcs`. `/libexec/getty` is what is usually attached to a term. You can see this automatic adding and removing of terms from the `console-server` by typing the following: +The `console-server` watches for new [[hurdio terms (devices translated with +`/hurd/term`)|translator/term]] and adds them to `/dev/vcs` automatically. +What this means is, if you create a new tty with `MAKEDEV`, and then attach +something to it, it will now appear in `/dev/vcs`. When a term is disconnected +from, it disappears from `/dev/vcs`. `/libexec/getty` is what is usually +attached to a term. You can see this automatic adding and removing of terms +from the `console-server` by typing the following: # cd /dev # ls vcs/ diff --git a/hurd/console/discussion.mdwn b/hurd/console/discussion.mdwn index 0022ec23..73d605ed 100644 --- a/hurd/console/discussion.mdwn +++ b/hurd/console/discussion.mdwn @@ -48,3 +48,50 @@ License|/fdl]]."]]"""]] http://xkbcommon.org/ ‘¡û sounds interesting for our console translator + + +# IRC, freenode, #hurd, 2013-10-01 + +[[!tag open_issue_hurd]] + + teythoon_: df: `/dev/cons': Operation not supported + missing/stub implementation in the console translator? + + +## IRC, freenode, #hurd, 2013-10-02 + + pinotree: yes, df does file_statfs which fails + + +# IRC, freenode, #hurd, 2013-10-22 + + hello hurders! I happened to watch samuel's gnu hackers talk and + wanted to start to use the hurd more regularily. However I noticed that + when I use the preinstalled image, there seems to be some issue with the + console driver + when I start emacs the mode line is drawn 3 times above the bottom + of the screen + is this know or did I miss a step in setting it up? Or should I + use the debian installer and start from scratch again? + C-Keen: it's probably unknown, and not an issue on your side. Did + you try to upgrade to the latest packages? + youpi: doing that now + my base image is debian-hurd-20130504.img + still an issue with the latest packages indeed + it seems emacs and the hurd console don't agree on the number of + lines... + C-Keen: you can set TERM=vt100 to work around the issue + ah alright. + or TERM=linux + youpi: can you start the emacs in X? I get an empty window here + I never tried + I never use emacs :) + I see ;) + it seems there's a bug in cud1 indeed + what's cud1? + see man 5 terminfo + yes it's a terminfo problem + the hurd console isn't well defined there + braunr: actually it seems like a bug in emacs + cud may or may not scroll the screen, depending on the + implementation diff --git a/hurd/libfuse.mdwn b/hurd/libfuse.mdwn index 78e96022..28125dd9 100644 --- a/hurd/libfuse.mdwn +++ b/hurd/libfuse.mdwn @@ -49,6 +49,25 @@ etc. and they could almost readily use our libfuse version +## IRC, freenode, #hurd, 2013-10-01 + + our libfuse implementation is still basic atm (there's a wiki + page about it) + okay... talk to me about FUSE + even with the improvements i have in my public branch, it still + cannot do real-world fs'es + okay, so you're the person to ask about FUSE + it strikes me that HURD not having FUSE support is a bit of an + architectural oversight + i'm not sure what's your point about fuse, since what fuse on + linux (and not only) does is done *natively* by the hurd + exactly + all of the hurd filesystems (which are just a type of servers) + run in userspace already + so FUSE should Just Work + well no + + # Source [[source_repositories/incubator]], libfuse/master. diff --git a/hurd/porting/guidelines.mdwn b/hurd/porting/guidelines.mdwn index d28a777e..a9acd9f9 100644 --- a/hurd/porting/guidelines.mdwn +++ b/hurd/porting/guidelines.mdwn @@ -1,5 +1,5 @@ [[!meta copyright="Copyright © 2002, 2003, 2005, 2007, 2008, 2009, 2010, 2011, -2012 Free Software Foundation, Inc."]] +2012, 2013 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -83,6 +83,24 @@ because else *-gnu* would catch i386-pc-linux-gnu for instance... Note: some of such statements are not from the source package itself, but from aclocal.m4 which is actually from libtool. In such case, the package simply needs to be re-libtoolize-d. + +## Preprocessor Define + +### IRC, freenode, #hurd, 2013-10-23 + + Is there a preprocessor define gcc sets for hurd which I can check + in my code? + __GNU__ + glibc sets it if i'm right + I also see that __MACH__ gets set + that's also set on Mac OS X + right, which uncovered a bug in the code + the microkernel doesn't always implies what operating system runs + on top of it + braunr: but __GNU__ is the correct define for hurd specific code? + yes + + ## Undefined `bits/confname.h` macros (`PIPE_BUF`, ...) If macro `XXX` is undefined, but macro `_SC_XXX` or `_PC_XXX` is defined in `bits/confname.h`, you probably need to use `sysconf`, `pathconf` or `fpathconf` to obtain it dynamicaly. diff --git a/hurd/running/virtualbox.mdwn b/hurd/running/virtualbox.mdwn index 822f771d..23a0b156 100644 --- a/hurd/running/virtualbox.mdwn +++ b/hurd/running/virtualbox.mdwn @@ -40,7 +40,44 @@ To convert the image you need the VirtualBox package properly installed with a V If [[QEMU with KVM|qemu]] is not available, VirtualBox reportedly has better performance. -IRC, freenode, #hurd, 2011-10-31: + +# Open Issues + +## IRC, freenode, #hurd, 2011-10-31 I don't know what virtualbox does with hardware emulation, but gnumach is awfully slow to probe things there + + +## IRC, freenode, #hurd, 2013-09-28 + + the problem is if i giveit more than 1855 it says truncating to + that + so i give it that.. then it has kmem alloc error + 1536mb same.. 1024 isok + hum + that's weird + virtual box ? + yeah + i wonder what cpu features i should enable/disable + pae ? + make sure vbox doesn't count on the so called memory balloon + pae isn't used except on xen + disable apic + enable host io cache in disk controllers + do we have these written on the wiki? + no because i didn't run into these problems + but since i know the system well enough to avoid them in the first + place .. + we need real users to report them + i'm not sure we have anything about vbox in the wiki actually + ./hurd/running/virtualbox.mdwn + we seem to have a page at least + it seems to be okay with 1024MiB + still weird + looks more random than buggy with more memory + do you have the exact error message you got during your previous + attempts ? + no.. i should have taken a screenshot.. its easy enough to + reproduce though + i'll wait until after its installed diff --git a/hurd/subhurd/discussion.mdwn b/hurd/subhurd/discussion.mdwn index fac93625..892387ef 100644 --- a/hurd/subhurd/discussion.mdwn +++ b/hurd/subhurd/discussion.mdwn @@ -180,3 +180,37 @@ License|/fdl]]."]]"""]] safer perhaps more powerful too, but that entirely depends on the features you want inside + + +# IRC, freenode, #hurd, 2013-10-04 + + hm, looks like we broke subhurds again + freezes after starting exec + o_O + looks like some translator refuses to start + teythoon: we need better error reporting first :) + +[[open_issues/subhurd_error_messages]]. + + and better visibility in general + teythoon: it may be that the subhurd i'm using is a bit od + old + one weird thing about subhurds is that they actually use the + ext2fs and linker from the host + so it's better if the subhurd and the host uses the same bootstrap + protocol :) + braunr: isn't boot --boot-root=DIR there to specify which root + translator and linker to use? + teythoon: yes but you don't want your root file system mounted + from the host when starting your subhurd + you can mount it r/o just fine, no? + ideally, we'd have a userspace version of grub reading the files + from the disk, as it's done when booting + hm + right + + +## IRC, freenode, #hurd, 2013-10-07 + + braunr: btw, did you straighten out your subhurd issue? + teythoon: no i haven't diff --git a/hurd/translator.mdwn b/hurd/translator.mdwn index 52cd09f7..32562a8b 100644 --- a/hurd/translator.mdwn +++ b/hurd/translator.mdwn @@ -106,6 +106,7 @@ The [[concept|concepts]] of translators creates its own problems, too: * [[symlink]] * [[firmlink]] * [[fifo]] +* [[term]] * ... diff --git a/hurd/translator/auth.mdwn b/hurd/translator/auth.mdwn index 7fd4832c..10cfb3aa 100644 --- a/hurd/translator/auth.mdwn +++ b/hurd/translator/auth.mdwn @@ -8,7 +8,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]]."]]"""]] -The *auth server* (or, *authentification server*). +The *auth server* (or, *authentification server*) is a key component managing +[[authentication]] in a Hurd system. It is stated by `/hurd/init`. diff --git a/hurd/translator/discussion.mdwn b/hurd/translator/discussion.mdwn index e038ba84..95f5ab0c 100644 --- a/hurd/translator/discussion.mdwn +++ b/hurd/translator/discussion.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011, 2013 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -10,7 +10,8 @@ License|/fdl]]."]]"""]] [[!tag open_issue_documentation open_issue_hurd]] -IRC, freenode, #hurd, 2011-08-25: + +# IRC, freenode, #hurd, 2011-08-25 < frhodes> how can I replace an existing running server with a new one without rebooting? @@ -23,3 +24,24 @@ IRC, freenode, #hurd, 2011-08-25: nature < antrik> in some cases, you might even be able simply to remove the old translator... but obviously only for non-critical stuff :-) + + +# IRC, freenode, #hurd, 2013-10-21 + + mhmm, there is a problem with thread destruction + +[[open_issues/libpthread/t/fix_have_kernel_resources]]. + + actually, translator self destruction + if a request arrives after the last thread servicing a port set + returns from mach_msg because of a timeout, but before the translator is + detached from its parent, the client will get an error + it should very rarely happen, but if it does, we could face the + same kind of issues we have when a server crashes + e.g. sshd looping over select() returning EBADF, consuming all cpu + not sure we want to introduce such new issues + + i don't think i'll be able to make translators disappear reliably + .. + but at least, thread consumption will correctly decrease with + inactivity diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn index e2f6b044..cfd09502 100644 --- a/hurd/translator/ext2fs.mdwn +++ b/hurd/translator/ext2fs.mdwn @@ -163,6 +163,11 @@ small backend stores, like floppy devices. ok +#### IRC, freenode, #hurd, 2013-10-08 + + ogi: your ext2fs patches were finally merged upstream :) + + ## Sync Interval [[!tag open_issue_hurd]] @@ -209,39 +214,6 @@ That would be a nice improvement, but only after writeback throttling is impleme tschwinge: well, thanks anyway ;) -## Increased Memory Consumption - -### IRC, freenode, #hurd, 2013-09-18 - - ext2fs is using a ginormous amount of memory on darnassus since i - last updated the hurd package :/ - i wonder if my ext2fs large store patches rework have introduced a - regression - the order of magnitude here is around 1.5G virtual space :/ - it used to take up to 3 times less before that - looks like my patches didn't make it into the latest hurd package - teythoon: looks like there definitely is a new leak in ext2fs - :/ - memory only - the number of ports looks stable relative to file system usage - braunr: I tested my patches on my development machine, it's up - for 14 days (yay libvirt :) and never encountered problems like this - i've been building glibc to reach that state - hm, that's a heavy load indeed - could be the file name tracking stuff, I tried to make sure that - everything is freed, but I might have missed something - teythoon: simply running htop run shows a slight, regular increase - in physical memory usage in ext2fs - old procfs stikes again? :) - braunr: I see that as well... curious... - 16:46 < teythoon> could be the file name tracking stuff, I tried - to make sure that everything is freed, but I might have missed something - how knows, maybe completely unrelated - the tracking patch isn't that big, I've gone over it twice today - and it still seems reasonable to me - hm - - # Documentation * diff --git a/hurd/translator/fifo.mdwn b/hurd/translator/fifo.mdwn index 857922fc..4132e94a 100644 --- a/hurd/translator/fifo.mdwn +++ b/hurd/translator/fifo.mdwn @@ -46,3 +46,9 @@ The *fifo* translator implements named pipes (FIFOs). gg0: got an example? http://bugs.debian.org/629184 i didn't close it myself + + +## IRC, OFTC, #debian-hurd, 2013-10-04 + + there is new-fifo, which you can try + i guess none of us know what it was really meant for diff --git a/hurd/translator/magic.mdwn b/hurd/translator/magic.mdwn index 84bacdfb..2b0d1bf7 100644 --- a/hurd/translator/magic.mdwn +++ b/hurd/translator/magic.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2006, 2007, 2008, 2010 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2006, 2007, 2008, 2010, 2013 Free Software +Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -9,7 +9,13 @@ 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 magic translator provides `/dev/fd`. +The `magic` translator returns magic retry results, which are then resolved by +[[glibc]]'s *name lookup* routines. + +[[!toc]] + + +# `/dev/fd`. $ showtrans /dev/fd /hurd/magic --directory fd @@ -20,3 +26,253 @@ individually like this: $ ls -l /dev/fd/0 crw--w---- 1 bing tty 0, 0 Nov 19 18:00 /dev/fd/0 + + +# `/dev/tty` + + $ showtrans /dev/tty + /hurd/magic tty + + +## Open Issues + +### IRC, OFTC, #debian-hurd, 2013-06-18 + + http://www.zsh.org/mla/workers/2013/msg00547.html + + +#### IRC, OFTC, #debian-hurd, 2013-06-19 + + youpi: http://www.zsh.org/mla/workers/2013/msg00548.html -- Is + that realistic? If yes, can someone of you test it? I though would expect + that if /dev/tty exists everywhere, it's a chardev everywhere, too. + that's not impossible indeed + I've noted it on my TODO list + + +#### IRC, OFTC, #debian-hurd, 2013-06-20 + + youpi: wrt the /dev/tty existance, + https://buildd.debian.org/status/fetch.php?pkg=mksh&arch=hurd-i386&ver=46-2&stamp=1371553966 + For the build logs, demonstrate that /dev/null and /dev/tty + exist: + ls: cannot access /dev/tty: No such device or address + uh?! + ah, ENODEV + so that's what we was thinking, no tty -> no /dev/tty + + +#### IRC, OFTC, #debian-hurd, 2013-09-20 + + Hi. zsh still FTBFS on Hurd due to some test failure: + https://buildd.debian.org/status/package.php?p=zsh -- IIRC I checked last + time on some porterbox and couldn't reproduce the failure there. Any + insight if /dev/tty is not accessible on the buildds inside the chroot? + Or is it no character device there? I checked on strauss and there it is + a character device. + My only other option to debug this (didn't think of that yesterday + before the upload unfortunately) would be to override dh_auto_test with + "ls -l /dev/tty; dh_auto_test". Do you think that would be helpful? + i see /dev/tty on exodar, in the root system and in the chroot + pinotree: And it is a character device? + ... in both cases? + crw--w---- 1 pino tty 0, 0 Sep 20 10:20 /dev/tty + yes + pinotree: Hrm. + (/dev in the chroot is a firmlink to the system /dev, iirc) + pinotree: What is a firmlink? :) + pinotree: /dev/tty belongs to your user in the example above. + something between a (sym)link and an union mount + pinotree: Is it possible that /dev/tty is not visible if the + buildd runs without a connected terminal? + that i'm not sure + I see. + wouldn't it be possible to skip only that check, instead of the + whole test suite? + maybe something like + tty=$(find /dev/ -name 'tty*' -type c -print) + if [[ -n $tty ]]; then / [[ -c $tty[(f)1] && ! -c $zerolength ]] + / else / print -u$ZTST_fd 'Warning: Not testing [[ -c tty ]] (no tty + found)' / [[ ! -c $zerolength ]] / fi + (never used zsh, so please excuse me if i wrote something silly + above) + re + pinotree: Yeah, sure. That would be one way to get the thing + building again, if that's really the cause. + i guess it would find any of the available tty* devices + it does that for block devices, why not with tty devices, after + all? :) + pinotree: I just wonder if the failing test is because the test + doesn't work properly on that architecture or because it indicates that + there is a bug in zsh which only is present on hurd. + wouldn't the change proposed above help in determining it? + If I'm sure that it's a broken test, I'll try to disable that + one. If not I'd report (more details) to upstream. :) + pinotree: Oh, indeed. + if you get no warning, then a tty device was found with find + (using its -type c option), so the failing condition would be a zsh (or + maybe something in the stack below) bug + with the warning, somehow there were no tty devices available, + hence nothing to test -c with + So basically doing a check with dash to see if we should run the + zsh test. + dash? + Well, whatever /bin/sh points to. :) + ah, do you mean because of $(find ...)? + Ah, right, -type c is from find not /bin/sh + pinotree: That's my try: + http://anonscm.debian.org/gitweb/?p=collab-maint/zsh.git;a=commitdiff;h=ba5c7320d4876deb14dba60584fcdf5d5774e13b + o_O + isn't that a bit... overcomplicated? + pinotree: Yeah, it's a little bit more complicated as the tests + itself are not pure shell code but some format on their own. + why not the "thing" i wrote earlier? + pinotree: Actually it is what I understand you wanted to do, just + with more debug output. Or I dunderstood + pinotree: Actually it is what I understand you wanted to do, just + with more debug output. Or I understood your thing wrongly. + tty=$(find /dev/ -name 'tty*' -type c -print) + if [[ -n $tty ]]; then / [[ -c $tty[(f)1] && ! -c + $zerolength ]] / else / print -u$ZTST_fd 'Warning: Not testing [[ -c tty + ]] (no tty found)' / [[ ! -c $zerolength ]] / fi + pinotree: Yeah, I know. + that is, putting these lines instead of the current two + tty=/dev/tty + following + imho that should be fit for upstream + pinotree: You mean inside C02cond.ztst? + yep + pinotree: No, IMHO that's a bad idea. + why? + pinotree: That file is to test the freshly compiled zsh. I can't + rely on their code if I'm testing it. + uh? + the test above for -b is basically doing the same + pinotree: Indeed. Hrm. + that's where i did c&p most of it :) + So upstream relies on -n in the testsuite before it has tested it? + Ugly. + if upstream does it, why cannot i too? :D + pinotree: You've got a point there. + Ok, rethinking. :) + otoh you could just move the testcase for -n up to that file, so + after that you know it works already + pinotree: Well, if so, upstream should do that, not me. :) + you could suggest them to, given the -n usage in the -b testcase + pinotree: Looks alphabetically sorted, so I guess that's at least + not accidentially. + pinotree: Ok, you've convinced me. :) + :D + Especially because this is upstream-suitable once it proved to fix + the Hurd FTBFS. :) + pinotree: The previous upstream code (laast change 2001) instead + of the hardcoded /dev/tty was btw "char=(/dev/tty*([1]))", so I suspect + that the find may work on Cygwin, too. + s/aa/a/ + ah, so that's that comment about globbing on cygwin was + referring to + Yep + cool, so incidentally i've solved also that small issue :9 + :) + pinotree: I hope so. :) + Then again, I hope, external commands like find are fine for + upstream. + then they should rework the already existing testcases ;) + pinotree: Ah, I fall again for the same assumptions. :) + Seems as I would really build test suites with a different + approach. :) + nothing bad in that, i'd say + I'd try to make the tests as far as possible independent from + other tools or features to be sure to test only the stuff I want to test. + Warning: Not testing [[ -c tty ]] (no tty found) + Interesting. I didn't expect that outside a chroot. :) + where's that? + pinotree: A plain "debuild on my Sid VM. + ah + Linux, amd64 + (and Debian of course ;-) + pinotree: Ah, my fault, I kept upstreams char= but didn't change + it in your code. :) + hehe + pinotree: Will be included in the next zsh upload. But I don't + want to upload a new package before the current one moved to testing (or + got an RC bug report to fix :-) + oh sure, that's fine + pinotree: + http://anonscm.debian.org/gitweb/?p=collab-maint/zsh.git;a=commitdiff;h=22bc9278997a8172766538a2ec6613524df03742 + (I've reverted my previous commit) + \o/ + + +#### IRC, OFTC, #debian-hurd, 2013-09-30 + + Anyone knows why the building of zsh on ironforge restarted? It + was at something like "building 4h20m" when I looked last and it now is + at "building 1h17m" but there's no old or last log, so it does still look + like the first build. + most probably got stuck + Oh, ok. + pinotree: So there are cases where the log is not kept? + looks so + when the machine crashes, yes :) + youpi: Ooops. Was that me? + no, I just rebooted the box + I didn't easily find which process to kill + Ok. Then I'll check back tomorrow morning if pinotree's fix for + zsh's test suite on hurd worked. :) + it seems to be hung on + /build/buildd-zsh_5.0.2-5-hurd-i386-vO9pnz/zsh-5.0.2/obj/Test/../Src/zsh + ../Src/zsh ../../Test/ztst.zsh ../../Test/Y02compmatch.ztst + :( + At least pinotree's patch worked as it then likely passed + C02cond.ztst. :) + youpi: For how long? There are multiple tests which take at least + 3 seconds per subtest. + one hour already + Ok. + That's far too long + + +#### IRC, OFTC, #debian-hurd, 2013-10-01 + + pinotree: I've just checked + https://buildd.debian.org/status/fetch.php?pkg=zsh&arch=hurd-i386&ver=5.0.2-5&stamp=1380608100 + manually: Your fix unfortunately seemed not to help, but another test + failed, too, and that one came later and was hence suspected as primary + failing issue. + pinotree: But "+ find: `/dev/tty': No such device or address" + gives some hint. I just have no idea, why find issues that message. + * XTaran really wonders how that message can be caused. + So find sees /dev/tty, but gets an error if it tries to access + (maybe only stat) it while not being connected to a terminal. + Bingo: This reproduces the issue (note the missing -t option to + ssh): ssh exodar.debian.net "find /dev/ -nowarn -maxdepth 1 -name 'tty*' + -type c -ls" + Even clearer: $ ssh exodar.debian.net "ls -l /dev/" | grep 'tty$' + ls: cannot access /dev/tty: No such device or address + ?????????? ? ? ? ? ? tty + I'd say this is a bug somewhere deep down, either in libc or the + kernel. + or in the console translator + pinotree: Never heard of that so far. :) + pinotree: Someone from zsh upstream suggests to use /dev/null or + /dev/zero instead of /dev/tty* -- will try that for the next upload. + ah right, /dev/null should be standard POSIX + I hope so. :) + http://pubs.opengroup.org/onlinepubs/9699919799/ check in POSIX + in any case, sorry for the troubles it is giving you... + pinotree: I'm more concerned about the hanging second test. I + think I can get that test working with using /dev/null. + Now that I've understood why the original test is failing. + pinotree: Shall I write a bug report for that issue? If so, + against which package? + XTaran: not sure it is worth at this stage, having a clearer + situation on what happens could be useful + it is something that can happen sporadically, though + pinotree: Well, it seems a definitely unwanted inconsistency + between what the directory listing shows and which (pseudo) files are + accessible. Independently of where the bug resides, this needs to be + fixed IMHO. + sure, nobody denies that + pinotree: I'd call it easily reproducible. :) + not really + ... once you know where to look for. diff --git a/hurd/translator/mtab/discussion.mdwn b/hurd/translator/mtab/discussion.mdwn index 0734e1e6..973fb938 100644 --- a/hurd/translator/mtab/discussion.mdwn +++ b/hurd/translator/mtab/discussion.mdwn @@ -2103,7 +2103,245 @@ In context of [[open_issues/mig_portable_rpc_declarations]]. anyway, got to run -## IRC, freenode, #hurd, 2013-09-20 +## Memory Leak + +### IRC, freenode, #hurd, 2013-09-18 + + ext2fs is using a ginormous amount of memory on darnassus since i + last updated the hurd package :/ + i wonder if my ext2fs large store patches rework have introduced a + regression + the order of magnitude here is around 1.5G virtual space :/ + it used to take up to 3 times less before that + looks like my patches didn't make it into the latest hurd package + teythoon: looks like there definitely is a new leak in ext2fs + :/ + memory only + the number of ports looks stable relative to file system usage + braunr: I tested my patches on my development machine, it's up + for 14 days (yay libvirt :) and never encountered problems like this + i've been building glibc to reach that state + hm, that's a heavy load indeed + could be the file name tracking stuff, I tried to make sure that + everything is freed, but I might have missed something + teythoon: simply running htop run shows a slight, regular increase + in physical memory usage in ext2fs + old procfs stikes again? :) + braunr: I see that as well... curious... + 16:46 < teythoon> could be the file name tracking stuff, I tried + to make sure that everything is freed, but I might have missed something + how knows, maybe completely unrelated + the tracking patch isn't that big, I've gone over it twice today + and it still seems reasonable to me + hm + + +### IRC, freenode, #hurd, 2013-09-25 + + seems like a small leak per file access + but htop makes it obvious because it makes lots of them + shouldn't be too hard to find + since it might also come from the large store patch, i'll take a + look at it + + +### IRC, freenode, #hurd, 2013-09-27 + + teythoon: found the leak :) + although its origin is weird + braunr: where is it? + i'm still building packages to make sure that's it + see + http://darnassus.sceen.net/gitweb/savannah_mirror/hurd.git/blob/HEAD:/libdiskfs/dir-lookup.c + which you changed in + http://darnassus.sceen.net/gitweb/savannah_mirror/hurd.git/commit/06d49cdadd9e96361f3fe49b9c940b88bb869284 + line 306 is "return error" instead of "goto out" + has been so since 1994 + what is unclear is why this code path is now run + patch is here: + http://darnassus.sceen.net/~rbraun/0001-Fix-memory-leak-in-libdiskfs.patch + I see, weird indeed + teythoon: the system also feels slower somehow + such errors might have introduced unexpected retries + i think it's possible to write a coccinelle patch to find such + errors + + +### IRC, freenode, #hurd, 2013-09-28 + + braunr: bah, I havent noticed the leak on my box, even after + building eglibc & hurd several times + that's weird + are you sure it's up to date ? + also, is procfs correctly attached to /proc ? + that's what seems to trigger it + yes, 20130924-2, with procfs on /proc + + braunr: that turned out to be the leak indeed? and somehow my + changes triggered it? did you discover why? + teythoon: yes, yes, no + but youpi didn't see the leak on his system + ^^ cool that you found it + I did + oh yes you mean you saw the leak + yes + + +### IRC, freenode, #hurd, 2013-10-01 + + the fix i did in libdiskfs might have fixed other issues + apparently, it's the code path taken when error isn't ENOENT, + including no error (translator started) + the memory leak fix, you mean? + yes + it might haved fixed reference counting too + although i'm not sure if we actually ever run into that issue in + the past + the weird thing is, that path is taken when starting a passive + translator + (i think) + (it might be any kind of translator, and just doing nothing if + alcready active) + already* + anyway, the fact that the leak was so visible means this code was + run very often + which doesn't make sense + hm ok, it seems that code was run every time actually + but the leak became visible when it concerned memory + which side-effects did the old code produce? + teythoon added a dynamically allocated path that wasn't freed + reference leaks + which might explain the assertion on reference we sometimes see + with ext2fs + when a counter overflows and becomes 0 + +[[open_issues/ext2fs_libports_reference_counting_assertion]]? + + hmm + which is why i'm mentioning it + :) + i'll try to reproduce the assertion + libdiskfs/node-drop.c: assert (np->dn_stat.st_size == 0); ← + this one? + yes + hm no + oho + no, not that one + no-oho + well maybe by side effect + but i doubt it + iirc you constantly get that when building ustr + (e.g., because the object was freed and reallocated quickly, + st_size has been reset, something like that) + is ustr a package ? + yes + ok + thanks + pinotree: indeed, it's still present + pinotree: actually, after a more in-depth look, reference counting + looks valid before the fix too + ok, thanks for checking + pinotree: the assertion affects the root translator, and is + triggered by a test that stresses memory + memory as in ram, or as in disk storage? + malloc + ok + i suspect the code doesn't handle memory failure well + iirc the ustr tests are mostly disk-intensive + this one is really about enonmem + enomem + i'll make ext2fs print a stack trace + (might be wrong, but did not investigate further, sorry) + no worries + i'm doing it now :) + + +### IRC, freenode, #hurd, 2013-10-02 + + i've traced the problem up to truncate + which gets a negative size + shouldn't take long to find out where it comes from now + it seems our truncate doesn't handle negative values well though + EINVAL The argument length is negative or larger than the + maximum file size. + i still have to see whether it comes from the user (unlikely) or + if it's an internal inconsistency + i suspect some code wrongly handles vm_map failures + leading to that inconsistency + pinotree: looks like glibc doesn't check for length >= 0 + yeah + servers should do it nonetheless + should we fix glibc, libdiskfs/libnetfs/libtrivfs/etc, or both? + it appears a client does the truncate + i'd say both + can you take the glibc part ? :) + i was going to do the hurd part... :p + ok, i'll pick libc + well i'm doing it already + i want to write a test case first + to make sure that's the problem + already on the hurd part, you mean? + yes + ok + ok looks like it + would you share the test you are doing, so i don't need to write + it again? :) + * pinotree lazy + :) + as soon as darnassus is restarted + ideally we could have some repository with all the testcases + written over time to fix bugs in implementations/compatibility/etc + i noticed the system doesn't automatically reboot when e2fsck says + reboot, and no unexpected inconsistency was found + is that normal ? + or having something like posixtestsuite, but actively maintained + pinotree: polishing the test before sending it + sure, no hurry :) + i can't reproduce the assertion but it does make ext2fs freeze + pinotree: http://darnassus.sceen.net/~rbraun/test_ftruncate.c + merci + pinotree: ustr builds + wow + the client code (ustr) seems to perform a ftruncate with size + ((size_t)-1) whereas lengths are signed .. + i'll check other libraries and send a patch soon + + braunr: btw, did you fix the leak? + yes + + http://darnassus.sceen.net/gitweb/savannah_mirror/hurd.git/commit/a81c0c28ea606b0d0a2ad5eeb74071c746b7cdeb + 1h after tagging 0.5 ( + :( + ah yes, I've seen that commit + I just wanted to know whether this settled the issue + it does :) + good + i still can't figure out why youpi didn't had it + the code path is run when no error (actually error != ENOENT) + which explains why the leak was so visible + so my patch exposed this b/c of the allocation I added, makes + sense + it's funny actually, b/c this wasn't an issue for me as well, I + had my development vm running on that patches for two weeks + + +### IRC, freenode, #hurd, 2013-10-03 + + youpi: i've committed a fix to hurd that checks for negative sizes + when truncating files + this allows building the ustr package without making ext2fs choke + on an assertion + pinotree is preparing a patch for glibc + see truncate/ftruncate + with an off_t size parameter, which can be negative + EINVAL The argument length is negative or larger than the + maximum file size. + hurd servers were not conforming to that before my change + + +## Multiple mtab Translators Spawned + +### IRC, freenode, #hurd, 2013-09-20 teythoon: how come i see three mtab translators running ? 6 now oO @@ -2113,10 +2351,250 @@ In context of [[open_issues/mig_portable_rpc_declarations]]. teythoon: more bug fixing for you :) -## IRC, freenode, #hurd, 2013-09-23 +### IRC, freenode, #hurd, 2013-09-23 so it might be a problem with either libnetfs (which afaics has never supported passive translator records before) or procfs, but tbh I haven't investigated this yet [[open_issues/libnetfs_passive_translators]]. + +### IRC, freenode, #hurd, 2013-09-26 + + teythoon: hum, i just saw something disturbing + teythoon: to isolate the leak, i created my own proc directory + and the mtab translators it spawns seem to be owned by root oO + braunr: but how is that possible? are you sure? have you checked + with 'ids'? + no i'm not sure + also, ext2fs seems to ignore --writable when started as a passive + translator + < teythoon> braunr: but how is that possible? + messup with passive translators i guess + teythoon: actually, it looks like it has effective/available id + it has no* + this feature doesn't map well in unix + braunr: ah yes, htop doesn't handle this well and shows root + indeed, our ps shows - as username + yes + + +### [[!debbug 724868]] + + +### IRC, freenode, #hurd, 2013-10-03 + + i can't manage to find out where the hurd stores information about + active translators ... + there is this transbox per node + but where are nodes stored ? + what if they are are dropped ? + braunr: iirc, see libfshelp + well i have + i still can't find it + i fear that it works for ext2fs because that particular translator + implements a cache of open nodes + whereas things like procfs drop and recreate nodes per open + which would be the root cause for the multiple mtab bug + doesn't tmpfs support translators? + good idea + although it's still a libdiskfs based one + no problem for tmpfs, so it would be a netfs/procfs issue + better than what i feared :) + now, how is libdiskfs able to find active translators .. + ah, there is a name cache in libdiskfs .. + nope, looks fine + + +### IRC, freenode, #hurd, 2013-10-04 + + nodes with a translator seem to keep a reference in libdiskfs and + not in libnetfs + mhmmpf + oh great .. + each libdiskfs that "works" seems to implement its own + diskfs_cached_lookup function + so both ext2fs and tmpfs actually maintain a list of nodes, + keeping a reference on those with a translator + while procfs simply doesn't + teythoon: ^ + *sigh* + braunr: ok, thanks, I'll look into that + i'm not sure how to fix it + we can either fix node destruction to cleanly shut down + translators + but this would mean starting mtab on each access + or we could implement a custom cache in procfs + or perhaps a very custom change in the lookup callback for mounts + i'll try the latter + err, shouldn't we try to fix this in lib*fs? + unless you really want to work on it + i dont' know + ah, so the node is destroyed but the translator is kept running? + that's what you mean by the above? + and ext2fs makes an effort of killing it in its node cleanup + code? + yes + grmbl, i'm lagging a lot + i'm not sure + ext2fs maintains it + with ext2fs, translators can only be explicitely removed + i mean, ext2fs keeps all node descriptors alive once accessed + while procfs doesn't + teythoon: ok, looks like i have a working patch that merely caches + the node for mounts + libnetfs suffers from the same leak as libdiskfs when looking up a + translator + i'll fix it too + + i installed my fixed procfs on darnassus, only one mtab :) + nice :) + now, why is there no /home in df output ? + not sure + note how /dev/tty* end up in /proc/mounts, those are passive + translators too, no? + yes + but that's a good thing i guess + or was mounts intended for file systems only ? + well, in the unix traditional meaning + I think its nice too, yes + but why are they fine and your /home is not... + that's weirder + also, mounts actually doesn't show passive translators + teythoon: does your code perform any kind of comparison ? + i see /servers/socket/26 but not /servers/socket/2 + s/comparison/filter/g + hmm + well, yes, try /hurd/mtab --insecure / + (I cannot connect to darnassus from here...) + ok but that looks unrelated + both /servers/socket/26 and /servers/socket/2 refer to the same + translator + i was wondering if mtab was filtering similar entries based on + that + no + that's weird too then, isn't it ? + yes ;) + ok + btw, how is that done with the same traanslator being bound to + two nodes? settrans cannot do that, can it? + no it can't + the translator does it when started + ah + (which means there is a race if both are started simulatneously, + although it's very rare and not hard to solve) + a weird beaving translator then :) + + i have a fix for the multiple mtab issue, will send a patch + tonight + + teythoon: if ext2fs is set active, mtab output reports it + + teythoon: looks like this bug is what allows mtab not to deadlock + teythoon: when i attach it as an active translator, cat freezes + + teythoon: if (control && control->pi.port_right == fsys) + that's the filtering i was previously talking about + oh please don't name global variables "path" ... + + youpi: i fixed procfs on ironforge and exodar to be started as + procfs -c -k 3 + without -k 3, many things as simple as top and uptime won't work + + +### IRC, freenode, #hurd, 2013-10-06 + + teythoon: pty-s also bind to two nodes, not only pfinet + + +### IRC, freenode, #hurd, 2013-10-07 + + teythoon: please tell us when you're available, we need to work + out the last mtab issues + braunr: I'm available now :) + I'm sorry, I've been very busy the last two weeks, but I've + plenty of time now + great :) + did you see youpi's mail ? + i have the exact same question + I did + it seems your code registers active translators + but parent translators don't seem to register them when they're + created from passive translators + or am i mistaken ? + I'll need a moment to get my hurd machine and myself up to + speed... + braunr: I concur with youpi, hooking into fshelp_fetch_root + should do just fine + I'll just try that + ok + how do you deal with mtab reporting itself ? + o_O does it do that? + no, but it should + when i set it as an active translator, i get a deadlock + hm + teythoon: before you change libfshelp, i'd like you to try + something else + use more appropriate names for global variables in mtab.c + in particular, the variable path clashes with local names + noted + teythoon: as a side note (i'm not asking to rewrite anything) + i strongly recommend a very explicit object oriented style of + coding + (or data-oriented as it's sometimes called) + use prefixes for all your interfaces so they can be made public if + needed (which acts as a namespace and avoids lots of collisions + naturally) + use "constructors" and "destructors" (functions that both allocate + and initialize) + this helps avoiding leaks a lot too + hm, I thought I did that, could you be more specific? + ok didn't see the comment + /* XXX split up */ error_t mtab_populate (... + :) + as a better example, see your code in libfshelp/translator-list.c + struct translator should have been treated as an object + this would probably have completely avoided any leaks in the first + place + braunr: right, I deviated from that style there + teythoon: these are minor details, don't mind them too much, i + just find it helps me a lot + braunr: sure, I appreciate the feedback :) + + +### IRC, freenode, #hurd, 2013-10-08 + + braunr: I'm on to the passive translator not getting registered + issue + however, removing them from the list if the active translator is + killed does not work as expected... I still need to fiddle with the + notifications to get this right + ok + + +### IRC, freenode, #hurd, 2013-10-16 + + braunr: btw, I fixed the 'passive translator not showing up in + proc/mounts'-issue + but 4 ports do leak each time a translator is killed and + reinstalled + this happens with passive ones as well as active ones + teythoon: is that issue tied to your changed ? + changes* + I'm not sure tbh, testing that is on my list of things to do + ok + first thing to know i guess + yes + + +## Memory Leak in `translator_ihash_cleanup` + +### IRC, freenode, #hurd, 2013-10-04 + + teythoon: isn't there a leak in translator_ihash_cleanup ? + braunr: looks like, yes + braunr: I probably forgot to add the free (element->name) when I + added the name field + teythoon: ok + teythoon: i let you fix that :p + braunr: sure ;) diff --git a/hurd/translator/proc.mdwn b/hurd/translator/proc.mdwn index d5e0960c..75bfb8fd 100644 --- a/hurd/translator/proc.mdwn +++ b/hurd/translator/proc.mdwn @@ -63,6 +63,35 @@ It is stated by `/hurd/init`. something special +## IRC, freenode, #hurd, 2013-09-25 + + so nice to finally see proc in top :) + hm cute, htop layout has become buggy, top just won't start + braunr: make sure your procfs knows the correct kernel pid + # showtrans /proc + /hurd/procfs -c -k 3 + we could have handled this nicer if procfs were integrated + upstream + we should probably just update the default + teythoon: mhm + $ fsysopts /proc + /hurd/procfs --stat-mode=444 --fake-self=1 + $ showtrans /proc + /hurd/procfs -c + -c == --stat-mode=444 --fake-self=1 + better indeed + teythoon: thanks + + +## IRC, freenode, #hurd, 2013-10-24 + + braunr: i'm using your repo and i can't see cpu percentage in htop + anymore, all zeroes, confirmed? + gg0: no + gg0: you probably need to reset procfs + gg0: settrans /proc /hurd/procfs -c -k 3 + + # Process Discovery ## IRC, freenode, #hurd, 2013-08-26 diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn index fc071337..018db7b2 100644 --- a/hurd/translator/procfs/jkoenig/discussion.mdwn +++ b/hurd/translator/procfs/jkoenig/discussion.mdwn @@ -436,6 +436,72 @@ Also used in `[GCC]/intl/relocatable.c`:`find_shared_library_fullname` for `#ifdef __linux__`. +### IRC, freenode, #hurd, 2013-10-03 + + what's the equivalent of cat /proc/self/maps on hurd? + camm`: for now, /proc/self doesn't work as expected + thanks, I just want to get a list of maps and protection status for + a running process -- how? + vminfo + thanks so much! I'm trying to debug an unexec failure on hurd when + a linker script is present. All works with the default script, but when + the text address is changed, unexec fails, running into a page with no + access in the middle of the executable: 0xc4b000[0x1000] (prot=0, + max_prot=RWX, offs=0xb55000) + I get a segfault when trying to read from this page. + unexec ? + emacs/gcl/maxima/acl2/hol88/axiom use unexec to dump a running + image into a saved executable elf file. + what is unexec ? + ok looks like a dirty tool + camm`: what is segfaulting, unexec or the resulting executable ? + unexec opens the file from which the running program was originally + executed, finds its section start addresses, then writes a new file + replacing any data in the old file with possibly modified versions in + running memory. The reverse of 'exec'. + the read from running memory delimited by the addresses in the + executable file is hitting a page which has been protected with *no* + access, and is segfaulting. Somehow, when the binary file is loaded, + hurd turning off all rights to this page. + let me check the stack location ... + ok I think I've got it -- hurd moves the sbrk(0) address away from + the end of .data (as reported by readelf) if the addresses are low, + presumably to avoid running into the stack. + starting sbrk(0)!=.data+data_size on hurd + i'm not sure there is anything like the heap on the hurd + sbrk is probably implemented on top of mmap + camm`: hm no, i'm wrong, glibc implements brk and sbrk mostly as + expected, but remapping the area isn't atomic + "Now reallocate it with no access allowed" + then, there is a call to vm_protect + and no error checking + ... + ok, that's fine, but need to know -- in general there is no + relationship between the address returned by sbrk(0) and the .data + addresses reported by readelf on the file, (hurd only) yes? + i don't know about that + there should be .. + Specific example: readelf -a -> [24] .data PROGBITS + 000f5580 0c4580 000328 00 WA 0 0 32 + + sbrk(0)->(void *) 0x8021000 + camm`: is that on an executable or a shared object ? + executable + 000f5580 looks very low + This is using a linker script. The default setup works just fine. + I think it (might) make sense for hurd to silently do this give the + placement of the C stack, but the assumptions behind my algorithm need + changing (perhaps). + (I probe in configure the allowable range of __executable_start, + and then choose a value to either ensure a large free signed range around + NULL, or a low data start to maximize heap) + braunr: are there any guarantees of sbrk(0)==.data+size without a + linker script? + camm`: i'm not sure at all + sbrk isn't even posix + thanks + + # `/proc/[PID]/mem` Needed by glibc's `pldd` tool (commit @@ -471,3 +537,19 @@ Needed by glibc's `pldd` tool (commit both htop and top seem to have problems report the cpu time so i expect the problem to be in procfs + + +# IRC, freenode, #hurd, 2013-10-03 + + teythoon: any reason the static variable translator_exists isn't + protected by a lock in procfs/rootdir.c ? + + +## IRC, freenode, #hurd, 2013-10-04 + + teythoon: can you tell me why translator_exists isn't protected + from shared access in rootdir_mounts_exists ? + braunr: hm, dunno tbh, I probably thought the race was harmless + enough + it probably is + settrans -Rg doesn't work on procfs :( diff --git a/hurd/translator/term.mdwn b/hurd/translator/term.mdwn new file mode 100644 index 00000000..667677a7 --- /dev/null +++ b/hurd/translator/term.mdwn @@ -0,0 +1,207 @@ +[[!meta copyright="Copyright © 2013 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +The *term* translator implements POSIX termios discipline. + + +# Open Issues + +## [[open_issues/Term_Blocking]] + +## Leaks/Not Re-used/Not Terminating + +[[!tag open_issue_hurd]] + + +### IRC, freenode, #hurd, 2013-10-14 + + good news + the terminal leak is related to privilege separation + I love how, as an unknowing by-stander, that is somehow good news + :-) + :) + it's a good news because 1/ we have more knowledge about the issue + and 2/ it may not even be a hurd bug + but rather an openssh-on-hurd bug + this explains why i didn't see the issue on anything else + (mach/hurd consoles, x terminals) + and this will also indirectly solve the screen lockup issue + braunr: good catch :) + s/a good news/good news/ + ah, yes, both definitely good news. Congrats on the progress. + i remember we used to disable privilege separation in the past + i'll have to dig what made us use it + interesting, screen seems to be affected nonetheless + so it's something common to both screen and ssh privsep + apparently, what sshd+privse and screen have in common is a fifo + so it's probably a tricky hurd bug actually + + +### IRC, freenode, #hurd, 2013-10-16 + + pflocal is leaking ports .. + this might be what blocks terminals + * pinotree gives braunr a stick of glue + thanks + + pflocal leaks struct sock .. + grmbl + + hm nice, pflocal leaks each time a socket is bound and/or accepted + on + looks like a simple ref mess + braunr: really? + yes + a leak in pflocal feels strange, never noticed it taking lots of + memory (and it's used a lot) + it's a port leak + well + no it's both a memory and port leak + not sure which one is the root cause yet + i guess server sockets aren't automatically unbound + if you want to see the leak, just disable priv separation in ssh + (to avoid the terminal leak ....) and write a shell loop to start ssh + your_server echo hello + google shows mails about the leak in the past + i also hope it fixes the terminal leak, although i'm really not + sure :( + + +### IRC, freenode, #hurd, 2013-10-17 + + hm nice, apparently, there is no pflocal leak + but a libdiskfs one ! + since ext2fs enables the ifsock shortcut + seems like it leaks a reference on sock node deletion + braunr: have you looked at libdiskfs/dead-name.c? + braunr: I think I'm hunting a very similar problem + i'm doing it now + I had the problem of dead name notifications not being delivered + wow + b/c I held no reference to the ports_info thing, so the dead + name handler in libports could no longer find the pi struct, so the + notification was silently dropped + i see + but it looks like dropping a node makes sure the associated + sockaddr has been deleted if any + are you sure the node is dropped in the first place? + no + well + i see something happenning at the pflocal side when removing the + node + but there is still a send right lingering somewhere + (see why we need a global lsof :p) + indeed + i'll try portinfo with that option we talked about + yes + 121 => 1682: send (refs: 1) + yep, ext2fs still has it + (I wonder how portinfo does that...) + i guess it imports rights from the target task + and see if it gets the same name as a local right + makes sense + easy to check + well, no, it cannot do that for receive rights + it creates an empty task just for that purpose + and uses mach_port_extract_right + but it works as you described, yes + so yes it does work for receive rights too + yes + cool :) + so it assumes identical port names are part of the ipc interface + something neal said we shouldn't rely on + iirc + yes, I remember something like that too + here is the strange thing + node->sockaddr is deallocated on a dead name notification + drop_node checks that sockaddr is null + so how can the dead name notification occur before the node is + dropped ? + so maybe the node is still around indeed + apparently, libdiskfs considers the address holds a reference on + the node + on the other hand, the server socket won't get released unless the + address gets a no-sender notification ... + this should probably be turned into a weak reference + teythoon: indeed, the node is leaked + + pflocal crashes when removing correctly deallocating addresses and + removing server sockets :/ + + ok, pflocal bug fixed + still have to fix the libdiskfs leak + and libdiskfs leak fixed too + :) + i'll build hurd packages with my changes to make sure i don't + break something before comitting + and see if this fixes the term issue + + looks like my patches work just fine :) + it doesn't solve the term issue though + + so, according to portinfo, pflocal has send rights to terminals oO + + mhhhmmmmmm + openssh seems to pass terminal file descriptors through unix + sockets when using privilege separation + braunr: i a write(sock, &pid, sizeof int) (or the like)? + *ie + not pid, file descriptors + SCM_RIGHTS + ah ok + the socket send/recv interface does support passing mach ports + and the leaked ports do turn into dead names when i kill terminals + yes, we support with a patch pochu did few years ago + so it seems the leak is related to libpipe this time + ok got it :) + pflocal used copy_send instead of move_send + \o/ + that bug was such a pain + * braunr happy + :) + speaking of it, in pflocal' S_socket_recv is it correct the + "out_flags = 0;"? + nice catch + although i wonder why flags are returned + it may have been set to null to tell us that we don't want to + return flags + pfinet seems to use it + but you change a local variable anyway + yes it's not useful + hmm + out_flags is what gets in struct msghdr -> msg_flags + so i guess it makes sense to fix it to *out_flags = 0, just to be + safe + pinotree: do you want me to push it tonight along with the others + ? + yes please + ok + thanks! + pflocal seems to not leak any memory or ports at all + great :> + + there, patches pushed :) + + +## `screen` Logout Hang + +[[!tag open_issue_hurd]] + + +### IRC, freenode, #hurd, 2013-10-14 + + i fixed term so that screen can shutdown properly + read() wouldn't return EIO after terminal hangup + + +### IRC, freenode, #hurd, 2013-10-17 + + and the missing EOI prevented screen from correctly shutting down + windows diff --git a/hurd/translator/tmpfs/discussion.mdwn b/hurd/translator/tmpfs/discussion.mdwn index 20aba837..8c332d84 100644 --- a/hurd/translator/tmpfs/discussion.mdwn +++ b/hurd/translator/tmpfs/discussion.mdwn @@ -430,3 +430,40 @@ License|/fdl]]."]]"""]] ok but that indeed means writeback of ext2fs works, which is a good sign :) + + +# IRC, freenode, #hurd, 2013-10-04 + + btw, I noticed that fifos do not work on tmpfs + teythoon: tmpfs seems limited, yes + that's annoying b/c /run is a tmpfs on Debian and sysvinit + creates a crontrol fifo there + I wonder why I didn't notice that before + also, fifos, like symlinks, can be shortcircuited in libdiskfs + i wonder if that has anything to do with the problem at hand + +[[mtab/discussion]], *Multiple mtab Translators Spawned*. + + b/c this breaks reboot & friends + I do too + b/c I cannot find any shortcut related code in tmpfs + well, it's optional normally + so that's ok + but has it really been tested when the option wasn't there ? :) + yes, but the tmpfs requests this by setting diskfs_shortcut_fifo + = 1; + hm i remember tmpfs was said to be working with + sockets/fifos/etc, back then when it was fixed + teythoon: oh + + +## IRC, freenode, #hurd, 2013-10-11 + + this will have to wait for the next hurd pkg unfortunately, b/c + I broke tmpfs by accident :-/ + how so? + the dropping of privileges broke passive translators and mkfifo + there actually is a reason why those are run as root or with the + privilege of their owner + privileges should be decoupled from identity + yes diff --git a/microkernel/mach/deficiencies.mdwn b/microkernel/mach/deficiencies.mdwn index 8f47f61f..2e205a9a 100644 --- a/microkernel/mach/deficiencies.mdwn +++ b/microkernel/mach/deficiencies.mdwn @@ -2384,3 +2384,310 @@ In context of [[open_issues/multithreading]] and later [[open_issues/select]]. concurrently (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 + + braunr: http://git.sceen.net/rbraun/x15.git/blob/HEAD:/README + "X15 is a free microkernel." + braunr: what distinguishes it from existing microkernels? + + +## IRC, freenode, #hurd, 2013-09-29 + + rah: the next part maybe ? + "Its purpose is to provide a foundation for a Hurd-like operating + system." + braunr: there are already microkernels that canbe used as the + foundatin for Hurd=like operating systems; why are you creating another + one? + braunr: what distinguishes your microkernel from existing + microkernels? + rah: + http://www.gnu.org/software/hurd/microkernel/mach/deficiencies.html + rah: it's better :) + rah: and please, cite one suitable kernel for the hurd + tschwinge: those are deficiencies in Mach; I'm asking about x15 + braunr: in what way is it better exactly? + rah: more performant, more scalable + braunr: how? + better algorithms, better interfaces + for example, it supports smp + ah + it supports SMP + ok + that's one thing + it implements lockless synchronization à la rcu + are there any others? + ok + lockless sync + anything else? + it can scale from 4MB of physical memory up to several hundreds + GiB + ipc is completely different, leading to simpler code, less data + involved, faster context switches + (although there is no code for that yet) + how can it support larger memory while other microkernels can't? + how is the ipc "different"? + others can + gnumach doesn't + how can it support larger memory while gnumach can't? + because it's not the same code base? + gnumach doesn't support temporary kernel mapping + ok, so x15 supports temporary kernel mapping + not exactly + virtual memory is completely different + how so? + gnumach 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 gnumach 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 + rah: I think basically all this has already been discussed + before and captured on that page? + it already supports i386/pae/amd64 + I see + the drawback is that it needs to update kernel page tables more + often + on linux, a small part of the kernel space is reserved for + temporary mappings, which need page table updates too + but most allocations don't use that + it's complicated + also, i plan to make virtual memory operations completely + concurrent on x15, similar to what is described in radixvm + ok + which means mapping operations on non overlapping regions won't be + serialized + a big advantage for microkernels which base their messaging + optimizations on mapping + so simply put, better performance because of simpler ipc and data + structures, and better scalability because of improved data structure + algorithms and concurrency + tschwinge: yes but that page is no use to someone who wants a summary + of what distinguishes x15 + x15 is still far from complete, which is why i don't advertise it + other than here + "release early, release often"? + give it a few more years :p + release what ? + something that doesn't work ? + software + yes + this release early practice applies to maintenance + release something that doesn't work so that others can help make it + work + not big developments + i don't want that for now + i have a specific idea of what i want, and both explaining and + defending it would take time, better spent in development itself + just wait for a first prototype + 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 + one big difference with other microkernels is that x15 is + specifically intended to run a unix like system + a hurd like system providing a psoix interface more accurately + and efficiently + so for example, while many microkernels provide only sync ipc, x15 + provides both sync ipc and signals + and then, there are a lot of small optimizations, like 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.. + http://darnassus.sceen.net/~hurd-web/microkernel/x15/ + please take note of the fact that this newly created page is not just + a dump of IRC logs + + +## IRC, freenode, #hurd, 2013-09-30 + + rah: i'm uncomfortable with a page about x15 on the wiki ... + there is a reason i don't want to advertise it for now + and you're just completely ignoring it + braunr: detailed information about x15 is already included elsewhere + in the wiki + rah: really ? + braunr: there is a section named "X15" on this page: + http://www.gnu.org/software/hurd/microkernel/mach/deficiencies.html + rah: oh ok, but it's still small and hard to find ;p + braunr: "small"?! + braunr: the X15 section starts at about 10% down the page and + finishes at the bottom of the page + braunr: and the page is huge + rah: hm ok, but that's still listed as mach deficiencies, not as + x15 itself + braunr: I heard about x15 + braunr: I wanted to learn about it + braunr: there was no easily accessible information for doing so + braunr: it's not unreasonable to want to learn about it, having heard + about it + braunr: others will want to learn about it + rah: please respect the developer's policy of how to advertise + their project + braunr: having learned about it myself, I've helped those who will + follow me by giving them the summary that I wanted + azeem_: I'm not disrespecting the developer's policy of how to + advertise their project; I'm not advertising their project + rah: maybe replace the wiki page by "If you would like to know + about X15, please contact " + azeem_: that's ridiculous + rah: then ask me directly + rah: don't make wiki pages + braunr: I don't understand what you mean + braunr: I have already asked you directly + braunr: I needed to ask you directly in order to make the wiki page + rah: braunr does not like your wiki page, how hard is it to + understand? + azeem: my discussion is with braunr, not you + rah: if someone wants to know more about x15, he can me directly, + no need for a wiki page + + +## IRC, freenode, #hurd, 2013-10-01 + + braunr: that's hyperbole; there's no "need" for a wiki, or for x15 or + even for the Hurd + braunr: a wiki page is helpful + useful, even + rah: as azeem said, i'm just not willing to advertise outside this + channel for now + it makes sense to mention it in the defficiencies page, since this + page talks about what's lacking in gnumach + and the wiki is about the hurd, including gnumach + braunr: why does it make sense to mention it in the deficiencies page + but not in a dedicated page? + rah: because gnumach is a hurd project, x15 isn't + braunr: what do you mean by "a hurd project"? + braunr: you're saying that x15 differs from gnumach in some way, and + that this difference is the reason it doesn't make sense to have a wiki + page devoted to x15; the phrase you've used to descibe that difference is + "a hurd project" but it's not clear what, exactly, you mean by that + braunr: could you explain what you mean by that? + rah: this is getting off-topic, please take this conversation + elsewhere + azeem: that's a very tenuous statement + azeem: I think this is the appropriate place to discuss the matter + I leave that to braunr to decide + azeem: I think *you* don't want the conversation to be had at all and + are attempting to censor it using a tenuous excuse + no no, I'm not censoring it - I am just saying you should take it + elsewhere + let's take it elsewhere + + +## IRC, freenode, #hurd, 2013-10-12 + + braunr: are you still working on x15/propel? + * zacts checks the git logs + 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 + + 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? + gnufreex: i always intended to go for a hybrid + + +## IRC, freenode, #hurd, 2013-10-19 + + braunr: when do you plan to start on x15/propel again? + zacts: after i'm done with thread destruction on the hurd + +[[open_issues/libpthread/t/fix_have_kernel_resources]]. + + and do you plan to actually run hurd on top of x15, or are you + still going to reimplement hurd as propel? + and no, i don't intend to run the hurd on top of x15 + + +## IRC, freenode, #hurd, 2013-10-24 + + braunr: What is your Mach replacement doing? + "what" ? :) + you mean how i guess + Sure. + well it's not a mach replacement any more + and for now it's stalled while i'm working on the hurd + that could be positive :) + it's in good shape + how did it diverge? + sync ipc, with unix-like signals + and qnx-like bare data messages + hmm, like okl5? + (with scatter gather) + okl4 + yes + 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 :/ + basically, x15 has a much lighter ipc interface + capabilities? + mach ports are mostly retained + but reference counting will be simplified + hmm + I don't like the reference counting part + port names will be plain integers, to directly be usable as file + descriptors and avoid a useless translation layer + (same as in qnx) + this sounds like future tense + there is no ipc code yet + so I guess this stuff is not implemented + ok. + next step is virtual memory + and i'm taking my time because i want it to be a killer feature + so if you don't IPC and you don't have VM, what do you have? :) + i have multiprocessor multithreading + I see. + mutexes, condition variables, rcu-like lockless synchronization, + work queues + basic bsd-like virtual memory + which i want to rework + I ignored all of that in Viengoos :) + and since ipc will still depend on virtual memory for zero-copy, i + want the vm system to be right + well, i'm more interested in the implementation than the + architecture + for example, i have unpublished code that features a lockless + radix tree for vm_object lookups + that's quite new for a microkernel based system, but the ipc + interface itself is very similar to what already exists + your half-sync ipc are original :) + I'm considering getting back in the OS game. + oh + But, I'm not going to write a kernel this time. + did anyone here consider starting a company for such things, like + genode did ? + I was considering using genode as a base. + neal: why genode ? + I want to build a secure system. + I think the best way to do that is using capabilities. + Genode runs on Fiasco.OC, for instance + and it provides a lot of infrastructure + neal: why not l4re for example ? + 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*: + + 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) + teythoon: that is a big interface change + how so + optimizing libihash and libpthread should already be a good start + well how do you intend to add this information ? + ok, "big" is overstatement, but still, it's a low level interface + change that would probably break a lot of things + store a pointer in the port structure in gnumach, make that + accessible somehow + yes but how ? + interesting question indeed + my plan for x15 is to make this "label" part of received messages + which means you need to change the format of messages + that is what i call a big change diff --git a/microkernel/mach/gnumach/boot_trace.mdwn b/microkernel/mach/gnumach/boot_trace.mdwn index 7b729c23..ea999a9b 100644 --- a/microkernel/mach/gnumach/boot_trace.mdwn +++ b/microkernel/mach/gnumach/boot_trace.mdwn @@ -227,3 +227,25 @@ License|/fdl]]."]]"""]] >> vm\_pageout >> Does not return. + + +# IRC, freenode, #hurd, 2013-10-07 + + look, where should i dig or where from should i start from, if i + have desire to know how the kernel was written from baremetal? Can it be + ever done nowadays? + cureOS: the boot entry of the kernel is i386/i386at/boothdr.S , + boot_entry + that's what grub jumps to + then that jumps to c_boot_entry + and everything else is C + grub loads it somehow. how does it prepare cpu and memoty, cpu + cache control if any... segments for stack.. + see the grub documentation + basically it's all flat linear space + does kernel transform it after that? + see the ldt/gdt initialization + from i386at_init and children + nothing much fancy, a kernel cs/ds, and user cs/ds + and paging, naturally + sure diff --git a/open_issues/64-bit_port.mdwn b/open_issues/64-bit_port.mdwn index b0c95612..edb2dccd 100644 --- a/open_issues/64-bit_port.mdwn +++ b/open_issues/64-bit_port.mdwn @@ -155,3 +155,10 @@ In context of [[mondriaan_memory_protection]]. the problem is the interfaces themselves type widths as passed between userspace and kernel + + +# IRC, OFTC, #debian-hurd, 2013-10-05 + + and what about 64 bit support, almost done? + kernel part is done + MIG 32/64 trnaslation missing diff --git a/open_issues/anatomy_of_a_hurd_system.mdwn b/open_issues/anatomy_of_a_hurd_system.mdwn index ba72b00f..a3c55063 100644 --- a/open_issues/anatomy_of_a_hurd_system.mdwn +++ b/open_issues/anatomy_of_a_hurd_system.mdwn @@ -803,3 +803,11 @@ Actually, the Hurd has never used an M:N model. Both libthreads (cthreads) and l and hoping it didn't corrupt something important like file system caches before being flushed kilobug, braunr : mhn, ook + + +# IRC, freenode, #hurd, 2013-10-13 + + ahh, ^c isn't working to cancel a ping - is there alternative? + ahungry: ctrl-c does work, you just missed something somewhere and + are running a shell directly on a console, without a terminal to handle + signals diff --git a/open_issues/boehm_gc.mdwn b/open_issues/boehm_gc.mdwn index 623dcb83..0a476d71 100644 --- a/open_issues/boehm_gc.mdwn +++ b/open_issues/boehm_gc.mdwn @@ -523,3 +523,22 @@ restults of GNU/Linux and GNU/Hurd look very similar. hi, I am dotgnu work on hurd, and even winforms app s/am/make and maybe c# hello world translate another day :) + + +## Leak Detection + +### IRC, freenode, #hurd, 2013-10-17 + + I spent the last two days integrating libgc - the boehm + conservative garbage collector - into hurd + it can be used in leak detection mode + whoa, cool + and it actually kind of works, finds malloc leaks in translators + i think there were problems with signal handling in libgc + i'm not sure we support nested signal handling well + yes, I read about them + libgc uses SIGUSR1/2, so any program installing handlers on them + will break + (which is not a problem on Linux, cause there some RT-signals or so + are used) + yes diff --git a/open_issues/code_analysis/discussion.mdwn b/open_issues/code_analysis/discussion.mdwn index 7ac3beb1..4cb03293 100644 --- a/open_issues/code_analysis/discussion.mdwn +++ b/open_issues/code_analysis/discussion.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011, 2012, 2013 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -42,6 +43,8 @@ License|/fdl]]."]]"""]] i tried duma, and it crashes, probably because of cthreads :) +# Static Analysis + ## IRC, freenode, #hurd, 2012-09-08 hello. What static analyzer would you suggest (probably you have @@ -49,3 +52,54 @@ License|/fdl]]."]]"""]] mcsim: if you find some good free static analyzer, let me know :) a simple one is cppcheck braunr: I'm choosing now between splint and adlint + + +## IRC, freenode, #hurd, 2013-10-17 + + whoa, llvm kinda works, enough to make scan-build work :) + teythoon: what is scan-build ? + braunr: clangs static analyzer + ok + I'm doing a full build of the hurd using it, I will post the + report once it is finished + this will help spot many problems + well, here are the scan-build reports I got so far: + https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build/ + I noticed it finds problems in mig generated code, so there are + probably lot's of duplictaes for those kind of problems + what's a... better one to look at? + it's also good at spotting error handling errors, and can spot + leaks sometimes + hm + + https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build/report-yVBHO1.html + that's minor, the device always exist + but that's still ugly + + https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build/report-MtgWSa.html + + https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build/report-QdsZIm.html + this could be important: + https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build/report-PDMEbk.html + this is the issue it finds in mig generated server stubs: + https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build/report-iU3soc.html + this one is #if TypeCheck1 + the libports one looks weird indeed + but TypeCheck is 1 (the tooltip shows macro expansion) + it is defined in line 23 + oh + hmmm... clang does not support nested functions, that will limit + its usefulness for us :/ + yes + one more reason not to use them + + +### IRC, freenode, #hurd, 2013-10-18 + + more complete, now with index: + https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build-2/ + + +# Leak Detection + +See *Leak Detection* on [[boehm_gc]]. diff --git a/open_issues/dbus.mdwn b/open_issues/dbus.mdwn index a41515a1..4473fba0 100644 --- a/open_issues/dbus.mdwn +++ b/open_issues/dbus.mdwn @@ -253,3 +253,115 @@ See [[glibc]], *Missing interfaces, amongst many more*, *`SOCK_CLOEXEC`*. to know how to find this sendmsg.c file? (it's in glibc, but otherwise the remark is valid) s/otherwise/anyway/ + + +# Emails + +# IRC, freenode, #hurd, 2013-10-16 + + gnu_srs: how could you fail to understand credentials need to be + checked ? + braunr: If data is sent via sendmsg, no problem, right? + gnu_srs: that's irrelevant + It's just to move the check to the receive side. + and that is the whole problem + it's not "just" doing it + first, do you know what the receive side is ? + do you know what it can be ? + do you know where the corresponding source code is to be found ? + please, describe a scenario where receiving faulty ancillary data + could be a problem instead + dbus + a user starting privileged stuff although he's not part of a + privileged group of users for example + gnome, kde and others use dbus to pass user ids around + if you can't rely on these ids being correct, you can compromise + the whole system + because dbus runs as root and can give root privileges + or maybe not root, i don't remember but a system user probably + "messagebus" + k! + see http://www.gnu.org/software/hurd/open_issues/dbus.html + IRC, freenode, #hurd, 2013-07-17 + and the proper fix is to patch pflocal to query the + auth server and add the credentials? + possibly + that doesn't sound to bad, did you give it a try? + + +# IRC, freenode, #hurd, 2013-10-22 + + I think I have a solution on the receive side for SCM_CREDS :) + + A question related to SCM_CREDS: dbus use a zero data byte to get + credentials sent. + however, kfreebsd does not care which data (and credentials) is + sent, they report the credentials anyway + should the hurd implementation do the same as kfreebsd? + gnu_srs: I'm not sure to understand: what happens on linux then? + does it see zero data byte as being bogus, and refuse to send the + creds? + linux is also transparent, it sends the credentials independent + of the data (but data has to be non-null) + ok + anyway, what the sending application writes does not matter indeed + so we can just ignore that + and have creds sent anyway + i think the interface normally requires at least a byte of data + for ancilliary data + possibly, yes + To pass file descriptors or credentials over a SOCK_STREAM, + you need to send or + receive at least one byte of non-ancillary data in + the same sendmsg(2) or + recvmsg(2) call. + but that may simply be linux specific + gnu_srs: how do you plan on implementing right checking ? + Yes, data has to be sent, at least one byte, I was asking about + e.g. sending an integer + just send a zero + well + dbus already does that + just don't change anything + let applications pass the data they want + the socket interface already deals with port rights correctly + what you need to do is make sure the rights received match the + credentials + The question is to special case on a zero byte, and forbid + anything else, or allow any data. + why would you forbid + ? + linux and kfreebsd does not special case on a received zero byte + same question, why would you want to do that ? + linux sends credentials data even if no SCM_CREDENTIALS structure + is created, kfreebsd don't + i doubt that + To be specific:msgh.msg_control = NULL; msgh.msg_controllen = 0; + bbl + see the test code: + http://lists.debian.org/debian-hurd/2013/08/msg00091.html + back + why would the hurd include groups when sending a zero byte, but + only uid when not ? + ? + 1) Sent credentials are correct: + no flags: Hurd: OK, only sent ids + -z Hurd: OK, sent IDs + groups + and how can it send more than one uid and gid ? + "sent credentials are not honoured, received ones are created" + Sorry, the implementation is changed by now. And I don't special + case on a zero byte. + what does this mean ? + then why give me that link ? + The code still applies for Linux and kFreeBSD. + It means that whatever you send, the kernel emits does not read + that data: see + socket.h: before struct cmsgcred: the sender's structure is + ignored ... + do you mean receiving on a socket can succeed with gaining + credentials, although the sender sent wrong ones ? + Looks like it. I don't have a kfreebsd image available right now. + linux returns EPERM + anyway + how do you plan to implement credential checking ? + I'll mail patches RSN diff --git a/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn b/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn index e3a6b648..3faa56fc 100644 --- a/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn +++ b/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011, 2013 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -12,8 +13,22 @@ License|/fdl]]."]]"""]] [[!tag open_issue_gdb open_issue_gnumach]] +[[!toc]] -# IRC, freenode, #hurd, 2011-07-14 + +# Memory Map + +## IRC, freenode, #hurd, 2010-06 (?) + + is there a way to get gdb to map addresses as required when + debugging mach with qemu ? + I can examine the data if I manually map the addresses th + 0xc0000000 but maybe there's an easier way... + jkoenig: I haven't found a way + I'm mostly using the internal kdb + + +## IRC, freenode, #hurd, 2011-07-14 Hello. I have problem with debugging gnumach. I set 2 brakepoints in file i386/i386at/model_dep.c on functions gdt_init and idt_init. Then @@ -114,3 +129,18 @@ License|/fdl]]."]]"""]] oh, right, without GDB... though if that's what he meant, his statement was very misleading at least + + +# Multiboot + +See also discussion about *multiboot* on [[arm_port]]. + + +## IRC, freenode, #hurd, 2013-10-09 + + I was just wondering - once gnumach is compiled and I have the + gnumach elf, is that bootable? I.e. can I use something like + "qemu-system-i386 -kernel gnumach"? + matlea01: you need something with multiboot support (like grub) + to provide the various bootstrap modules to the kernel + Ah, I see diff --git a/open_issues/emacs.mdwn b/open_issues/emacs.mdwn index cdd1b10d..749649be 100644 --- a/open_issues/emacs.mdwn +++ b/open_issues/emacs.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009, 2013 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -1525,3 +1525,18 @@ perhaps prepared (I did not yet have a look), and re-tries again and again? Why doesn't Mach page out some pages to make memory available? This is stock GNU Mach from Git, no patches, configured for Xen domU usage. + + +# IRC, freenode, #hurd, 2013-10-04 + + given you are an emacs user: could you please pick the build + patch from deb#725099, recompile emacs24 and test it with your daily + work? + + +## IRC, freenode, #hurd, 2013-10-07 + + Wow! emacs24 runs in X:-D + pinotree: I've now built and installed emacs 24.3. So far so good + ^ + good, keep testing and stressing diff --git a/open_issues/exec_memory_leaks.mdwn b/open_issues/exec_memory_leaks.mdwn index 67281bdc..1fc5a928 100644 --- a/open_issues/exec_memory_leaks.mdwn +++ b/open_issues/exec_memory_leaks.mdwn @@ -94,3 +94,28 @@ After running the libtool testsuite for some time: 8 39.5 0:15.60 28:48.57 9 0.0 0:04.49 10:24.12 10 12.8 0:08.84 19:34.45 + + +# IRC, freenode, #hurd, 2013-10-08 + + * braunr hunting the exec leak + and i think i found it + yes :> + testing a bit more and committing the fix later tonight + pinotree: i've been building glibc for 40 mins and exec is still + consuming around 1m memory + wow nice + i've been noticing exec leaking quite some time ago, then forgot + to pay more attention to that + it's been more annoying since darnassus provides web access to + cgis + automated tools make requests every seconds + the leak occurred when starting a shell script or using system() + youpi: not sure you saw it, i fixed the exec leak + + +## IRC, freenode, #hurd, 2013-10-10 + + braunr: http://postimg.org/image/jd764wfpp/ + exec 797M + this should be fixed with the release of the next hurd packages diff --git a/open_issues/ext2fs_libports_reference_counting_assertion.mdwn b/open_issues/ext2fs_libports_reference_counting_assertion.mdwn index ff1c4c38..9ff43afa 100644 --- a/open_issues/ext2fs_libports_reference_counting_assertion.mdwn +++ b/open_issues/ext2fs_libports_reference_counting_assertion.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2012, 2013 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -91,3 +91,14 @@ With that patch in place, the assertion failure is seen more often. sure we can get that easily lol [[automatic_backtraces_when_assertions_hit]]. + + +# IRC, freenode, #hurd, 2013-10-09 + + mhmm, i may have an explanation for the weird assertions we + sometimes see in ext2fs + glibc uses alloca to reserve memory for one reply port per thread + in abort_all_rpcs + if this erases the thread-specific area, we can expect all kinds + of wreckage + i'm not sure how to fix this though diff --git a/open_issues/gdb_qemu_debugging_gnumach.mdwn b/open_issues/gdb_qemu_debugging_gnumach.mdwn deleted file mode 100644 index d3105f50..00000000 --- a/open_issues/gdb_qemu_debugging_gnumach.mdwn +++ /dev/null @@ -1,19 +0,0 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled [[GNU Free Documentation -License|/fdl]]."]]"""]] - -[[!tag open_issue_gdb open_issue_gnumach]] - -\#hurd, freenode, June (?) 2010 - - is there a way to get gdb to map addresses as required when debugging mach with qemu ? - I can examine the data if I manually map the addresses th 0xc0000000 but maybe there's an easier way... - jkoenig: I haven't found a way - I'm mostly using the internal kdb - diff --git a/open_issues/gdb_signal_handler.mdwn b/open_issues/gdb_signal_handler.mdwn index 3084f7e3..5e27a099 100644 --- a/open_issues/gdb_signal_handler.mdwn +++ b/open_issues/gdb_signal_handler.mdwn @@ -401,3 +401,74 @@ License|/fdl]]."]]"""]] braunr: are you sure? there is minimal user-code run before the signal is going into the handler. you "step out of the handler" + + +# IRC, freenode, #hurd, 2013-10-24 + + how come some executables are not debuggable with gdb, e.g Cannot + access memory at address xxx. -fPIC flag? + no + i'm not sure but it's certainly not -fPIC + Another example is localedef: ./debian/tmp-libc/usr/bin/localedef + -i en_GB -c -f UTF-8 -A /usr/share/locale/locale.alias en_GB.UTF-8 + segfailts + and in gdb hangs after creating a thread., after C-c no useful + info: stack ends with: Cannot access memory at address 0x8382c385 + if it's on the stack, it's probably a stack corruption + gnu_srs: are u using 'x' command or 'print' in GDB? IIRC + print may throw such message, but x may not + bt + x may too + what you're showing looks like an utf-8 string + c385 is Å + 83 is a special f + 82 is a comma + so the stack is corrupted:-( + probably + well, certainly + but gdb should show you where the program counter is + is that: ECX: the count register + no + eip + program counter == instruction pointer + k!, the program counter is at first entry in bt: #0 0x01082612 + in _hurd_intr_rpc_msg_in_trap () at intr-msg.c:133 + this is the hurd interruptible version of mach_msg + so it probably means the corruption was made by a signal handler + which is one of the reasons why gdb can't handle Ctrl-c + what to do in such a case, follow the source code + single-stepping? + single stepping also uses signals + and using printf will probably create an infinite recursion + in those cases, i use mach_print + as a first step, you could make sure a signal is actually received + and which one + hmm + also, before rushing into conclusions, make sure you're looking at + the right thread + i don't expect localedef to be multithreaded + but gdb sometimes just doesn't get the thread where the segfault + actually occurred + two threads: 1095.4 and 1095.5 (created when starting localedef + in gdb) + no, at the time of the crash + the second thread is always the signal thread + OK,in gdb the program hangs, interrupted by C-c, outside it + segfaults + when you use bt to get the corrupted stack, you can also use info + threads and thread apply all bt + I did: http://paste.debian.net/61170/ + ok so it confirms there is only one real application thread, the + main one + and that the corruption probably occurs during signal handling + rpctrace (edited out non-printable characters): + http://paste.debian.net/61178/ + Ah, have to do it again as root;-) + yes .. :p + new last part: http://paste.debian.net/61181/ + so, there is a seek, then a stat, then a close perhaps (port + deallocation) and then a signal received (probably sigsegv) + gnu_srs: when you try running it in gdb, do you get a sigkill ? + damn, gdb on darnassus is bugged :-( + It hangs, interrupted with C-c. + ok diff --git a/open_issues/git-core-2.mdwn b/open_issues/git-core-2.mdwn index cbf47bd2..a92b3ebb 100644 --- a/open_issues/git-core-2.mdwn +++ b/open_issues/git-core-2.mdwn @@ -61,6 +61,113 @@ Fixing this situation is easy enough: Still seen. +## IRC, freenode, #hurd, 2013-10-10 + + Huh? I've cloned the 'hurd' repository and I'm attempting to compile + it, but the 'rtnetlink.h' header in + 'hurd/pfinet/linux-src/include/linux/' is just blank. (Which leads to an + error later down when a macro that's supposed to be defined in there is + first used) + So I'm just wondering, is that file really blank? Or is this some + unexpected error of decompression? + clone again and see + the file is definitely not empty + I cloned it twice, both have that file blank. BUT, I want to point + out that both clones do have some decompression errors. (Some files are + missing chunks in /both/ cloned repositories). + where did you clone it from ? + git.sv.gnu.org/hurd/hurd.git + hum decompression errors ? + can you paste them please ? + Hmm, I can clone again and show you an example if I find one + This was on the hurd. When I run: git clone $repo;, it seems to fail + almost randomly with "incorrect header check", but when it does succeed, + occasionally some files are missing chunks + and apparently entire files can be blank + http or git ? + git. + that's really weird + actually i don't even have problems with http any more nowadays .. + This is using the hurd image from sthibault + So once I get it recompiled and shuffle in the new binaries, the + problem should probably go away + no + well maybe but + don't recompile + upgrade packages instead + Alright, I'll do an upgrade instead. Why that path specifically? + rebuilding is long + i wonder if the image you got is corrupted + compute the checksum + we've had weird reports in the past about the images he provides + well not the images themselves, but differences after dowloading + .. + downloading* + The MD5SUMS file on his site isn't including the values for the most + recent images. + It stops at 2012-12-28 + hummm + Anyway, let's see. git clone failed again: + Receiving objects: 100% (50955/50955), 15.48 MiB | 42 KiB/s, done. + error: inflate: date stream error (incorrect header check) <- This + is the interesting part + fatal: serious inflate inconsistency + fatal: index-pack failed + not intereseting enough unfortunately + but it might come from savannah too + try the mirrors at + http://darnassus.sceen.net/gitweb/?a=project_list;pf=savannah_mirror + Let's see..if I try: 'git clone + git://darnassus.sceen.net/gitweb/savannah_mirror/hurd.git', I get: + 'fatal: remote error: access denied or repository not exported: + /gitweb/savannah_mirror/hurd.git' + my bad + that's weird, it should work .. + oh, stupid translation error + translation? From one human language to another? + not translation actually + typo :) + it's either + git://darnassus.sceen.net/savannah_mirror/hurd.git + or + http://darnassus.sceen.net/gitweb/savannah_mirror/hurd.git + copy paste the url exactly please + /gitweb/ is only present in the http url + Ah, right. Okay, I'll paste it exactly + Ehm. The whole thing locked up badly. I'll reboot it and try again. + are you sure it locked oO ? + the hurd can easily become unresponsive when performing io + operations + but you need more than such a git repository to reach that state + Yeah, that happens occasionally. It's not related to git, but rather + it happens when I cancel some command. + your image must be corrupted + have you enabled host io caching btw ? + By now it's corrupted for sure..everytime it crashes the filesystem + gets into a weird state. + I'll unpack a fresh image, then update the packages, and then try + cloning this git repository. + i'll get the image too so we can compare sums + 957bb0768c9558564f0c3e0adb9b317e ./debian-hurd.img.tar.gz + Which unpacks to: debian-hurd-20130504.img + the NSA might backdoor the Hurd, in anticipation of our scheduled + world-dominance + for now they're doing it passively : + :p + sea`: same thing here + sea`: if you still have problems, the image itself might be wrong + in which case you should try with the debian network installer + Ah, so if problems persist, try with the network installer. Okay + Is there some recipe for constructing a hurd/mach minimal + environment? + A system with only just enough tools and libraries to compile and + poke at things. + not currently + we all work in debian environments + the reason being that a lot of patches are queued for integration + upstream + + # 2010-11-17 A very similar issue. The working tree had a lot of diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn index b453b44f..292c6256 100644 --- a/open_issues/glibc.mdwn +++ b/open_issues/glibc.mdwn @@ -330,6 +330,33 @@ Last reviewed up to the [[Git mirror's 0323d08657f111267efa47bd448fbf6cd76befe8 clearly not a priority ok + IRC, freenode, #hurd, 2013-09-26: + + if I want to have epoll/kqueue like things, where + should it dwell? kernel or some libs? + libs + userland + 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 + 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) + while keeping the existing way working for some time + glibc implements select + the hurd io interface shows the select interface + servers such as pfinet/pflocal implement it + glibc implements the client-side of the call + where's poll? since epoll just added edge-trigger in + poll + both select and poll are implemented on top of the hurd io + select call (which isn't exactly select) + + http://darnassus.sceen.net/gitweb/savannah_mirror/hurd.git/blob/HEAD:/hurd/io.defs + this is the io interface + + http://darnassus.sceen.net/gitweb/savannah_mirror/glibc.git/blob/refs/heads/tschwinge/Roger_Whittaker:/hurd/hurdselect.c + this is the client side implementation + * `sys/eventfd.h` * `sys/inotify.h` @@ -854,6 +881,298 @@ Last reviewed up to the [[Git mirror's 0323d08657f111267efa47bd448fbf6cd76befe8 to check where those locks are held and determine the right order + IRC, OFTC, #debian-hurd, 2013-09-28: + + now we'd just need tls + http://bugs.ruby-lang.org/issues/8937 + 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: + + so what is missing for ruby2.0, only disabling use of + context for now, no? + i'm not tracking it closely, gg0_ is + maybe terceiro would accept a patch which only disables + *context, "maybe" because he rightly said changes must go + upstream + 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 + 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 + about tests, current ruby2.0 doesn't run makecheckall, only + makecheck which succeeds on hurd (w/o context) + if anyone wants to give it a try: + http://paste.debian.net/plain/51089 + first hunk makes makecheck (not makecheckall) succeed and + has been upstreamed, not packaged yet + what about makecheckall for ruby2.0? + 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 + i for a moment thought it as for 1.9.1, ok + these hangs should be debugged, yes + 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 + yep a smart mind could start debugging them, starting from + patch above pasted by a lazy one owner + one problem is that one can't reproduce them by isolate + them, they don't fail. start makecheckall then wait for one fail + 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 + ) + and fix them all + + 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 + gg0_: I don't really know what to answer + that's why I didn't answer :) + 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 + that can be a plan yes + btw reverting it upstream should not be a problem eventually + sure, the thing is remembering to do it + filed http://bugs.ruby-lang.org/issues/8990 + please don't fix tls too soon :) + s/makecheck/maketest/g + + IRC, OFTC, #debian-hurd, 2013-10-08: + + ok. *context disabled http://bugs.ruby-lang.org/issues/8990 + + bt full of an attached stuck ruby test + http://paste.debian.net/plain/53788/ + anything useful? + uh, is that really all? + there's not much interesting unfortunately + did you run thread apply all bt full ? + (not just bt full) + no just bt full + http://paste.debian.net/plain/53790/ + wait, there's a child + damn ctrl-c'ing while it was loading symbols made it crash :/ + restarted testsuite + isn't it interesting that failed tests fail only if testsuite + runs from beginning, whereas if run singularly, they succeed? + as it got out of whatever resources + youpi: http://paste.debian.net/plain/53798/ + the interesting part is actually right at the top + it's indeed stuck in the critical section spinlock + question being what is keeping it + 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 + (I did find some missing paths, which I fixed) + 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 + yes, but the issue we were discussing there is not what + happens here + we would see another thread stuck in the other way roudn, + otherwise + no way to get what is locking? + no, that's not recorded + and what about writing it somewhere right after getting the + lock? + one will have to do that in all spots taking that lock + but yes, that's the usual approach + i would give it try but eglibc rebuild takes too much time, + that conflicts with my laziness + i read even making locks timed would help + + IRC, OFTC, #debian-hurd, 2013-10-09: + + so correct order would be: + __spin_lock (&ss->lock); // locks sigstate + __spin_lock (&ss->critical_section_lock); + [do critical stuff] + __spin_unlock (&ss->critical_section_lock); + __spin_unlock (&ss->lock); // unlocks sigstate + ? + + 21:44 < gg0> terceiro: backported to 2.0 (backport to 1.9 is + waiting) https://bugs.ruby-lang.org/issues/9000 + 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) + 21:48 < terceiro> gg0: nice + 21:48 < terceiro> I will try to upload a snapshot as soon as + I can + 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 :) + + would it be a problem granting me access to a porter box to + rebuild eglibc+ruby2.0? + i'm already doing it on another vm but host often loses power + you cannot install random stuff on a porterbox though + i know i'd just need build-deps of eglibc+ruby2.0 i guess + (already accessed to porter machines in the past, account + lele, mips iirc) + ldap should remember that + don't want to disturb anyone else work btw. if it's not a + problem, nice. otherwise no problem + please send a request to admin@exodar.debian.net so it + is not forgotten + following this one would be too "official"? + http://dsa.debian.org/doc/guest-account/ + hurd is not a release architecture, so hurd machines are + not managed by DSA + ok + the general procedure outlines is ok though, just need + to be sent to the address above + sent + (1st signed mail with mutt, in the worst case i've attached + passphrase :)) + gg0: could you send me an ssh key? + no alioth account? + yes, but EPERM + youpi: sent to youpi@ + youpi@ ? + (... which doesn't exist :/) + sthibault@ + please test gg0-guest@exodar.debian.net ? + (I'd rather not adduser the ldap name, who knows what might + happen when you get your DD account) + i'm in. thanks + you're welcome + ldap users need to be adduser'ed? + I'm not getting your ldap user account from ud-replicate, + at least + (btw i never planned to apply nm, i'd be honoured but i + simply think not to deserve it) + never say never ;) + bah i like failing. that would be a success. i can't :) + gg0-guest@exodar:~$ dchroot + E: Access not authorised + I: You do not have permission to access the schroot service. + I: This failure will be reported. + ah, right, iirc I need to add you somewhere + gg0: please retry? + works + good + are there already eglibc+ruby2.0 build-deps? + yes + oh that means i should do something myself now :) + yep, that had to happen at some point :) + my laziness thanks: "at some point" is better than "now" :) + + IRC, freenode, #hurd, 2013-10-10: + + ok just reproduced the + former. ../sysdeps/mach/hurd/jmp-unwind.c:53 waits + 20:37 < braunr> gg0: does ruby create and destroy threads + ? + no idea + braunr: days ago you and youpi talked about locking order + (just before this anchor + http://darnassus.sceen.net/~hurd-web/open_issues/glibc/#recvmmsg) + oh right + could you submit the fix for jmp-unwind.c to + upstream? + it didn't made it in the todo list + so correct order is in hurd_thread_cancel, right? + sorry about that + we need to make a pass to make sure it is + that means locking first ss->critical_section_lock _then_ + ss->lock + correct? + but considering how critical hurd_thread_cancel is, i + expect so + + i get the same deadlock by swapping locks + braunr: youpi: fyi ^ + 20:51 < braunr> 20:37 < braunr> gg0: does ruby create and + destroy threads ? + how could i check it? + gg0: ps -eflw + gg0: that's not surprising, since in the b acktrace you + posted there isn't another thread locked in the other order + so it's really that somehow the thread is already in + critical sesction + youpi: you mean there is ? + ah, it's not the same bug + no, in what he posted, no other thread is stuck + so it's not a locking order + just that the critical section is actually busy + youpi: ack + braunr: what's the other bug? ext2fs one? + gg0: idk + braunr: thanks. doesn't show threads (found -T for that) but + at least doesn't limit columns number if piped (thanks to -w) + it does + there is a TH column + ok thread count. -T gives more info + + IRC, freenode, #hurd, 2013-10-24: + + ruby2.0 builds fine with the to-be-uploaded libc btw + youpi: without d-ports patches? surprise me :) + gg0: plain main archive source + you did it. surprised + ah ok you just pushed your tls. great! + tls will fix a lot of things + + * `sigaltstack` + + IRC, freenode, #hurd, 2013-10-09: + + Hi, is sigaltstack() really supported, even if it is + defined as well as SA_ONSTACK? + probably not + well, + i don't know actually, mistaking with something else + it may be supported + iirc no + pinotree: are you sure? + this is what i remember + if you want to be sure that $foo works, just do the + usual way: test it yourself + found it: hurd/TODO: *** does sigaltstack/sigstack + really work? -- NO + 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 + in any case, test it + anybody fluent in assembly? Looks like this code + destroys the stack: http://paste.debian.net/54331/ + gnu_srs1: why would it ? + 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) + Well, in that case it is the called function: + http://paste.debian.net/54341/ + how do you know there is a problem with the stack in the + first place ? + tracing up to here, everything is OK. then esp and ebp + are destroyed. + and single stepping goes backward until it segfaults + "destroyed" ? + zero if I remember correctly now. the x86 version built + for is i586, should that be changed to i486? + this shouldn't change anything + and they shouldn't get to 0 + use gdb to determine exactly which instruction resets the + stack pointer + how to step into the assembly part? using 's' steps + through the function since no line information: + Single stepping until exit from function + wine_call_on_stack, + which has no line number information. + gnu_srs1: use break on the address + how do i get the address of where the assembly starts? + * `recvmmsg`/`sendmmsg` (`t/sendmmsg`) From [[!message-id "20120625233206.C000A2C06F@topped-with-meat.com"]], diff --git a/open_issues/glibc/t/tls-threadvar.mdwn b/open_issues/glibc/t/tls-threadvar.mdwn index 7ce36f41..40d1463e 100644 --- a/open_issues/glibc/t/tls-threadvar.mdwn +++ b/open_issues/glibc/t/tls-threadvar.mdwn @@ -116,3 +116,40 @@ dropped altogether, and `__thread` directly be used in glibc. ## IRC, OFTC, #debian-hurd, 2013-09-23 yay, errno threadvar conversion success + + +## IRC, OFTC, #debian-hurd, 2013-10-05 + + youpi: any ETA for tls? + gg0_: one can't have an ETA for bugfixing + i don't call them bugs if there's something missing to implement btw + no, here it's bugs + the implementation is already in the glibc branches in our + repository + it just makes some important regressions + + +## IRC, OFTC, #debian-hurd, 2013-10-07 + + about tls, I've made some "progress": now I'm wondering how raise() + has ever been working before :) + + +## IRC, OFTC, #debian-hurd, 2013-10-15 + + good, reply_port tls is now ok + last but not least, sigstate + + +## IRC, OFTC, #debian-hurd, 2013-10-21 + + started testsuite with threadvars dropped completely + so far so good + + +## IRC, OFTC, #debian-hurd, 2013-10-24 + + ok, hurd boots with full-tls libc, no threadvars at all any more + \o/ + good bye threadvars bugs, welcome tls ones ;) + now I need to check that threads can really use another stack :) diff --git a/open_issues/gnumach_page_cache_policy.mdwn b/open_issues/gnumach_page_cache_policy.mdwn index 5e93887e..77e52ddb 100644 --- a/open_issues/gnumach_page_cache_policy.mdwn +++ b/open_issues/gnumach_page_cache_policy.mdwn @@ -811,3 +811,63 @@ License|/fdl]]."]]"""]] have* and even if laggy, it doesn't feel much more than the usual lag of a network (ssh) based session + + +# IRC, freenode, #hurd, 2013-10-08 + + hmm i have to change what gnumach reports as being cached memory + + +## IRC, freenode, #hurd, 2013-10-09 + + mhmm, i'm able to copy files as big as 256M while building debian + packages, using a gnumach kernel patched for maximum memory usage in the + page cache + just because i used --sync=30 in ext2fs + a bit of swapping (around 40M), no deadlock yet + gitweb is a bit slow but that's about it + that's quite impressive + i suspect thread storms might not even be the cataclysmic event + that we thought it was + the true problem might simply be parallel fs synces + + +## IRC, freenode, #hurd, 2013-10-10 + + even with the page cache patch, memory filled, swap used, and lots + of cached objects (over 200k), darnassus is impressively resilient + i really wonder whether we fixed ext2fs deadlock + + youpi: fyi, darnassus is currently running a patched gnumach with + the vm cache changes, in hope of reproducing the assertion errors we had + in the past + i increased the sync interval of ext2fs to 30s like we discussed a + few months back + and for now, it has been very resilient, failing only because of + the lack of kernel map entries after several heavy package builds + wait the latter wasn't a deadlock it resumed after 1363.06 s + gg0: thread storms can sometimes (rarely) fade and let the system + resume "normally" + which is why i increased the sync interval to 30s, this leaves + time between two intervals for normal operations + otherwise writebacks are queued one after the other, and never + processed fast enough for that queue to become empty again (except + rarely) + youpi: i think we should consider applying at least the sync + interval to exodar, since many DDs are just unaware of the potential + problems with large IOs + sure + + 222k cached objects (1G of cached memory) and darnassus is still + kicking :) + youpi: those lock fixing patches your colleague sent last year + must have helped somewhere + :) + + +## IRC, freenode, #hurd, 2013-10-13 + + braunr: how are your tests going with the object cache? + youpi: not so good + youpi: it failed after 2 days of straight building without a + single error output :/ diff --git a/open_issues/hurd_101.mdwn b/open_issues/hurd_101.mdwn index 574a03ec..25822512 100644 --- a/open_issues/hurd_101.mdwn +++ b/open_issues/hurd_101.mdwn @@ -60,3 +60,41 @@ Not the first time that something like this is proposed... how ipc works and understand exactly what state is stored where ok + + +# IRC, freenode, #hurd, 2013-10-12 + + Hi all, can anyone expand on + https://www.gnu.org/software/hurd/contributing.html - if I proceed with + the quick start and have the system running in a virtual image, how do I + go from there to being able to start tweaking the source (and recompiling + ) in a meaningful way? + Would I modify the source, compile within the VM and then what + would be the next step to actually test my new changes? + ahungry: we use debian + i suggest formatting your changes into patches, importing them + into debian packages, rebuilding those packages, and installing them over + the upstream ones + what about modifications to mach itself? or say I wanted to try + to work on the wifi drives - I would build the translator or module or + whatever and just add to the running instance of hurd? + s/drives/drivers + same thing + although + during development, it's obviously a bit too expensive to rebuild + complete packages each time + you can use the hurd on top of a gnumach kernel built completely + from upstream sources + you need a few debian patches for the hurd itself + a lot of them for glibc + i usually create a temporary local branch with the debian patches + i need to make my code run + and then create the true development branch itself from that one + drivers are a a dark corner of the hurd + i wouldn't recommend starting there + but if you did, yes, you'd write a server to run drivers, and + start it + you'd probably write a translator (which is a special kind of + server), yes + braunr: thanks for all the info, hittin the sack now but ill have + to set up a box and try to contribute diff --git a/open_issues/hurd_init.mdwn b/open_issues/hurd_init.mdwn index b0b58a70..cc06935c 100644 --- a/open_issues/hurd_init.mdwn +++ b/open_issues/hurd_init.mdwn @@ -214,3 +214,11 @@ License|/fdl]]."]]"""]] I've been hacking on init/startup, I've looked into cleaning it up + + +## IRC, freenode, #hurd, 2013-10-07 + + braunr: btw, what do you think of my /hurd/startup proposal? + i haven't read it in detail yet + it's about separating init right ? + yes diff --git a/open_issues/libpthread/t/fix_have_kernel_resources.mdwn b/open_issues/libpthread/t/fix_have_kernel_resources.mdwn index 6f09ea0d..feea7c0d 100644 --- a/open_issues/libpthread/t/fix_have_kernel_resources.mdwn +++ b/open_issues/libpthread/t/fix_have_kernel_resources.mdwn @@ -413,3 +413,67 @@ Address problem mentioned in [[/libpthread]], *Threads' Death*. oh, git is multithreaded great so i've actually tested my libpthread patch quite a lot + + +## IRC, freenode, #hurd, 2013-09-25 + + on a side note, i was able to build gnumach/libc/hurd packages + with thread destruction + nice :) + they boot and work mostly fine, although they add their own issues + e.g. the comm field of the root ext2fs is empty + ps crashes when trying to display threads + but thread destruction actually works, i.e. servers (those that + are configured that away at least) go away after some time, and even + heavily used servers such as ext2fs dynamically scale over time :) + + +## IRC, freenode, #hurd, 2013-10-10 + + concerning threads, i think i figured out the last bugs i had with + thread destruction + it should be well on its way to be merged by the end of the year + + +## IRC, freenode, #hurd, 2013-10-11 + + braunr: is your thread destruction patch ready for testing? + gg0: there are packages at my repository, yes + but i still have hurd fixes to do before i polish it + in particular, posix says returning from main() stops the entire + process and all other threads + i didn't check that during the switch to pthreads, and ext2fs (and + maybe others) actually return from main but expect other threads to live + on + this creates problems when the main thread is actually destroyed, + but not the process + braunr: tmpfs does something like that, but calls pthread_exit + at the end of main + same effect + this was fine with cthreads, but must be changed with pthreads + and libpthread must be fixed to enforce it + (or libc) + + diskfs_startup_diskfs should probably be changed to reuse the main + thread instead of returning + + +## IRC, freenode, #hurd, 2013-10-19 + + I know what threads are, but what is 'thread destruction'? + the hurd currently never destroys individual threads + they're destroyed when tasks are destroyed + if the number of threads in a task peaks at a high number, say + thousands of them, they'll remain until the task is terminated + such tasks are usually file systems, normally never restarted (and + in the case of the root file system, not restartable) + this results in a form of leak + another effect of this leak is that servers which should go away + because of inactivity still remain + since thread destruction doesn't actually work, the debian package + uses a patch to prevent worker threads from timeouting + and to finish with, since thread destruction actually doesn't + work, normal (unpatched) applications that destroy threads are certainly + failing bad + i just need to polish a few things, wait for youpi to finish his + work on TLS to resolve conflicts, and that will be all diff --git a/open_issues/lsof.mdwn b/open_issues/lsof.mdwn index 2cbf2302..2651932d 100644 --- a/open_issues/lsof.mdwn +++ b/open_issues/lsof.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2013 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -11,3 +11,41 @@ License|/fdl]]."]]"""]] We don't have a `lsof` tool. Perhaps we could cook something with having a look at which ports are open at the moment (as [[`portinfo`|hurd/portinfo]] does, for example)? + + +# IRC, freenode, #hurd, 2013-10-16 + + braunr: there's something I've been working on, it's not yet + finished but usable + http://paste.debian.net/58266/ + it graphs port usage + it's a bit heavy on the dependency-side though... + but + is it able to link rights from different ipc spaces ? + no + what do you mean exactly? + know that send right 123 in task 1 refers to receive right 321 in + task 2 + basically, lsof + i'm not sure it's possible right now, and that's what we'd really + need + does the kernel hand out this information? + ^ + right, I'm not sure it's possible either + but a graph maker in less than 300 is cute :) + 300 lines* + well, it leverages pymatplotlib or something, it needs half of + the pythonverse ;) + lsof and pmap and two tools we really lack on the hurd + what does portinfo --translate=PID do? + i guess it asks proc so that ports that refer to task actually + give useful info + hml + no + doesn't make sense to give a pid in this case + teythoon: looks like it does what we talked about + :) + teythoon: the output looks a bit weird anyway, i think we need to + look at the code to be sure + braunr: this is what aptitude update looks like: + https://teythoon.cryptobitch.de/portmonitor/aptitude_portmonitor.svg diff --git a/open_issues/mach-defpager_swap.mdwn b/open_issues/mach-defpager_swap.mdwn index 7d3b001c..6e4dc088 100644 --- a/open_issues/mach-defpager_swap.mdwn +++ b/open_issues/mach-defpager_swap.mdwn @@ -18,3 +18,24 @@ License|/fdl]]."]]"""]] I allocated a 5GB partition as swap, but hurd only found 1GB use 2GiB swaps only, >2Gib are not supported (and apparently it just truncates the size, to be investigated) + +## IRC, freenode, #hurd, 2013-10-25 + + mkswap truncated the swap partiton to 2GB + :/ + have you checked with 'free' ? + I have a 4gb swap partition on one of my boxes + how did you create it? + 2gig swap alright + according to free + + +# Swap Files + +## IRC, freenode, #hurd, 2013-10-25 + + C-Keen: swapfiles are not to work very badly on the hurd + swapfiles cause recursion and reservation problems on every system + but on the hurd, we just never took the time to fix the swap code + +Same issues as we generally would have with `hurd-defpager`? diff --git a/open_issues/multiprocessing.mdwn b/open_issues/multiprocessing.mdwn index 0ac7f195..eaaa2289 100644 --- a/open_issues/multiprocessing.mdwn +++ b/open_issues/multiprocessing.mdwn @@ -17,7 +17,7 @@ for applying multiprocessing. That is, however, only true from a first and inexperienced point of view: there are many difficulties. -IRC, freenode, #hurd, August / September 2010 +# IRC, freenode, #hurd, August / September 2010 silver_hook: because multi-server systems depend on inter-process communication, and inter-process communication is many times more @@ -32,7 +32,7 @@ IRC, freenode, #hurd, August / September 2010 serious research challenges -IRC, freenode, #hurd, 2011-07-26 +# IRC, freenode, #hurd, 2011-07-26 < braunr> 12:03 < CTKArcher> and does the hurd take more advantages in a multicore architecture than linux ? @@ -57,7 +57,7 @@ IRC, freenode, #hurd, 2011-07-26 < braunr> (here, thread migration means being dispatched on another cpu) -debian-hurd list +# debian-hurd list On Thu, Jan 02, 2003 at 05:40:00PM -0800, Thomas Bushnell, BSG wrote: > Georg Lehner writes: diff --git a/open_issues/performance.mdwn b/open_issues/performance.mdwn index ae05e128..772fd865 100644 --- a/open_issues/performance.mdwn +++ b/open_issues/performance.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation, +[[!meta copyright="Copyright © 2010, 2011, 2012, 2013 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -44,6 +44,8 @@ call|/glibc/fork]]'s case. * [[metadata_caching]] + * [[community/gsoc/project_ideas/object_lookups]] + --- diff --git a/open_issues/performance/io_system/read-ahead.mdwn b/open_issues/performance/io_system/read-ahead.mdwn index cd39328f..05a58f2e 100644 --- a/open_issues/performance/io_system/read-ahead.mdwn +++ b/open_issues/performance/io_system/read-ahead.mdwn @@ -3031,3 +3031,13 @@ License|/fdl]]."]]"""]] so, add? if that's what you want to do, ok i'll think about your initial question tomorrow + + +## IRC, freenode, #hurd, 2013-09-30 + + talking about which... did the clustered I/O work ever get + concluded? + antrik: yes, mcsim was able to finish clustered pageins, and it's + still on my TODO list + it will get merged eventually, now that the large store patch has + also been applied diff --git a/open_issues/performance/microkernel_multi-server.mdwn b/open_issues/performance/microkernel_multi-server.mdwn index 111d2b88..0382c835 100644 --- a/open_issues/performance/microkernel_multi-server.mdwn +++ b/open_issues/performance/microkernel_multi-server.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011, 2013 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -12,7 +12,8 @@ License|/fdl]]."]]"""]] Performance issues due to the microkernel/multi-server system architecture? -IRC, freenode, #hurd, 2011-07-26 + +# IRC, freenode, #hurd, 2011-07-26 < CTKArcher> I read that, because of its microkernel+servers design, the hurd was slower than a monolithic kernel, is that confirmed ? @@ -45,3 +46,181 @@ IRC, freenode, #hurd, 2011-07-26 < braunr> but in 95, processors weren't that fast compared to other components as they are now < youpi> while disk/mem haven't evovled so fast + + +# IRC, freenode, #hurd, 2013-09-30 + + ok.. i noticed when installing debian packages in X, the mouse + lagged a little bit + that takes me back to classic linux days + it could be a side effect of running under virtualisation who + knows + no + it's because of the difference of priorities between server and + client tasks + is it simple enough to increase the priority of the X server? + it does remind me of the early linux days.. people were more + interested in making things work, and making things not crash.. than + improving the desktop interactivity or responsiveness + very low priority :P + snadge: actually it's not the difference in priority, it's the + fact that some asynchronous processing is done at server side + the priority difference just gives more time overall to servers + for that processing + snadge: when i talk about servers, i mean system (hurd) servers, + no x + yeah.. linux is the same.. in the sense that, that was its + priority and focus + snadge: ? + servers + what are you talking about ? + going back 10 years or so.. linux had very poor desktop + performance + i'm not talking about priorities for developers + it has obviously improved significantly + i'm talking about things like nice values + right.. and some of the modifications that have been done to + improve interactivity of an X desktop, are not relevant to servers + not relevant at all since it's a hurd problem, not an x problem + yeah.. that was more of a linux problem too, some time ago was the + only real point i was making.. a redundant one :p + where i was going with that.. was desktop interactivity is not a + focus for hurd at this time + it's not "desktop interactivity" + it's just correct scheduling + is it "correct" though.. the scheduler in linux is configurable, + and selectable + depending on the type of workload you expect to be doing + not really + it can be interactive, for desktop loads.. or more batched, for + server type loads.. is my basic understanding + no + that's the scheduling policy + the scheduler is cfs currently + and that's the main difference + cfs means completely fair + whereas back in 2.4 and before, it was a multilevel feedback + scheduler + i.e. a scheduler with a lot of heuristics + the gnumach scheduler is similar, since it was the standard + practice from unix v6 at the time + (gnumach code base comes from bsd) + so 1/ we would need a completely fair scheduler too + and 2/ we need to remove asynchronous processing by using mostly + synchronous rpc + im just trying to appreciate the difference between async and sync + event processing + on unix, the only thing asynchronous is signals + on the hurd, simply cancelling select() can cause many + asynchronous notifications at the server to remove now unneeded resources + when i say cancelling select, i mean one or more fds now have + pending events, and the others must be cleaned + yep.. thats a pretty fundamental change though isnt it? .. if im + following you, you're talking about every X event.. so mouse move, + keyboard press etc etc etc + instead of being handled async.. you're polling for them at some + sort of timing interval? + never mind.. i just read about async and sync with regards to rpc, + and feel like a bit of a noob + async provides a callback, sync waits for the result.. got it :p + async is resource intensive on hurd for the above mentioned + reasons.. makes sense now + how about optimising the situation where a select is cancelled, + and deferring the signal to the server to clean up resources until a + later time? + so like java.. dont clean up, just make a mess + then spend lots of time later trying to clean it up.. sounds like + my life ;) + reuse stale objects instead of destroying and recreating them, and + all the problems associated with that + but if you're going to all these lengths to avoid sending messages + between processes + then you may as well just use linux? :P + im still trying to wrap my head around how converting X to use + synchronous rpc calls will improve responsiveness + what has X to do with it? + nothing wrong with X.. braunr just mentioned that hurd doesnt + really handle the async calls so well + there is more overhead.. that it would be more efficient on hurd, + if it uses sync rpc instead + and perhaps a different task scheduler would help also + ala cfs + but i dont think anyone is terribly motivated in turning hurd into + a desktop operating system just yet.. but i could be wrong ;) + i didn't say that + i misinterpreted what you said then .. im not surprised, im a + linux sysadmin by trade.. and have basic university OS understanding (ie + crap all) at a hobbyist level + i said there is asynchronous processing (i.e. server still have + work to do even when there is no client) + that processing mostly comes from select requests cancelling what + they installed + ie.e. you select fd 1 2 3, even on 2, you cancel on 1 and 3 + those cancellations aren't synchronous + the client deletes ports, and the server asynchronously receives + dead name notifications + since servers have a greater priority, these notifications are + processed before the client can continue + which is what makes you feel lag + X is actually a client here + when i say server, i mean hurd servers + the stuff implementing sockets and files + also, you don't need to turn the hurd into a desktop os + any correct way to do fair scheduling will do + can the X client be made to have a higher priority than the hurd + servers? + or perhaps something can be added to hurd to interface with X + well, the future is wayland + ufs .. unfair scheduling.. give priority to X over everything else + hurd almost seams ideal for that idea.. since the majority of the + system is seperated from the kernel + im likely very wrong though :p + snadge: the reason we elevated the priority of servers is to avoid + delaying the processing of notifications + because each notification can spawn a server thread + and this lead to cases where processing notifications was so slow + that spawning threads would occur more frequently, leading to the server + exhausting its address space because of thread stacks + cant it wait for X though? .. or does it lead to that situation + you just described + we should never need such special cases + we should remove async notifications + my logic is this.. if you're not running X then it doesnt + matter.. if you are, then it might.. its sort of up to you whether you + want priority over your desktop interface or whether it can wait for more + important things, which creates perceptible lag + snadge: no it doesn't + X is clearly not the only process involved + the whole chain should act synchronously + from the client through the server through the drivers, including + the file system and sockets, and everything that is required + it's a general problem, not specific to X + right.. from googling around, it looks like people get very + excited about asyncronous + there was a move to that for some reason.. it sounds great in + theory + continue processing something else whilst you wait for a + potentially time consuming process.. and continue processing that when + you get the result + its also the only way to improve performance with parallelism? + which is of no concern to hurd at this time + snadge: please don't much such statements when you don't know what + you're talking about + it is a concern + and yes, async processing is a way to improve performance + but don't mistake async rpc and async processing + async rpc simply means you can send and receive at any time + sync means you need to recv right after send, blocking until a + reply arrives + the key word here is *blocking*ù + okay sure.. that makes sense + what is the disadvantage to doing it that way? + you potentially have more processes that are blocking? + a system implementing posix such as the hurd needs signals + and some event handling facility like select + implementing them synchronously means a thread ready to service + these events + the hurd currently has such a message thread + but it's complicated and also a scalability concern + e.g. you have at least two thread per process + bbl diff --git a/open_issues/pthread_atfork.mdwn b/open_issues/pthread_atfork.mdwn index 1b656f05..06b9d6c6 100644 --- a/open_issues/pthread_atfork.mdwn +++ b/open_issues/pthread_atfork.mdwn @@ -18,3 +18,89 @@ can probably be borrowed from `nptl/sysdeps/unix/sysv/linux/register-atfork.c`. SRCDIR/opal/mca/memory/linux/arena.c:387: warning: warning: pthread_atfork is not implemented and will always fail + + +# Samuel's implementation + +TODO. + + +## IRC, OFTC, #debian-hurd, 2013-10-08 + + youpi: if you need/want to test your pthread_atfork + implementation, you can check libposix-atfork-perl and its test suite + (whose test 004 hangs now, with eglibc -93) + while it failed previously indeed + we might simply need to rebuild perl against it + (I see ifdef pthread_atfork in perl) + + +## IRC, freenode, #hurd, 2013-10-16 + + tschwinge: I'd love to try your cross-gnu tool, the wiki page + suggests that the list of required source packages is outdated. can you + give me some hints? + tschwinge: I got this error running cross-gnu: + http://paste.debian.net/58303/ + make[4]: Leaving directory `/home/teythoon/repos/hurd/cross/src/glibc/setjmp' + make subdir=string -C ../string ..=../ objdir=/home/teythoon/repos/hurd/cross/obj/glibc -f Makefile -f ../elf/rtld-Rules rtld-all rtld-modules='rtld-strchr.os rtld-strcmp.os rtld-strcpy.os rtld-strlen.os rtld-strnlen.os rtld-memchr.os rtld-memcmp.os rtld-memmove.os rtld-memset.os rtld-mempcpy.os rtld-stpcpy.os rtld-memcpy.os rtld-rawmemchr.os rtld-argz-count.os rtld-argz-extract.os rtld-stpncpy.os' + make[4]: Entering directory `/home/teythoon/repos/hurd/cross/src/glibc/string' + make[4]: Leaving directory `/home/teythoon/repos/hurd/cross/src/glibc/string' + make[4]: Entering directory `/home/teythoon/repos/hurd/cross/src/glibc/string' + make[4]: Nothing to be done for `rtld-all'. + make[4]: Leaving directory `/home/teythoon/repos/hurd/cross/src/glibc/string' + make[3]: Leaving directory `/home/teythoon/repos/hurd/cross/src/glibc/elf' + i686-pc-gnu-gcc -shared -static-libgcc -Wl,-O1 -Wl,-z,defs -Wl,-dynamic-linker=/lib/ld.so.1 -B/home/teythoon/repos/hurd/cross/obj/glibc/csu/ -Wl,--version-script=/home/teythoon/repos/hurd/cross/obj/glibc/libc.map -Wl,-soname=libc.so.0.3 -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both -nostdlib -nostartfiles -e __libc_main -L/home/teythoon/repos/hurd/cross/obj/glibc -L/home/teythoon/repos/hurd/cross/obj/glibc/math -L/home/teythoon/repos/hurd/cross/obj/glibc/elf -L/home/teythoon/repos/hurd/cross/obj/glibc/dlfcn -L/home/teythoon/repos/hurd/cross/obj/glibc/nss -L/home/teythoon/repos/hurd/cross/obj/glibc/nis -L/home/teythoon/repos/hurd/cross/obj/glibc/rt -L/home/teythoon/repos/hurd/cross/obj/glibc/resolv -L/home/teythoon/repos/hurd/cross/obj/glibc/crypt -L/home/teythoon/repos/hurd/cross/obj/glibc/mach -L/home/teythoon/repos/hurd/cross/obj/glibc/hurd -Wl,-rpath-link=/home/teythoon/repos/hurd/cross/obj/glibc:/home/teythoon/repos/hurd/cross/obj/glibc/math:/home/teythoon/repos/hurd/cross/obj/glibc/elf:/home/teythoon/repos/hurd/cross/obj/glibc/dlfcn:/home/teythoon/repos/hurd/cross/obj/glibc/nss:/home/teythoon/repos/hurd/cross/obj/glibc/nis:/home/teythoon/repos/hurd/cross/obj/glibc/rt:/home/teythoon/repos/hurd/cross/obj/glibc/resolv:/home/teythoon/repos/hurd/cross/obj/glibc/crypt:/home/teythoon/repos/hurd/cross/obj/glibc/mach:/home/teythoon/repos/hurd/cross/obj/glibc/hurd -o /home/teythoon/repos/hurd/cross/obj/glibc/libc.so -T /home/teythoon/repos/hurd/cross/obj/glibc/shlib.lds /home/teythoon/repos/hurd/cross/obj/glibc/csu/abi-note.o /home/teythoon/repos/hurd/cross/obj/glibc/elf/soinit.os /home/teythoon/repos/hurd/cross/obj/glibc/libc_pic.os /home/teythoon/repos/hurd/cross/obj/glibc/elf/sofini.os /home/teythoon/repos/hurd/cross/obj/glibc/elf/interp.os /home/teythoon/repos/hurd/cross/obj/glibc/elf/ld.so /home/teythoon/repos/hurd/cross/obj/glibc/mach/libmachuser-link.so /home/teythoon/repos/hurd/cross/obj/glibc/hurd/libhurduser-link.so -lgcc + /home/teythoon/repos/hurd/cross/obj/glibc/libc_pic.os: In function `__fork': + /home/teythoon/repos/hurd/cross/src/glibc/posix/../sysdeps/mach/hurd/fork.c:70: undefined reference to `__start__hurd_atfork_prepare_hook' + /home/teythoon/repos/hurd/cross/lib/gcc/i686-pc-gnu/4.8.1/../../../../i686-pc-gnu/bin/ld: /home/teythoon/repos/hurd/cross/obj/glibc/libc_pic.os: relocation R_386_GOTOFF against undefined hidden symbol `__start__hurd_atfork_prepare_hook' can not be used when making a shared object + /home/teythoon/repos/hurd/cross/lib/gcc/i686-pc-gnu/4.8.1/../../../../i686-pc-gnu/bin/ld: final link failed: Bad value + collect2: error: ld returned 1 exit status + make[2]: *** [/home/teythoon/repos/hurd/cross/obj/glibc/libc.so] Error 1 + make[2]: Leaving directory `/home/teythoon/repos/hurd/cross/src/glibc/elf' + make[1]: *** [elf/subdir_lib] Error 2 + make[1]: Leaving directory `/home/teythoon/repos/hurd/cross/src/glibc' + make: *** [all] Error 2 + + rm -f /home/teythoon/repos/hurd/cross/sys_root/lib/ld.so + + exit 100 + + binutils-2.23.2, + gcc-4.8.1, + everything else is from git as specified in the wiki. + + +## IRC, freenode, #hurd, 2013-10-24 + + in recent glibc commits (tschwinge/Roger_Whittaker branch) there + are references to _hurd_atfork_* symbols in sysdeps/mach/hurd/fork.c, and + some _hurd_fork_* symbols, some of the _hurd_fork_* symbols seem to be + defined in Hurd's boot/frankemul.ld (mostly guessing by their names being + mentioned, I don't know linker script syntax), but those _hurd_atfork_* + symbols don't seem to be defined there, are they supposed to be defined + elsewhere or is th + does anyone know where the _hurd_atfork_* group of symbols + referenced in glibc are defined (if anywhere)? + AliciaC: it's the DEFINE_HOOK (_hurd_atfork_prepare_hook, (void)); + in glibc/sysdeps/mach/hurd/fork.c + hm, is that not just a declaration? + no, it's a definition, as its name suggests : + (despite the macro name) + :) + ok + I should look into it more, I could have sworn I was getting + undefined references, but maybe the symbol names used are different from + those defined, but that'd be odd as well, in the same file and all + I mean, I do get undefined references, but question is if it's to + things that should have been defined or not + what undefined references do you gaT? + s/gaT/get + I'll get back to you once I have that system up again + youpi: sysdeps/mach/hurd/fork.c:70: undefined reference to + `__start__hurd_atfork_prepare_hook' + fork.c:70: 'RUN_HOOK (_hurd_atfork_prepare_hook, ());' + DEFINE_HOOK (_hurd_atfork_prepare_hook, (void)); is higher up in + the file + though there is also this message: build/libc_pic.os: relocation + R_386_GOTOFF against undefined hidden symbol + `__start__hurd_atfork_prepare_hook' can not be used when making a shared + object diff --git a/open_issues/smp.mdwn b/open_issues/smp.mdwn index a45a1e22..89474d25 100644 --- a/open_issues/smp.mdwn +++ b/open_issues/smp.mdwn @@ -37,3 +37,11 @@ See also the [[FAQ entry|faq/smp]]. ## Richard, 2013-03-20 This task actually looks too big for a GSoC project. + + +## IRC, freenode, #hurd, 2013-09-30 + + also, while the problem with hurd is about I/O, it's actually a + lot more about caching, and even with more data cached in, the true + problem is contention, in which case having several processors would + actually slow things down even more diff --git a/open_issues/strict_aliasing.mdwn b/open_issues/strict_aliasing.mdwn index b7d39805..0e59f796 100644 --- a/open_issues/strict_aliasing.mdwn +++ b/open_issues/strict_aliasing.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2012, 2013 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -29,3 +29,16 @@ License|/fdl]]."]]"""]] issues (if gcc catches them all) The strict aliasing things should be fixed, yes. Some might be from MIG. + + +# IRC, freenode, #hurd, 2013-10-17 + + we should build gnumach and the hurd with -fno-strict-aliasing + aren't the mig-generated stubs the only issues related to that? + no + b/c we often have pointers of different type pointing to the + same address? for example code using libports? + the old linux code, including pfinet, and even the hurd libraries, + use techniques that assume aliasing + exactly + right, I agree diff --git a/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.mdwn b/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.mdwn index 7159551d..f40e0455 100644 --- a/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.mdwn +++ b/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.mdwn @@ -50,3 +50,5 @@ IRC, unknown channel, unknown date: result in others trying to take it... nope: look at the code :) or maybe the cancel_hook, but I really doubt it + +See discussion about *`critical_section_lock`* on [[glibc]]. diff --git a/open_issues/time.mdwn b/open_issues/time.mdwn index 367db872..d9f1fa1d 100644 --- a/open_issues/time.mdwn +++ b/open_issues/time.mdwn @@ -837,3 +837,17 @@ not get a define for `HZ`, which is then defined with a fallback value of 60. braunr: Guile2 works smoothly now, let me try something cool with it nalaginrut: nice + + +### IRC, OFTC, #debian-hurd, 2013-09-29 + + youpi: is the latest glibc carrying the changes related to + timing? what about gb guile-2.0 with it? + it does + so that was the only issue with guile? + well at least we'll see + iirc yes + according to nalaginrut and the latest build log, it'd seem so + started + yay, guile-2.0 :) + yay diff --git a/open_issues/wine.mdwn b/open_issues/wine.mdwn index 65e6c584..f8bb469b 100644 --- a/open_issues/wine.mdwn +++ b/open_issues/wine.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011, 2013 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -21,7 +22,7 @@ requirements Wine has: only libc / POSIX / etc., or if there are allocation. There is kernel support for this,* however. -IRC, freenode, #hurd, 2011-08-11 +# IRC, freenode, #hurd, 2011-08-11 < arethusa> I've been trying to make Wine work inside a Debian GNU/Hurd VM, and to that end, I've successfully compiled the latest sources from Git @@ -67,3 +68,13 @@ IRC, freenode, #hurd, 2011-08-11 < youpi> yes < pinotree> (but that patch is lame) + + +# IRC, freenode, #hurd, 2013-10-02 + + youpi: I've come a little further with wine, see debian bug + #724681 (same problem). + Now the problem is probably due to the specific address space + and stack issues to be + fixed for wine to run as braunr pointed out some months ago + (IRC?) when we discussed wine. diff --git a/unix/process.mdwn b/unix/process.mdwn index 21fbfc69..82034751 100644 --- a/unix/process.mdwn +++ b/unix/process.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2013 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -8,13 +8,11 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] -A *UNIX process* is TODO. +A *UNIX process* is a program in execution, that is, an instance running in an +execution context. Generally, especially in [[microkernel]]-based systems, the [[kernel]]'s idea of a task is not as encompassing as a UNIX process, and will use additional effort to enhance the kernel's primitive to a full-fledged UNIX model. - -A [[Mach task|microkernel/mach/task]] implements a part of a UNIX process. - In the GNU/Hurd, processes are based on [[Mach task|microkernel/mach/task]]s, but are [[enhanced by the glibc|glibc/process]]. -- cgit v1.2.3