summaryrefslogtreecommitdiff
path: root/open_issues
diff options
context:
space:
mode:
Diffstat (limited to 'open_issues')
-rw-r--r--open_issues/64-bit_port.mdwn20
-rw-r--r--open_issues/anatomy_of_a_hurd_system.mdwn189
-rw-r--r--open_issues/arm_port.mdwn1
-rw-r--r--open_issues/code_analysis.mdwn14
-rw-r--r--open_issues/dde.mdwn44
-rw-r--r--open_issues/gdb_signal_handler.mdwn403
-rw-r--r--open_issues/glibc/0.4.mdwn4
-rw-r--r--open_issues/glibc/debian.mdwn67
-rw-r--r--open_issues/glibc/debian/experimental.mdwn60
-rw-r--r--open_issues/glibc/t/tls-threadvar.mdwn12
-rw-r--r--open_issues/libc_variant_selection.mdwn25
-rw-r--r--open_issues/libnetfs_argument_parsing.mdwn62
-rw-r--r--open_issues/libpthread.mdwn197
-rw-r--r--open_issues/libpthread/t/fix_have_kernel_resources.mdwn181
-rw-r--r--open_issues/libpthread_assertion_thread_prevp.mdwn20
-rw-r--r--open_issues/mondriaan_memory_protection.mdwn85
-rw-r--r--open_issues/some_todo_list.mdwn15
-rw-r--r--open_issues/translator_stdout_stderr.mdwn87
-rw-r--r--open_issues/user-space_device_drivers.mdwn92
19 files changed, 1492 insertions, 86 deletions
diff --git a/open_issues/64-bit_port.mdwn b/open_issues/64-bit_port.mdwn
index 66da44b9..b0c95612 100644
--- a/open_issues/64-bit_port.mdwn
+++ b/open_issues/64-bit_port.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
@@ -137,3 +138,20 @@ See also [[microkernel/mach/gnumach/memory_management]].
<braunr> hm actually no, it would require mcmodel=large
<braunr> hum, that's stupid, we can make the kernel run at -2g, and use 3g
up to the sign extension hole for the kernel map
+
+
+# IRC, freenode, #hurd, 2013-07-02
+
+In context of [[mondriaan_memory_protection]].
+
+ <xscript> BTW, it's not like I have an infinite amount of time for this,
+ but having 64-bit support would be valuable for me, so I might contribute
+ that back if it's not a too monumental task
+ <xscript> I saw some discussions about 32bit apps on top of 64bit mach, but
+ I'd like a full 64bit system
+ <xscript> any clues?
+ <xscript> I suppose the compiler support is all there already
+ <xscript> is MIG (and mach) the only piece missing?
+ <braunr> the problem is the interfaces themselves
+ <braunr> type widths
+ <braunr> as passed between userspace and kernel
diff --git a/open_issues/anatomy_of_a_hurd_system.mdwn b/open_issues/anatomy_of_a_hurd_system.mdwn
index 11a1f754..75a62535 100644
--- a/open_issues/anatomy_of_a_hurd_system.mdwn
+++ b/open_issues/anatomy_of_a_hurd_system.mdwn
@@ -323,7 +323,9 @@ Actually, the Hurd has never used an M:N model. Both libthreads (cthreads) and l
<braunr> etc..
-# IRC, freenode, #hurd, 2012-12-06
+# Service Directory
+
+## IRC, freenode, #hurd, 2012-12-06
<spiderweb> what is the #1 feature that distinguished hurd from other
operating systems. the concept of translators. (will read more when I get
@@ -333,56 +335,7 @@ Actually, the Hurd has never used an M:N model. Both libthreads (cthreads) and l
<braunr> and the VFS permissions to control access to those services
-# IRC, freenode, #hurd, 2012-12-10
-
- <spiderweb> I want to work on hurd, but I think I'm going to start with
- minix, I own the minix book 3rd ed. it seems like a good intro to
- operating systems in general. like I don't even know what a semaphore is
- yet.
- <braunr> well, enjoy learning :)
- <spiderweb> once I finish that book, what reading do you guys recommend?
- <spiderweb> other than the wiki
- <braunr> i wouldn't recommend starting with a book that focuses on one
- operating system anyway
- <braunr> you tend to think in terms of what is done in that specific
- implementation and compare everything else to that
- <braunr> tannenbaum is not only the main author or minix, but also the one
- of the book http://en.wikipedia.org/wiki/Modern_Operating_Systems
- <braunr>
- http://en.wikipedia.org/wiki/List_of_important_publications_in_computer_science#Operating_systems
- should be a pretty good list :)
-
-
-# IRC, freenode, #hurd, 2013-03-12
-
- <mjjc> i have a question regarding ipc in hurd. if a task is created, does
- it contain any default port rights in its space? i am trying to deduce
- how one calls dir_lookup() on the root translator in glibc's open().
- <kilobug> mjjc: yes, there are some default port rights, but I don't
- remember the details :/
- <mjjc> kilobug: do you know where i should search for details?
- <kilobug> mjjc: hum either in the Hurd's hacking guide
- https://www.gnu.org/software/hurd/hacking-guide/ or directly in the
- source code of exec server/libc I would say, or just ask again the
- question here later on to see if someone else has more information
- <mjjc> ok, thanks
- <pinotree> there's also rpctrace to, as the name says, trace all the rpc's
- executed
- <braunr> some ports are introduced in new tasks, yes
- <braunr> see
- http://www.gnu.org/software/hurd/hacking-guide/hhg.html#The-main-function
- <braunr> and
- <braunr>
- http://www.gnu.org/software/hurd/gnumach-doc/Task-Special-Ports.html#Task-Special-Ports
- <mjjc> yes, the second link was just what i was looking for, thanks
- <braunr> the second is very general
- <braunr> also, the first applies to translators only
- <braunr> if you're looking for how to do it for a non-translator
- application, the answer is probably somewhere in glibc
- <braunr> _hurd_startup i'd guess
-
-
-# IRC, freenode, #hurd, 2013-05-23
+## IRC, freenode, #hurd, 2013-05-23
<gnu_srs> Hi, is there any efficient way to control which backed
translators are called via RPC with a user space program?
@@ -409,18 +362,7 @@ Actually, the Hurd has never used an M:N model. Both libthreads (cthreads) and l
same as for regular files
<braunr> gnu_srs: this *must* be obvious for you to do any tricky work on
the hurd
- <gnu_srs> fsysopts /servers/socket/2 works by /1 gives Operation not
- supported.
-
-[[!taglink open_issue_hurd]].
-
- <braunr> ah right, some servers don't implement that
- <braunr> work around this by using showtrans
- <braunr> fsysopts asks the server itself how it's running, usually giving
- its command name and options
- <braunr> showtrans asks the parent how it starts a passive translator
- attached to the node
- <gnu_srs> Yes showtrans works :), thanks.
+
<gnu_srs> Anyway, if I create a test program calling io_stat I assume
S_io_stat in pflocal is called.
<gnu_srs> How to make the program call S_io_stat in pfinet instead?
@@ -447,6 +389,127 @@ Actually, the Hurd has never used an M:N model. Both libthreads (cthreads) and l
implementation
+## IRC, freenode, #hurd, 2013-06-30
+
+ <hacklu> hi, what is the replacer of netname_check_in?
+
+ <hacklu> I want to ask another question. in my opinion, the rpc is the
+ mach's way, and the translator is the hurd's way. so somebody want to
+ lookup a service, it should not need to ask the mach kernel know about
+ this query. the hurd will take the control.
+ <hacklu> am I right?
+ <braunr> no
+ <braunr> that's nonsense
+ <braunr> service lookups has never been in mach
+ <braunr> first mach based systems used a service directory, whereas the
+ hurd uses the file system for that
+ <braunr> you still need mach to communicate with either of those
+ <hacklu> how to understand the term of service directory here?
+ <braunr> a server everyone knows
+ <braunr> which gives references to other servers
+ <braunr> usually, depending on the name
+ <braunr> e.g. name_lookup("net") -> port right to network server
+ <hacklu> is that people use netname_check_in to register service in the
+ past? now used libtrivfs?
+ <braunr> i don't know about netname_check_in
+ <braunr> old mach (not gnumach) documentation might mention this service
+ directory
+ <braunr> libtrivfs doesn't have much to do with that
+ <braunr> on the hurd, the equivalent is the file system
+ <hacklu> maybe that is outdate, I just found that exist old doc, and old
+ code which can't be build.
+ <braunr> every process knows /
+ <braunr> the file system is the service directory
+ <braunr> nodes refer to services
+ <hacklu> so the file system is the nameserver, any new service should
+ register in it before other can use
+ <braunr> and the file system is distributed, so looking up a service may
+ require several queries
+ <braunr> setting a translator is exactly that, registering a program to
+ service requests on a node
+ <braunr> the file system isn't one server though
+ <braunr> programs all know about /, but then, lookups are recursive
+ <braunr> e.g. if you have / and /home, and are looking for
+ /home/hacklu/.profile, you ask / which tells you about /home, and /home
+ will give you a right to /home/hacklu/.profile
+ <hacklu> even in the past, the mach don't provide name register service,
+ there must be an other server to provide this service?
+ <braunr> yes
+ <braunr> what's nonsense in your sentence is comparing RPCs and translators
+ <braunr> translators are merely servers attached to the file system, using
+ RPCs to communicate with the rest of the system
+ <hacklu> I know yet, the two just one thing.
+ <braunr> no
+ <braunr> two things :p
+ <braunr> completely different and unrelated except for one using the other
+ <hacklu> ah, just one used aonther one.
+ <hacklu> is exist anyway to anounce service except settrans with file node?
+ <braunr> more or less
+ <braunr> tasks can have special ports
+ <braunr> that's how one task knows about / for example
+ <braunr> at task creation, a right to / is inserted in the new task
+ <hacklu> I think this is also a file node way.
+ <braunr> no
+ <braunr> if i'm right, auth is referenced the same way
+ <braunr> and there is no node for auth
+ <hacklu> how the user get the port of auth with node?
+ <braunr> it's given when a task is created
+ <hacklu> pre-set in the creation of one task?
+ <braunr> i'm unconfortable with "pre-set"
+ <braunr> inserted at creation time
+ <braunr> auth is started very early
+ <braunr> then tasks are given a reference to it
+
+
+# IRC, freenode, #hurd, 2012-12-10
+
+ <spiderweb> I want to work on hurd, but I think I'm going to start with
+ minix, I own the minix book 3rd ed. it seems like a good intro to
+ operating systems in general. like I don't even know what a semaphore is
+ yet.
+ <braunr> well, enjoy learning :)
+ <spiderweb> once I finish that book, what reading do you guys recommend?
+ <spiderweb> other than the wiki
+ <braunr> i wouldn't recommend starting with a book that focuses on one
+ operating system anyway
+ <braunr> you tend to think in terms of what is done in that specific
+ implementation and compare everything else to that
+ <braunr> tannenbaum is not only the main author or minix, but also the one
+ of the book http://en.wikipedia.org/wiki/Modern_Operating_Systems
+ <braunr>
+ http://en.wikipedia.org/wiki/List_of_important_publications_in_computer_science#Operating_systems
+ should be a pretty good list :)
+
+
+# IRC, freenode, #hurd, 2013-03-12
+
+ <mjjc> i have a question regarding ipc in hurd. if a task is created, does
+ it contain any default port rights in its space? i am trying to deduce
+ how one calls dir_lookup() on the root translator in glibc's open().
+ <kilobug> mjjc: yes, there are some default port rights, but I don't
+ remember the details :/
+ <mjjc> kilobug: do you know where i should search for details?
+ <kilobug> mjjc: hum either in the Hurd's hacking guide
+ https://www.gnu.org/software/hurd/hacking-guide/ or directly in the
+ source code of exec server/libc I would say, or just ask again the
+ question here later on to see if someone else has more information
+ <mjjc> ok, thanks
+ <pinotree> there's also rpctrace to, as the name says, trace all the rpc's
+ executed
+ <braunr> some ports are introduced in new tasks, yes
+ <braunr> see
+ http://www.gnu.org/software/hurd/hacking-guide/hhg.html#The-main-function
+ <braunr> and
+ <braunr>
+ http://www.gnu.org/software/hurd/gnumach-doc/Task-Special-Ports.html#Task-Special-Ports
+ <mjjc> yes, the second link was just what i was looking for, thanks
+ <braunr> the second is very general
+ <braunr> also, the first applies to translators only
+ <braunr> if you're looking for how to do it for a non-translator
+ application, the answer is probably somewhere in glibc
+ <braunr> _hurd_startup i'd guess
+
+
# IRC, freenode, #hurd, 2013-06-15
<damo22> ive been reading a little about exokernels or unikernels, and i
diff --git a/open_issues/arm_port.mdwn b/open_issues/arm_port.mdwn
index 8a2a037f..b07df939 100644
--- a/open_issues/arm_port.mdwn
+++ b/open_issues/arm_port.mdwn
@@ -273,4 +273,3 @@ architecture.
<slpz> braunr: OK, thanks. I'm interested on it, and didn't want to
duplicate efforts.
<braunr> little addition: it may have started, but we don't know about it
-
diff --git a/open_issues/code_analysis.mdwn b/open_issues/code_analysis.mdwn
index bdd2ae18..67798c6a 100644
--- a/open_issues/code_analysis.mdwn
+++ b/open_issues/code_analysis.mdwn
@@ -193,3 +193,17 @@ There is a [[!FF_project 276]][[!tag bounty]] on some of these tasks.
* [Trinity: A Linux kernel fuzz tester (and then
some)](http://www.socallinuxexpo.org/scale11x/presentations/trinity-linux-kernel-fuzz-tester-and-then-some),
Dave Jones, The Eleventh Annual Southern California Linux Expo, 2013.
+
+ * Mayhem, *an automatic bug finding system*
+
+ IRC, freenode, #hurd, 2013-06-29:
+
+ <teythoon> started reading the mayhem paper referenced here
+ http://lists.debian.org/debian-devel/2013/06/msg00720.html
+ <teythoon> that's nice work, they are doing symbolic execution of x86
+ binary code, that's effectively model checking with some specialized
+ formulas
+ <teythoon> (too bad the mayhem code isn't available, damn those
+ academic people keeping the good stuff to themselvs...)
+ <teythoon> (and I really think that's bad practice, how should anyone
+ reproduce their results? that's not how science works imho...)
diff --git a/open_issues/dde.mdwn b/open_issues/dde.mdwn
index 65d84886..76b80211 100644
--- a/open_issues/dde.mdwn
+++ b/open_issues/dde.mdwn
@@ -598,3 +598,47 @@ In context of [[libpthread]].
<braunr> hm, i haven't looked but, does someone know if virtio is included
in netdde ?
<youpi> braunr: nope, there's an underlying virtio layer needed before
+
+
+## IRC, freenode, #hurd, 2013-07-24
+
+ <teythoon> btw, I'd love to see libvirt support in hurd
+ <teythoon> I tried to hack up a dde based net translator
+ <teythoon> afaics they are very much like any other pci device, so the
+ infrastructure should be there
+ <teythoon> if anything I expect the libvirt stuff to be more easily
+ portable
+ <youpi> what do you mean by "a dde based net translator" ?
+ <youpi> ah, you mean virtio support in netdde ?
+ <teythoon> yes
+ <teythoon> virtio net is present in the kernel version we use for the dde
+ drivers
+ <teythoon> so I just copied the dde driver over, but I had no luck
+ compiling it
+ <youpi> ok, but what would be the benefice over e1000 & co?
+ <teythoon> any of the dde drivers btw
+ <teythoon> youpi: less overhead
+ <youpi> e1000 is already low overhead actually
+ <youpi> there are less and less differences in strategies for driving a
+ real board, and a virtual one
+ <youpi> we are seeing shared memory request buffer, dma, etc. in real
+ boards
+ <youpi> which ends up being almost exactly what virtio does :)
+ <youpi> ahci, for instance, really looks extremely like a virtio interface
+ <youpi> (I know, it's a disk, but that's the same idea, and I do know what
+ I'm talking about here :) )
+ <teythoon> that would actually be my next wish, a virtio disk driver, and
+ virt9p ;)
+ <braunr> on the other hand, i wouldn't spend much time on a virtio disk
+ driver for now
+ <braunr> the hurd as it is can't boot on a device that isn't managed by the
+ kernel
+ <braunr> we'd need to change the boot protocol
+ <teythoon> ok, I wasn't planning to, just wanted to see if I can easily
+ hack up the virtio-net translator
+ <braunr> well, as youpi pointed, there is little benefit to that as well
+ <braunr> but if that's what you find fun, help yourself :)
+ <teythoon> I didn't know that, I assumed there was some value to the virtio
+ stuff
+ <braunr> there is
+ <braunr> but relatively to other improvements, it's low
diff --git a/open_issues/gdb_signal_handler.mdwn b/open_issues/gdb_signal_handler.mdwn
new file mode 100644
index 00000000..3084f7e3
--- /dev/null
+++ b/open_issues/gdb_signal_handler.mdwn
@@ -0,0 +1,403 @@
+[[!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]]."]]"""]]
+
+[[!tag open_issue_gdb open_issue_glibc]]
+
+
+# IRC, freenode, #hurd, 2013-07-07
+
+ <zyg> Hi, I'm in GDB inside a handler for SIGHUP, after stepping out, gdb
+ will hang on instruction: <_hurd_sigstate_lock+88>: xchg
+ %edx,0x4(%eax)
+ <zyg> here is my signal test pasted: http://pastebin.com/U72qw3FC
+ #include <stdio.h>
+ #include <stdlib.h>
+ #include <signal.h>
+
+ void *
+ my_handler(int signal, void *info, void *context)
+ {
+ printf("got SIGHUP\n");
+ return NULL;
+ }
+
+ void
+ install_handler (int signal)
+ {
+ struct sigaction sa;
+ sa.sa_sigaction = my_handler;
+ sa.sa_flags = SA_SIGINFO;
+ sigemptyset(&sa.sa_mask);
+ sigaction(signal, &sa, NULL);
+ }
+
+ void test_sighup(void)
+ {
+ raise(SIGHUP);
+ }
+
+ int main(int argc, char **argv){
+ install_handler(SIGHUP);
+ test_sighup();
+ exit(1);
+ }
+ <braunr> zyg: thanks
+ <braunr> zyg: what is the problem exactly ?
+ <braunr> zyg: i mean, does it hand before attaching with gdb ?
+ <zyg> braunr: it doesn't hang if runned without gdb. I've pasted here when
+ I step out of the handler, and get to the hanging instruction:
+ http://pastebin.com/nUyCx6Wj
+ $ gdb --args a.out
+ GNU gdb (GDB) 7.6-debian
+ Copyright (C) 2013 Free Software Foundation, Inc.
+ License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
+ This is free software: you are free to change and redistribute it.
+ There is NO WARRANTY, to the extent permitted by law. Type "show copying"
+ and "show warranty" for details.
+ This GDB was configured as "i486-gnu".
+ For bug reporting instructions, please see:
+ <http://www.gnu.org/software/gdb/bugs/>...
+ Reading symbols from /home/shrek/a.out...(no debugging symbols found)...done.
+ (gdb)
+
+ (gdb) display/i $pc
+ (gdb) handle SIGHUP pass stop print
+ Signal Stop Print Pass to program Description
+ SIGHUP Yes Yes Yes Hangup
+ (gdb)
+
+ (gdb) run
+ Starting program: /home/shrek/a.out
+ [New Thread 3571.5]
+
+ Program received signal SIGHUP, Hangup.
+ 0x010548ec in mach_msg_trap ()
+ at /build/buildd-eglibc_2.17-6-hurd-i386-g946kE/eglibc-2.17/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
+ 2 /build/buildd-eglibc_2.17-6-hurd-i386-g946kE/eglibc-2.17/build-tree/hurd-i386-libc/mach/mach_msg_trap.S: No such file or directory.
+ 1: x/i $pc
+ => 0x10548ec <mach_msg_trap+12>: ret
+ (gdb)
+
+ (gdb) si
+ 0x0804862d in my_handler ()
+ 1: x/i $pc
+ => 0x804862d <my_handler>: push %ebp
+ (gdb) x/20xi 0x804862d
+ => 0x804862d <my_handler>: push %ebp
+ 0x804862e <my_handler+1>: mov %esp,%ebp
+ 0x8048630 <my_handler+3>: sub $0x18,%esp
+ 0x8048633 <my_handler+6>: movl $0x8048750,(%esp)
+ 0x804863a <my_handler+13>: call 0x8048500 <puts@plt>
+ 0x804863f <my_handler+18>: mov $0x0,%eax
+ 0x8048644 <my_handler+23>: leave
+ 0x8048645 <my_handler+24>: ret
+ 0x8048646 <install_handler>: push %ebp
+ 0x8048647 <install_handler+1>: mov %esp,%ebp
+ 0x8048649 <install_handler+3>: sub $0x28,%esp
+ 0x804864c <install_handler+6>: movl $0x804862d,-0x14(%ebp)
+ 0x8048653 <install_handler+13>: movl $0x40,-0xc(%ebp)
+ 0x804865a <install_handler+20>: lea -0x14(%ebp),%eax
+ 0x804865d <install_handler+23>: add $0x4,%eax
+ 0x8048660 <install_handler+26>: mov %eax,(%esp)
+ 0x8048663 <install_handler+29>: call 0x80484d0 <sigemptyset@plt>
+ 0x8048668 <install_handler+34>: movl $0x0,0x8(%esp)
+ 0x8048670 <install_handler+42>: lea -0x14(%ebp),%eax
+ 0x8048673 <install_handler+45>: mov %eax,0x4(%esp)
+ (gdb)
+
+ (gdb) break *0x804863f
+ Breakpoint 1 at 0x804863f
+ (gdb) c
+ Continuing.
+ got SIGHUP
+
+ Breakpoint 1, 0x0804863f in my_handler ()
+ 1: x/i $pc
+ => 0x804863f <my_handler+18>: mov $0x0,%eax
+ (gdb)
+
+ (gdb) si
+ 0x08048644 in my_handler ()
+ 1: x/i $pc
+ => 0x8048644 <my_handler+23>: leave
+ (gdb)
+ 0x08048645 in my_handler ()
+ 1: x/i $pc
+ => 0x8048645 <my_handler+24>: ret
+ (gdb)
+ 0x010708b2 in trampoline () from /lib/i386-gnu/libc.so.0.3
+ 1: x/i $pc
+ => 0x10708b2 <trampoline+2>: add $0xc,%esp
+ (gdb)
+ 0x010708b5 in trampoline () from /lib/i386-gnu/libc.so.0.3
+ 1: x/i $pc
+ => 0x10708b5 <trampoline+5>: ret
+ (gdb)
+ __sigreturn (scp=0x102988c) at ../sysdeps/mach/hurd/i386/sigreturn.c:30
+ 30 ../sysdeps/mach/hurd/i386/sigreturn.c: No such file or directory.
+ 1: x/i $pc
+ => 0x1096340 <__sigreturn>: push %ebp
+ (gdb)
+ 0x01096341 30 in ../sysdeps/mach/hurd/i386/sigreturn.c
+ 1: x/i $pc
+ => 0x1096341 <__sigreturn+1>: push %edi
+ (gdb)
+ 0x01096342 30 in ../sysdeps/mach/hurd/i386/sigreturn.c
+ 1: x/i $pc
+ => 0x1096342 <__sigreturn+2>: push %esi
+ (gdb)
+ 0x01096343 30 in ../sysdeps/mach/hurd/i386/sigreturn.c
+ 1: x/i $pc
+ => 0x1096343 <__sigreturn+3>: push %ebx
+ (gdb)
+ 0x01096344 30 in ../sysdeps/mach/hurd/i386/sigreturn.c
+ 1: x/i $pc
+ => 0x1096344 <__sigreturn+4>: sub $0x2c,%esp
+ (gdb)
+ 0x01096347 30 in ../sysdeps/mach/hurd/i386/sigreturn.c
+ 1: x/i $pc
+ => 0x1096347 <__sigreturn+7>: mov 0x40(%esp),%esi
+ (gdb)
+ 0x0109634b 30 in ../sysdeps/mach/hurd/i386/sigreturn.c
+ 1: x/i $pc
+ => 0x109634b <__sigreturn+11>: call 0x11a0609 <__x86.get_pc_thunk.bx>
+ (gdb)
+ 0x011a0609 in __x86.get_pc_thunk.bx () from /lib/i386-gnu/libc.so.0.3
+ 1: x/i $pc
+ => 0x11a0609 <__x86.get_pc_thunk.bx>: mov (%esp),%ebx
+ (gdb)
+ 0x011a060c in __x86.get_pc_thunk.bx () from /lib/i386-gnu/libc.so.0.3
+ 1: x/i $pc
+ => 0x11a060c <__x86.get_pc_thunk.bx+3>: ret
+ (gdb)
+ 0x01096350 in __sigreturn (scp=0x102988c) at ../sysdeps/mach/hurd/i386/sigreturn.c:30
+ 30 in ../sysdeps/mach/hurd/i386/sigreturn.c
+ 1: x/i $pc
+ => 0x1096350 <__sigreturn+16>: add $0x15ccb0,%ebx
+ (gdb)
+ 35 in ../sysdeps/mach/hurd/i386/sigreturn.c
+ 1: x/i $pc
+ => 0x1096356 <__sigreturn+22>: test %esi,%esi
+ (gdb)
+ 0x01096358 35 in ../sysdeps/mach/hurd/i386/sigreturn.c
+ 1: x/i $pc
+ => 0x1096358 <__sigreturn+24>: je 0x10964f0 <__sigreturn+432>
+ (gdb)
+ 0x0109635e 35 in ../sysdeps/mach/hurd/i386/sigreturn.c
+ 1: x/i $pc
+ => 0x109635e <__sigreturn+30>: testl $0x10100,0x4(%esi)
+ (gdb)
+ 0x01096365 35 in ../sysdeps/mach/hurd/i386/sigreturn.c
+ 1: x/i $pc
+ => 0x1096365 <__sigreturn+37>: jne 0x10964f0 <__sigreturn+432>
+ (gdb)
+ __hurd_threadvar_location_from_sp (__sp=<optimized out>, __index=<optimized out>) at ../hurd/hurd/threadvar.h:94
+ 94 ../hurd/hurd/threadvar.h: No such file or directory.
+ 1: x/i $pc
+ => 0x109636b <__sigreturn+43>: mov -0x38(%ebx),%ebp
+ (gdb)
+ __hurd_threadvar_location (__index=_HURD_THREADVAR_SIGSTATE) at ../hurd/hurd/threadvar.h:116
+ 116 in ../hurd/hurd/threadvar.h
+ 1: x/i $pc
+ => 0x1096371 <__sigreturn+49>: mov %esp,%edx
+ (gdb)
+ __hurd_threadvar_location_from_sp (__sp=0x1029848, __index=_HURD_THREADVAR_SIGSTATE) at ../hurd/hurd/threadvar.h:94
+ 94 in ../hurd/hurd/threadvar.h
+ 1: x/i $pc
+ => 0x1096373 <__sigreturn+51>: cmp 0x0(%ebp),%esp
+ (gdb)
+ 0x01096376 94 in ../hurd/hurd/threadvar.h
+ 1: x/i $pc
+ => 0x1096376 <__sigreturn+54>: jae 0x10964d0 <__sigreturn+400>
+ (gdb)
+ 0x0109637c 94 in ../hurd/hurd/threadvar.h
+ 1: x/i $pc
+ => 0x109637c <__sigreturn+60>: mov -0x15c(%ebx),%eax
+ (gdb)
+ 0x01096382 94 in ../hurd/hurd/threadvar.h
+ 1: x/i $pc
+ => 0x1096382 <__sigreturn+66>: and (%eax),%edx
+ (gdb)
+ 0x01096384 94 in ../hurd/hurd/threadvar.h
+ 1: x/i $pc
+ => 0x1096384 <__sigreturn+68>: mov -0x90(%ebx),%eax
+ (gdb)
+ 0x0109638a 94 in ../hurd/hurd/threadvar.h
+ 1: x/i $pc
+ => 0x109638a <__sigreturn+74>: add (%eax),%edx
+ (gdb)
+ _hurd_self_sigstate () at ../hurd/hurd/signal.h:165
+ 165 ../hurd/hurd/signal.h: No such file or directory.
+ 1: x/i $pc
+ => 0x109638c <__sigreturn+76>: mov 0x8(%edx),%edi
+ (gdb)
+ 0x0109638f 165 in ../hurd/hurd/signal.h
+ 1: x/i $pc
+ => 0x109638f <__sigreturn+79>: test %edi,%edi
+ (gdb)
+ 0x01096391 165 in ../hurd/hurd/signal.h
+ 1: x/i $pc
+ => 0x1096391 <__sigreturn+81>: je 0x1096598 <__sigreturn+600>
+ (gdb)
+ __sigreturn (scp=0x102988c) at ../sysdeps/mach/hurd/i386/sigreturn.c:42
+ 42 ../sysdeps/mach/hurd/i386/sigreturn.c: No such file or directory.
+ 1: x/i $pc
+ => 0x1096397 <__sigreturn+87>: mov %edi,(%esp)
+ (gdb)
+ 0x0109639a 42 in ../sysdeps/mach/hurd/i386/sigreturn.c
+ 1: x/i $pc
+ => 0x109639a <__sigreturn+90>: call 0x1051d70 <_hurd_sigstate_lock@plt>
+ (gdb)
+ 0x01051d70 in _hurd_sigstate_lock@plt () from /lib/i386-gnu/libc.so.0.3
+ 1: x/i $pc
+ => 0x1051d70 <_hurd_sigstate_lock@plt>: jmp *0x864(%ebx)
+ (gdb)
+ _hurd_sigstate_lock (ss=ss@entry=0x1244008) at hurdsig.c:170
+ 170 hurdsig.c: No such file or directory.
+ 1: x/i $pc
+ => 0x106bb90 <_hurd_sigstate_lock>: sub $0x1c,%esp
+ (gdb)
+ 0x0106bb93 170 in hurdsig.c
+ 1: x/i $pc
+ => 0x106bb93 <_hurd_sigstate_lock+3>: mov %ebx,0x14(%esp)
+ (gdb)
+ 0x0106bb97 170 in hurdsig.c
+ 1: x/i $pc
+ => 0x106bb97 <_hurd_sigstate_lock+7>: call 0x11a0609 <__x86.get_pc_thunk.bx>
+ (gdb)
+ 0x011a0609 in __x86.get_pc_thunk.bx () from /lib/i386-gnu/libc.so.0.3
+ 1: x/i $pc
+ => 0x11a0609 <__x86.get_pc_thunk.bx>: mov (%esp),%ebx
+ (gdb)
+ 0x011a060c in __x86.get_pc_thunk.bx () from /lib/i386-gnu/libc.so.0.3
+ 1: x/i $pc
+ => 0x11a060c <__x86.get_pc_thunk.bx+3>: ret
+ (gdb)
+ 0x0106bb9c in _hurd_sigstate_lock (ss=ss@entry=0x1244008) at hurdsig.c:170
+ 170 in hurdsig.c
+ 1: x/i $pc
+ => 0x106bb9c <_hurd_sigstate_lock+12>: add $0x187464,%ebx
+ (gdb)
+ 0x0106bba2 170 in hurdsig.c
+ 1: x/i $pc
+ => 0x106bba2 <_hurd_sigstate_lock+18>: mov %esi,0x18(%esp)
+ (gdb)
+ 170 in hurdsig.c
+ 1: x/i $pc
+ => 0x106bba6 <_hurd_sigstate_lock+22>: mov 0x20(%esp),%esi
+ (gdb)
+ sigstate_is_global_rcv (ss=0x1244008) at hurdsig.c:162
+ 162 in hurdsig.c
+ 1: x/i $pc
+ => 0x106bbaa <_hurd_sigstate_lock+26>: lea 0x57c0(%ebx),%eax
+ (gdb)
+ 0x0106bbb0 162 in hurdsig.c
+ 1: x/i $pc
+ => 0x106bbb0 <_hurd_sigstate_lock+32>: mov (%eax),%eax
+ (gdb)
+ 163 in hurdsig.c
+ 1: x/i $pc
+ => 0x106bbb2 <_hurd_sigstate_lock+34>: test %eax,%eax
+ (gdb)
+ 0x0106bbb4 163 in hurdsig.c
+ 1: x/i $pc
+ => 0x106bbb4 <_hurd_sigstate_lock+36>: je 0x106bbbc <_hurd_sigstate_lock+44>
+ (gdb)
+ 0x0106bbb6 163 in hurdsig.c
+ 1: x/i $pc
+ => 0x106bbb6 <_hurd_sigstate_lock+38>: cmpl $0x1,0x18(%esi)
+ (gdb)
+ 0x0106bbba 163 in hurdsig.c
+ 1: x/i $pc
+ => 0x106bbba <_hurd_sigstate_lock+42>: je 0x106bbe0 <_hurd_sigstate_lock+80>
+ (gdb)
+ _hurd_sigstate_lock (ss=ss@entry=0x1244008) at hurdsig.c:172
+ 172 in hurdsig.c
+ 1: x/i $pc
+ => 0x106bbe0 <_hurd_sigstate_lock+80>: lea 0x4(%eax),%ecx
+ (gdb)
+ __spin_try_lock (__lock=0x124480c) at ../sysdeps/mach/i386/machine-lock.h:59
+ 59 ../sysdeps/mach/i386/machine-lock.h: No such file or directory.
+ 1: x/i $pc
+ => 0x106bbe3 <_hurd_sigstate_lock+83>: mov $0x1,%edx
+ (gdb)
+ 0x0106bbe8 59 in ../sysdeps/mach/i386/machine-lock.h
+ 1: x/i $pc
+ => 0x106bbe8 <_hurd_sigstate_lock+88>: xchg %edx,0x4(%eax)
+ (gdb)
+ <braunr> zyg: i don't get what you mean
+ <braunr> are you starting it with gdb ?
+ <zyg> braunr: yes: "gdb --args a.out"
+ <braunr> ok
+ <braunr> can't reproduce it
+ <braunr> i get "Program received signal SIGHUP, Hangup.
+ <braunr> "
+ <braunr> then continue, then the program has exited
+ <zyg> braunr: do you run it in gdb or without?
+ <zyg> braunr: Ah "Program received signal SIGHUP, Hangup." is from
+ gdb.. try issue continue, not sure why gdb stops at SIGHUP (default?).
+ <braunr> 10:34 < braunr> then continue, then the program has exited
+ <braunr> gdb stops at signals
+ <zyg> braunr: yes, try repeating that, but instead of continue, just issue
+ "si"
+ <zyg> braunr: sorry.. you would need to remove that printf/fprintf, else it
+ gets too long. That's why I put a breakpoint.
+ <braunr> a breakpoint ?
+ <braunr> on the signal handler ?
+ <zyg> braunr: yes, put a break after having entered the handler. Or edit
+ the pasted C code an remove that printf("got SIGHUP\n");
+ <braunr> i'm not sure that's correctly supported
+ <braunr> and i can see why glibc would deadlock on the sigstate lock
+ <braunr> don't do that :p
+ <zyg> braunr: why does it deadlock?
+ <braunr> because both the signal handler and messages from gdb will cause
+ common code paths to be taken
+ <zyg> braunr: oh.. when I step instruction I'm inside an SIGTRAP handler
+ probably?
+ <braunr> possible
+ <braunr> i don't know the details but that's the kind of things i expect
+ <braunr> and signals on the hurd are definitely buggy
+ <braunr> i don't know if we support nesting them
+ <braunr> i'd say we don't
+ <zyg> braunr: I'll try to put a break beyond that xchg and continue
+ <braunr> xhcg is probably the sigstate spinlock
+ <braunr> xchg*
+ <braunr> you'd need to reach the unlock instruction, which is probably
+ executed once the handler has finished running
+ <zyg> braunr: yes :) ... one instruction beyond didn't help
+ <zyg> braunr: thanks alot, putting a break in __sigreturn, after that
+ function has called _hurd_sigstate_unlock@plt works!
+ <braunr> works ?
+ <braunr> what did you want to do ?
+ <zyg> braunr: I want to trace user code inside the signal handler, also how
+ we enter and how we leave.
+ <braunr> well you can't do that inside, so no it doesn't work for you :/
+ <braunr> but that's a start i guess
+ <zyg> braunr: I seem to do most normal things inside the handler,
+ step-instruction and put breaks.
+ <braunr> ?
+ <braunr> i thought that's what made the program deadlock
+ <zyg> braunr: as you said earlier, the deadlock came when i "step
+ instruction" into the area between _hurd_sigstate_lock and
+ _hurd_sigstate_unlock. Otherwise I havn't had any issues.
+ <braunr> but isn't the sigstate locked during the handler execution ?
+ <zyg> braunr: no it locks and unlocks in __sigreturn which is done when
+ leaving the handler.
+ <braunr> than how could it deadlock on handler entry ?
+ <braunr> or perhaps the fact your handler was empty made the entry point
+ directly reach __sigreturn
+ <braunr> hm no i don't buy it
+ <braunr> the sigstate must also be locked on entry
+ <zyg> braunr: there was never any problem with entering
+ <braunr> then describe the problem with more details please
+ <braunr> ah sorry
+ <zyg> braunr: are you sure? there is minimal user-code run before the
+ signal is going into the handler.
+ <braunr> you "step out of the handler"
diff --git a/open_issues/glibc/0.4.mdwn b/open_issues/glibc/0.4.mdwn
index ceb5ea21..f864469d 100644
--- a/open_issues/glibc/0.4.mdwn
+++ b/open_issues/glibc/0.4.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
@@ -10,6 +10,8 @@ License|/fdl]]."]]"""]]
[[!tag open_issue_glibc open_issue_libpthread]]
+Things to consider doing when bumping the glibc SONAME.
+
# IRC, freenode, #hurd, 2012-12-14
diff --git a/open_issues/glibc/debian.mdwn b/open_issues/glibc/debian.mdwn
index 331632f3..9886ec98 100644
--- a/open_issues/glibc/debian.mdwn
+++ b/open_issues/glibc/debian.mdwn
@@ -62,3 +62,70 @@ apter applying patches.
If the Debian symbol versioning file is not up to date and the build of Debian
packages fails due to this, putting `DPKG_GENSYMBOLS_CHECK_LEVEL=0` in the
environment \`\`helps''; see `man dpkg-gensymbols`.
+
+
+# IRC, freenode, #hurd, 2013-07-01
+
+ <braunr> something seems to have changed with regard to patch handling in
+ eglibc 2.17
+ <braunr> pinotree: when i add a patch to series and use dpkg-buildpackage,
+ i'm told there are local modifications and the build stops :/
+ <braunr> any idea what i'm doing wrong ?
+ <pinotree> which steps do you do?
+ <braunr> i extract the sources, copy the patch to debian/patches/hurd-i386,
+ add the appropriate line to debian/patches/series, call dch -i, then
+ dpkg-buildpackage
+ <pinotree> eglibc is a "3.0 (quilt)" format source package
+ <pinotree> this means its default patches are in a quilt-style system, and
+ they are applied on extraction
+ <braunr> ok
+ <braunr> and it can't detect new patches ?
+ <pinotree> so if you add a new patch to the global serie, you have to push
+ it manually
+ <braunr> i have to revert them all ?
+ <braunr> ok
+ <braunr> how do i do that ?
+ <pinotree> quilt push -a
+ <braunr> ok
+ <braunr> thanks
+ <pinotree> remember to do that before starting the build, since the rest
+ assumes the quilt-style patches are fully applied
+ <bddebian> No push applies them, quilt pop -a reverts them
+ <pinotree> yeah, and he has to push the new over the dpkg-applied ones
+ <bddebian> Oh, aye
+ <braunr> does quilt change series ?
+ <pinotree> no
+ <braunr> ok
+ <pinotree> i mean, some commands do that
+ <braunr> so i do everything i did, with an additional push, right ?
+ <pinotree> ok, screw me, i didn't get your question above :P
+ <braunr> does that change your answer ?
+ <pinotree> <braunr> does quilt change series ?
+ <braunr> yes
+ <pinotree> if you import or create a new patch, it changes series indeed
+ <braunr> ok
+ <pinotree> push or pop of patches does not
+ <braunr> i'm doing it wron
+ <braunr> g
+ <pinotree> btw, in a quilt patch stack you can easily import a new patch
+ using the import command
+ <pinotree> so for example you could do
+ <pinotree> apt-get source eglibc # or get it somehow else
+ <pinotree> cd eglibc-*
+ <pinotree> quilt import /location/of/my/patch
+ <pinotree> quilt push # now your patch is applied
+ <braunr> ah thanks
+ <pinotree> dpkg-buildpackage as usual
+ <braunr> that's what i was looking for
+ <bddebian> quilt new adds a new entry in series
+ <pinotree> y
+ <bddebian> or import, aye
+ <pinotree> braunr: if you want to learn quilt, a very good doc is its own,
+ eg /usr/share/doc/quilt/quilt.txt.gz
+ * bddebian has never actually used import
+ <braunr> ok
+ <pinotree> it is basically a simple stack of patches
+
+ <youpi> braunr: yes, patch handling is a bit different
+ <youpi> the arch-independant patches are applied by dpkg-source -x
+ <youpi> and the arch-dependent patches are applied during build
diff --git a/open_issues/glibc/debian/experimental.mdwn b/open_issues/glibc/debian/experimental.mdwn
index 8d117e99..5168479d 100644
--- a/open_issues/glibc/debian/experimental.mdwn
+++ b/open_issues/glibc/debian/experimental.mdwn
@@ -11,6 +11,7 @@ License|/fdl]]."]]"""]]
[[!tag open_issue_glibc]]
Issues with the current 2.17 version of glibc/EGLIBC in Debian experimental.
+Now in unstable.
# IRC, OFTC, #debian-hurd, 2013-03-14
@@ -113,3 +114,62 @@ Issues with the current 2.17 version of glibc/EGLIBC in Debian experimental.
eventually? (Some experimental package(s), but which?)
<youpi> that was libc0.3 packages
<youpi> which are indeed known to break the network
+
+
+# IRC, freenode, #hurd, 2013-06-18
+
+ <braunr> root@darnassus:~# dpkg-reconfigure locales
+ <braunr> Generating locales (this might take a
+ while)... en_US.UTF-8...Segmentation fault
+ <braunr> is it known ?
+ <youpi> uh, no
+
+
+## IRC, OFTC, #debian-hurd, 2013-06-19
+
+ <pinotree> btw i saw too the segmentation fault when generating locales
+
+
+# IRC, OFTC, #debian-hurd, 2013-06-20
+
+ <youpi> damn
+ <youpi> hang at ext2fs boot
+ <youpi> static linking issue, clearly
+
+
+## IRC, freenode, #hurd, 2013-06-30
+
+ <youpi> Mmm
+ <youpi> __access ("/etc/ld.so.nohwcap", F_OK) at startup of ext2fs
+ <youpi> deemed to fail....
+ <pinotree> when does that happen?
+ <youpi> at hwcap initialization
+ <youpi> at least that's were ext2fs.static linked against libc 2.17 hangs
+ at startup
+ <youpi> and this is indeed a very good culprit :)
+ <pinotree> ah, a debian patch
+ <youpi> does anybody know a quick way to know whether one is the / ext2fs ?
+ :)
+ <pinotree> isn't the root fs given a special port?
+ <youpi> I was thinking about something like this, yes
+ <youpi> ok, boots
+ <youpi> I'll build a 8~0 that includes the fix
+ <youpi> so people can easily build the hurd package
+ <youpi> Mmm, no, the bootstrap port is also NULL for normally-started
+ processes :/
+ <youpi> I don't understand why
+ <youpi> ah, only translators get a bootstrap port :/
+ <youpi> perhaps CRDIR then
+ <youpi> (which makes a lot of sense)
+
+
+## IRC, freenode, #hurd, 2013-07-01
+
+ <braunr> youpi: what is local-no-bootstrap-fs-access.diff supposed to fix ?
+ <youpi> ext2fs.static linked againt debian glibc 2.17
+ <youpi> well, as long as you don't build & use ext2fs.static with it...
+ <braunr> that's thing, i want to :)
+ <braunr> +the
+ <youpi> I'd warmly welcome a way to detect whether being the / translator
+ process btw
+ <youpi> it seems far from trivial
diff --git a/open_issues/glibc/t/tls-threadvar.mdwn b/open_issues/glibc/t/tls-threadvar.mdwn
index 105a07c7..609d866b 100644
--- a/open_issues/glibc/t/tls-threadvar.mdwn
+++ b/open_issues/glibc/t/tls-threadvar.mdwn
@@ -64,3 +64,15 @@ dropped altogether, and `__thread` directly be used in glibc.
<youpi> I saw the mails, but didn't investigate at all
[[!message-id "878vdyqht3.fsf@kepler.schwinge.homeip.net"]].
+
+
+# IRC, freenode, #hurd, 2013-07-08
+
+ <youpi> tschwinge: apparently there were a lot of changes missing in the
+ threadvars branch I had commited long time ago
+ <youpi> I'm gathering things
+ <tschwinge> youpi: t/tls-threadvar you mean?
+ <youpi> yes
+ <youpi> tschwinge: yes, there were a lot other occurences of threadvars
+ stuff in various places
+ <youpi> I'm building libc again, and will see what issue would remain
diff --git a/open_issues/libc_variant_selection.mdwn b/open_issues/libc_variant_selection.mdwn
index afcd9ae0..71370a43 100644
--- a/open_issues/libc_variant_selection.mdwn
+++ b/open_issues/libc_variant_selection.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
@@ -28,6 +29,28 @@ On Thu, Oct 07, 2010 at 11:22:46AM +0200, Samuel Thibault wrote:
> Yes, you need to copy it by hand. Same for libc0.3-i686, we just need to
> steal the cpuid code from the kfreebsd port of glibc.
+
+# IRC, freenode, #hurd, 2013-06-30
+
+ <pinotree> other than that, the hwcap system is not working for us yet,
+ right?
+ <youpi> no but we'd like to use e.g. cpuid for that
+ <youpi> like kfreebsd does
+ <pinotree> do they use cpuid for that?
+ <pinotree> i kind of lost myself in glibc's loading internals, trying to
+ find out where the hwcap bits come from
+ <youpi> on linux it comes from the kernel
+ <youpi> on kfreebsd aiui they use cpuid to figure it out from the process
+ itself
+ <pinotree> do you have any pointer to the kfreebsd way? iirc i had a look
+ in their sysdeps, but found nothing related to that
+ <youpi> it's in local-sysdeps.diff aiui
+ <youpi> +dl_platform_kfreebsd_i386_init
+ <youpi> which fills dl_hwcap
+ <youpi> called at _dl_sysdep_start
+ <pinotree> interesting
+
+
---
Having working CPUID code inside [[glibc]] is also a prerequisite for proper
diff --git a/open_issues/libnetfs_argument_parsing.mdwn b/open_issues/libnetfs_argument_parsing.mdwn
new file mode 100644
index 00000000..e1e0d794
--- /dev/null
+++ b/open_issues/libnetfs_argument_parsing.mdwn
@@ -0,0 +1,62 @@
+[[!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]]."]]"""]]
+
+[[!tag open_issue_hurd]]
+
+# IRC, freenode, #hurd, 2013-06-27
+
+ <teythoon> the arg parsing in libdiskfs and libnetfs differ :/
+ <teythoon> afaics libdiskfs gets it right, libnetfs does not
+ <pinotree> what do you mean?
+ <teythoon> wrt to *_std_{runtime,startup}_argp
+ <teythoon> see eg netfs.h
+ <teythoon> libdiskfs/opts-std-runtime.c:const struct argp
+ diskfs_std_runtime_argp =
+ <teythoon> libdiskfs/opts-std-runtime.c-{
+ <teythoon> libdiskfs/opts-std-runtime.c- std_runtime_options, parse_opt,
+ 0, 0, children
+ <teythoon> libdiskfs/opts-std-runtime.c-};
+ <teythoon> but
+ <teythoon> libnetfs/std-runtime-argp.c:const struct argp
+ netfs_std_runtime_argp = { 0 };
+ <pinotree> well there are no common startup/runtime options provided by
+ netfs
+ <pinotree> usually netfs-based translators put netfs_std_startup_argp as
+ child as their options, so if netfs starts providing options they would
+ work
+ <teythoon> ah
+ <pinotree> if you have a test showing issues, we can certainly look it :)
+ <teythoon> ok, m/b I was confused...
+ <pinotree> no worries, feel free to ask anytime
+ <teythoon> I thought about providing --update as common runtime flag, like
+ diskfs does, you think it's the right thing to do?
+ <pinotree> what would it do?
+ <teythoon> or should it be left for each translator to implement?
+ <teythoon> nothing by default I guess
+ <pinotree> options provided in libdiskfs are implemented and handled mostly
+ in libdiskfs itself
+ <pinotree> so imho a new option for libnetfs would be there because its
+ behaviour is implemented mostly within libnetfs itself
+ <teythoon> libdiskfs calls diskfs_reload_global_state
+ <teythoon> libnetfs could do the same, allowing translators to plug in
+ anything they wish
+ <teythoon> but I'll implement it in procfs for the time being
+ <pinotree> ah, its alias is remount
+ <teythoon> yes
+ <teythoon> I need that working for procfs
+ <teythoon> btw, I think I got your mount confusion thing figured out
+ <pinotree> but procfs has nothing to update/flush, all the information are
+ fetched at every rpc
+ <teythoon> yes
+ <teythoon> but we still need to ignore the flag
+ <teythoon> otherwise the set_options rpc fails
+ <teythoon> http://paste.debian.net/12938/
+ <teythoon> whee, remounting proc works :)
+ <braunr> :)
diff --git a/open_issues/libpthread.mdwn b/open_issues/libpthread.mdwn
index e2fda122..8e3fde71 100644
--- a/open_issues/libpthread.mdwn
+++ b/open_issues/libpthread.mdwn
@@ -1260,7 +1260,7 @@ Most of the issues raised on this page has been resolved, a few remain.
<braunr> i'll add traces to know which step causes the error
-### IRC, freenode, #hurd, 2012-12-11
+#### IRC, freenode, #hurd, 2012-12-11
<youpi> braunr: mktoolnix seems like a reproducer for the libports thread
priority issue
@@ -1273,7 +1273,7 @@ Most of the issues raised on this page has been resolved, a few remain.
<youpi> that's it, yes
-### IRC, freenode, #hurd, 2013-03-01
+#### IRC, freenode, #hurd, 2013-03-01
<youpi> braunr: btw, "unable to adjust libports thread priority: (ipc/send)
invalid destination port" is actually not a sign of fatality
@@ -1284,6 +1284,34 @@ Most of the issues raised on this page has been resolved, a few remain.
<braunr> weird sentence, agreed :p
+#### IRC, freenode, #hurd, 2013-06-14
+
+ <gnu_srs> Hi, when running check for gccgo the following occurs (multiple
+ times) locking up the console
+ <gnu_srs> unable to adjust libports thread priority: (ipc/send) invalid
+ destination port
+ <gnu_srs> (not locking up the console, it was just completely filled with
+ messages))
+ <braunr> gnu_srs: are you running your translator as root ?
+ <braunr> or, do you have a translator running as an unprivileged user ?
+ <braunr> hm, invalid dest port
+ <braunr> that's a bug :p
+ <braunr> but i don't know why
+ <braunr> i'll have to take some time to track it down
+ <braunr> it might be a user ref overflow or something similarly tricky
+ <braunr> gnu_srs: does it happen everytime you run gccgo checks or only
+ after the system has been alive for some time ?
+ <braunr> (some time being at least a few hours, more probably days)
+
+#### IRC, freenode, #hurd, 2013-07-05
+
+ <braunr> ok, found the bug about invalid ports when adjusting priorities
+ <braunr> thhe hurd must be plagued with wrong deallocations :(
+ <braunr> i have so many problems when trying to cleanly destroy threads
+
+[[libpthread/t/fix_have_kernel_resources]].
+
+
### IRC, freenode, #hurd, 2013-03-11
<braunr> youpi: oh btw, i noticed a problem with the priority adjustement
@@ -1296,6 +1324,171 @@ Most of the issues raised on this page has been resolved, a few remain.
<youpi> uh
<youpi> indeed
+### IRC, freenode, #hurd, 2013-07-01
+
+ <youpi> braunr: it seems as if pfinet is not prioritized enough
+ <youpi> I'm getting network connectivity issues when the system is quite
+ loaded
+ <braunr> loaded with what ?
+ <braunr> it could be ext2fs having a lot more threads than other servers
+ <youpi> building packages
+ <youpi> I'm talking about the buildds
+ <braunr> ok
+ <braunr> ironforge or others ?
+ <youpi> they're having troubles uploading packages while building stuff
+ <youpi> ironforge and others
+ <youpi> that happened already in the past sometimes
+ <youpi> but at the moment it's really pronounced
+ <braunr> i don't think it's a priority issue
+ <braunr> i think it's swapping
+ <youpi> ah, that's not impossible indeed
+ <youpi> but why would it swap?
+ <youpi> there's a lot of available memory
+ <braunr> a big file is enough
+ <braunr> it pushes anonymous memory out
+ <youpi> to fill 900MiB memory ?
+ <braunr> i see 535M of swap on if
+ <braunr> yes
+ <youpi> ironforge is just building libc
+ <braunr> and for some reason, swapping is orders of magnitude slower than
+ anything else
+ <youpi> not linking it yet
+ <braunr> i also see 1G of free memory on it
+ <youpi> that's what I meant with 900MiB
+ <braunr> so at some point, it needed a lot of memory, caused swapping
+ <braunr> and from time to time it's probably swapping back
+ <youpi> well, pfinet had all the time to swap back already
+ <youpi> I don't see why it should be still suffering from it
+ <braunr> swapping is a kernel activity
+ <youpi> ok, but once you're back, you're back
+ <youpi> unless something else pushes you out
+ <braunr> if the kernel is busy waiting for the default pager, nothing makes
+ progress
+ <braunr> (eccept the default pager hopefully)
+ <youpi> sure but pfinet should be back already, since it does work
+ <youpi> so I don't see why it should wait for something
+ <braunr> the kernel is waiting
+ <braunr> and the kernel isn't preemptibl
+ <braunr> e
+ <braunr> although i'm not sure preemption is the problem here
+ <youpi> well
+ <youpi> what I don't understand is what we have changed that could have so
+ much impact
+ <youpi> the only culprit I can see is the priorities we have changed
+ recently
+ <braunr> do you mean it happens a lot more frequently than before ?
+ <youpi> yes
+ <youpi> way
+ <braunr> ok
+ <youpi> ironforge is almost unusable while building glibc
+ <youpi> I've never seen that
+ <braunr> that's weird, i don't have these problems on darnassus
+ <braunr> but i think i reboot it more often
+ <braunr> could be a scalability issue then
+ <braunr> combined with the increased priorities
+ <braunr> if is indeed running full time on the host, whereas swapping
+ issues show the cpu being almost idle
+ <braunr> loadavg is high too so i guess there are many threads
+ <braunr> 0 971 3 -20 -20 1553 305358625 866485906 523M 63M * S<o
+ ? 13hrs /hurd/ext2fs.static -A /dev/hd0s2
+ <braunr> 0 972 3 -20 -20 1434 125237556 719443981 483M 5.85M * S<o
+ ? 13hrs /hurd/ext2fs.static -A /dev/hd0s3
+ <braunr> around 1k5 each
+ <youpi> that's quite usual
+ <braunr> could be the priorities then
+ <braunr> but i'm afraid that if we lower them, the number of threads will
+ grow out of control
+ <braunr> (good thing is i'm currently working on a way to make libpthread
+ actually remove kernel resources)
+ <youpi> but the priorities should be the same in ext2fs and pfinet,
+ shouldn't they?
+ <braunr> yes but ext2 has a lot more threads than pfinet
+ <braunr> the scheduler only sees threads, we don't have a grouping feature
+ <youpi> right
+ <braunr> we also should remove priority depressing in glibc
+ <braunr> (in sched_yield)
+ <braunr> it affects spin locks
+
+ <braunr> youpi: is it normal to see priorities of 26 ?
+ <youpi> braunr: we have changed the nice factor
+ <braunr> ah, factor
+ <youpi> Mm, I'm however realizing the gnumach kernel running these systems
+ hasn't been upgraded in a while
+ <youpi> it may not even have the needed priority levels
+ <braunr> ar euare you using top right now on if ?
+ <braunr> hm no i don't see it any more
+ <braunr> well yes, could be the priorities ..
+ <youpi> I've rebooted with an upgraded kernel
+ <youpi> no issue so far
+ <youpi> package uploads will tell me on the long run
+ <braunr> i bet it's also a scalability issue
+ <youpi> but why would it appear now only?
+ <braunr> until the cache and other data containers start to get filled,
+ processing is fast enough that we don't see it hapenning
+ <youpi> sure, but I haven't seen that in the past
+ <braunr> oh it's combined with the increased priorities
+ <youpi> even after a week building packages
+ <braunr> what i mean is, increased priorities don't affect much if threads
+ porcess things fast
+ <braunr> things get longer with more data, and then increased prioritis
+ give more time to these threads
+ <braunr> and that's when the problem appears
+ <youpi> but increased priorities give more time to the pfinet threads too,
+ don't they?
+ <braunr> yes
+ <youpi> so what is different ?
+ <braunr> but again, there are a lot more threads elsewhere
+ <braunr> with a lot more data to process
+ <youpi> sure, but that has alwasy been so
+ <braunr> hm
+ <youpi> really, 1k5 threads does not surprise me at all :)
+ <youpi> 10k would
+ <braunr> there aren't all active either
+ <youpi> yes
+ <braunr> but right, i don't know why pfinet would be given less time than
+ other threads ..
+ <braunr> compared to before
+ <youpi> particularly on xen-based buildds
+ <braunr> libpthread is slower than cthreads
+ <youpi> where it doesn't even have to wait for netdde
+ <braunr> threads need more quanta to achieve the same ting
+ <braunr> perhaps processing could usually be completed in one go before,
+ and not any more
+ <braunr> we had a discussion about this with antrik
+
+ <braunr> youpi: concerning the buildd issue, i don't think pfinet is
+ affected actually
+ <braunr> but the applications using the network may be
+ <youpi> why using the network would be a difference ?
+ <braunr> normal applications have a lower priority
+ <braunr> what i mean is, pfinet simply has nothing to do, because normal
+ applications don't have enough cpu time
+ <braunr> (what you said earlier seemed to imply pfinet had issues, i don't
+ think it has)
+ <braunr> it should be easy to test by pinging the machine while under load
+ <braunr> we should also check the priority of the special thread used to
+ handle packets, both in pfinet and netdde
+ <braunr> this one isn't spawned by libports and is likely to have a lower
+ priority as well
+
+ <braunr> youpi: you're right, something very recent slowed things down a
+ lot
+ <braunr> perhaps the new priority factor
+ <braunr> well not the factor but i suppose the priority range has been
+ increased
+
+[[nice_vs_mach_thread_priorities]].
+
+ <youpi> braunr: haven't had any upload issue so far
+ <youpi> over 20 uploads
+ <youpi> while it was usually 1 every 2 before...
+ <youpi> so it was very probably the kernel missing the priorities levels
+ <braunr> ok
+ <braunr> i think i've had the same problem on another virtual machine
+ <braunr> with a custom kernel i built a few weeks ago
+ <braunr> same kind of issue i guess
+ <braunr> it's fine now, and always was on darnassus
+
## IRC, freenode, #hurd, 2012-12-05
diff --git a/open_issues/libpthread/t/fix_have_kernel_resources.mdwn b/open_issues/libpthread/t/fix_have_kernel_resources.mdwn
index 10577c1e..4e35161f 100644
--- a/open_issues/libpthread/t/fix_have_kernel_resources.mdwn
+++ b/open_issues/libpthread/t/fix_have_kernel_resources.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
@@ -10,7 +10,9 @@ License|/fdl]]."]]"""]]
[[!tag open_issue_libpthread]]
-`t/have_kernel_resources`
+`t/fix_have_kernel_resources`
+
+Address problem mentioned in [[/libpthread]], *Threads' Death*.
# IRC, freenode, #hurd, 2012-08-30
@@ -19,3 +21,178 @@ License|/fdl]]."]]"""]]
<braunr> tschwinge: i.e. the ability to tell the kernel where the stack is,
so it's unmapped when the thread dies
<braunr> which requiring another thread to perform this deallocation
+
+
+## IRC, freenode, #hurd, 2013-05-09
+
+ <bddebian> braunr: Speaking of which, didn't you say you had another "easy"
+ task?
+ <braunr> bddebian: make a system call that both terminates a thread and
+ releases memory
+ <braunr> (the memory released being the thread stack)
+ <braunr> this way, a thread can completely terminates itself without the
+ assistance of a managing thread or deferring work
+ <bddebian> braunr: That's "easy" ? :)
+ <braunr> bddebian: since it's just a thread_terminate+vm_deallocate, it is
+ <braunr> something like thread_terminate_self
+ <bddebian> But a syscall not an RPC right?
+ <braunr> in hurd terminology, we don't make the distinction
+ <braunr> the only real syscalls are mach_msg (obviously) and some to get
+ well known port rights
+ <braunr> e.g. mach_task_self
+ <braunr> everything else should be an RPC but could be a system call for
+ performance
+ <braunr> since mach was designed to support clusters, it was necessary that
+ anything not strictly machine-local was an RPC
+ <braunr> and it also helps emulation a lot
+ <braunr> so keep doing RPCs :p
+
+
+## IRC, freenode, #hurd, 2013-05-10
+
+ <braunr> i'm not sure it should only apply to self though
+ <braunr> youpi: can we get a quick opinion on this please ?
+ <braunr> i've suggested bddebian to work on a new RPC that both terminates
+ a thread and releases its stack to help fix libpthread
+ <braunr> and initially, i thought of it as operating only on the calling
+ thread
+ <braunr> do you see any reason to make it work on any thread ?
+ <braunr> (e.g. a real thread_terminate + vm_deallocate)
+ <braunr> (or any reason not to)
+ <youpi> thread stack deallocation is always a burden indeed
+ <youpi> I'd tend to think it'd be useful, but perhaps ask the list
+
+
+## IRC, freenode, #hurd, 2013-06-26
+
+ <braunr> looks like there is a port right leak in libpthread
+ <braunr> grmbl, the port leak seems to come from mach_port_destroy being
+ buggy :/
+ <braunr> hum, apparently we're not the only ones to suffer from port leaks
+ wrt mach_port_destroy
+ <braunr> ew, libpthread is leaking
+ <pinotree> memory or ports?
+ <braunr> both
+ <pinotree> sounds great ;)
+ <braunr> as it is, libpthread doesn't destroy threads
+ <braunr> it queues them so they're recycled late
+ <braunr> r
+ <braunr> but there is confusion between the thread structure itself and its
+ internal resources
+ <braunr> i.e. there is pthread_alloc which allocates a thread structure,
+ and pthread_create which allocates everything else
+ <braunr> but on pthread_exit, nothing is destroyed
+ <braunr> when a thread structure is reused, its internal resources are
+ replaced by new instances
+ <pinotree> oh
+ <braunr> it's ok for joinable threads but most of our threads are detached
+ <braunr> pinotree: as expected, it's bigger than expected :p
+ <braunr> so i won't be able to write a quick fix
+ <braunr> the true way to fix this is make it possible for threads to free
+ their own resources
+ <braunr> let's do that :p
+ <braunr> ok, got the new thread termination function, i'll build eglibc
+ package providing it, then experiment with libpthread
+ <pinotree> braunr: iirc there's also a tschwinge patch in the debian eglibc
+ about that
+ <braunr> ah
+ <pinotree> libpthread_fix.diff
+ <braunr> i see
+ <braunr> thanks for the notice
+ <braunr> bddebian:
+ http://www.sceen.net/~rbraun/0001-thread_terminate_deallocate.patch
+ <braunr> bddebian: this is what it looks like
+ <braunr> see, short and easy
+ <bddebian> Aye but didn't youpi say not to bother with it??
+ <braunr> he did ?
+ <braunr> i don't remember
+ <bddebian> I thought that was the implication. Or maybe that was the one I
+ already did!?
+ <braunr> i'd be interested in reading that
+ <braunr> anyway, there still are problems in libpthread, and this call is
+ one building block to fix some of them
+ <braunr> some important ones
+ <braunr> (big leaks)
+
+
+## IRC, freenode, #hurd, 2013-06-29
+
+ <braunr> damn, i fix leaks in libpthread, only to find out leaks somewhere
+ else :(
+ <braunr> bddebian: ok, actually it was a bit more complicated than what i
+ showed you
+ <braunr> because in addition to the stack, the call must also release the
+ send right in the caller's ipc space
+ <braunr> (it can't be released before since there would be no mean to
+ reference the thread to destroy)
+ <braunr> or perhaps it should strictly be reserved to self termination
+ <braunr> hmm
+ <braunr> yes it would probably be simpler
+ <braunr> but it should be a decent compromise
+ <braunr> i'm close to having a libpthread that doesn't leak anything
+ <braunr> and that properly destroys threads and their resources
+
+
+## IRC, freenode, #hurd, 2013-06-30
+
+ <braunr> bddebian: ok, it was even more tricky, because the kernel would
+ save the return value on the user stack (which is released by the call
+ and then invalid) before checking for asynchronous software traps (ASTs,
+ a kind of software interrupts in mach), and terminating the calling
+ thread is done by a deferred AST ... :)
+ <braunr> hmm, making threads able to terminate themselves makes rpctrace a
+ bit useless :/
+ <braunr> well, more restricted
+
+ <braunr> ok so, tough question :
+ <braunr> i have a small test program that creates a thread, and inspect its
+ state before any thread dies
+ <braunr> i can see msg_report_wait requests when using ps
+ <braunr> (one per thread)
+ <braunr> one of these requests create a new receive right, apparently for
+ the second thread in the test program
+ <braunr> each time i use ps, i can see the sequence numbers of two receive
+ rights increase
+ <braunr> i guess these rights are related to proc and signal handling per
+ thread
+ <braunr> but i can't find what create them
+ <braunr> does anyone know ?
+ <braunr> tschwing_: ^ :)
+
+ <braunr> again, too many things wrong elsewhere to cleanly destroy threads
+ ..
+ <braunr> something is deeply wrong with controlling terminals ..
+
+
+## IRC, freenode, #hurd, 2013-07-01
+
+ <braunr> youpi: if you happen to notice what receive right is created for
+ each thread (beyond the obvious port used for blocking and waking up),
+ please let me know
+ <braunr> it's the only port leak i have with thread destruction
+ <braunr> and i think it's related to the proc server since i see the
+ sequence number increase every time i use ps
+
+ <braunr> pinotree: my change doesn't fix all the pthread leaks but it's a
+ lot better
+ <braunr> bddebian: i've spent almost the whole week end trying to find the
+ last port leak without success
+ <braunr> there is some weird bug related to the controlling tty that hits
+ me every time i try to change something
+ <braunr> it's the same bug that prevents ttys from being correctly closed
+ when using ssh or screen
+ <braunr> well maybe not the same, but it's close
+ <braunr> some stale receive right kept around for no apparent reason
+ <braunr> and i can't find its source
+
+
+## IRC, freenode, #hurd, 2013-07-02
+
+ <braunr> and btw, i don't think i can make my libpthread patch work
+ <braunr> i'll just aim at avoiding leaks, but destroying threads and their
+ related resources depends on other changes i don't clearly see
+
+
+## IRC, freenode, #hurd, 2013-07-03
+
+ <braunr> grmbl, i don't want to give up thread destruction ..
diff --git a/open_issues/libpthread_assertion_thread_prevp.mdwn b/open_issues/libpthread_assertion_thread_prevp.mdwn
index e8160528..f93f07d6 100644
--- a/open_issues/libpthread_assertion_thread_prevp.mdwn
+++ b/open_issues/libpthread_assertion_thread_prevp.mdwn
@@ -87,3 +87,23 @@ failed"]]
<braunr> removing the libports_stability patch exposed bugs in libpthread,
triggering assertions when queueing/dequeue threads from a queue (but i
don't know which one / in which function)
+
+
+## IRC, freenode, #hurd, 2013-06-25
+
+ <pinotree> braunr:
+ https://buildd.debian.org/status/fetch.php?pkg=libmemcached&ver=1.0.17-2&arch=hurd-i386&stamp=1372165732
+ <pinotree> make: ./pthread/pt-internal.h:122: __pthread_enqueue: Assertion
+ `thread->prevp == 0' failed. \o/
+ <pinotree> (it should rather be /o\, but better pretend not)
+ <braunr> pinotree: yes, we regularly see it
+ <braunr> pinotree: how long has the machine been running at this point ?
+ <pinotree> dunno, you should ask samuel about that
+ <pinotree> does it happen after N hours/days?
+ <braunr> a few days of moderate to high activity yes
+ <pinotree> ah ok
+ <braunr> and i actually see this error much more often when i disable the
+ libports stability patch in the hurd debian package
+ <braunr> so i guess something is wrong with thread recycling
+ <braunr> but i wanted to completely rewrite that part with the new kernel
+ call i asked bddebian to work on :)
diff --git a/open_issues/mondriaan_memory_protection.mdwn b/open_issues/mondriaan_memory_protection.mdwn
new file mode 100644
index 00000000..2c7b9ba1
--- /dev/null
+++ b/open_issues/mondriaan_memory_protection.mdwn
@@ -0,0 +1,85 @@
+[[!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]]."]]"""]]
+
+<http://scale.eecs.berkeley.edu/mondriaan/>.
+
+
+# IRC, freenode, #hurd, 2013-07-02
+
+ <xscript> in any case, what I wanted to check is if current hurd support
+ PIE
+ <xscript`> I just saw samuel posted some fixes to have PIE working in hurd
+ <xscript`> are those included in the official image?
+ <youpi> sure
+ <youpi> it's just a trivial fixup in some address calculation code
+ <xscript> youpi: nice
+ <xscript> and does anyone know how complex would it be to implement some
+ hackish support to have non-overlapping virtual addresses for
+ applications supporting PIE?
+ <braunr> not too difficult
+ <xscript> really? I didn't expect such an answer XD
+ <xscript> I'd like to have something similar to a SASOS
+ <xscript> (single address space os)
+ <braunr> ?
+ <braunr> you mean an sasos on top of mach ?
+ <xscript> yes, but only for a few apps I want to evaluate
+ <braunr> i see
+ <xscript> the optimal would be to have all of hurd's servers on that mode
+ <braunr> you'l probably need to implement a small allocator but other than
+ that it shouldn't be too hard, yes
+ <braunr> uh ??
+ <xscript> but running on 32 bits can be a problem here
+ <braunr> and not hurdish at all
+ <xscript> what's not hurdish?
+ <braunr> we do want address space separation
+ <xscript> well, you can have multiple address spaces (page tables), but
+ without overlapping addresses between them
+ <xscript> that's exactly what I'm looking for
+ <braunr> sorry i don't see what you mean
+ <braunr> if you run several servers in the same address space, they can
+ corrupt each other
+ <braunr> we don't want that
+ <braunr> it's that simple
+ <xscript> yes, sorry, I didn't explain myself
+ <xscript> I want a separate address space on each server
+ <xscript> but I want all memory allocations to be on addresses unique to
+ the whole OS
+ <braunr> that still doesn't make sense
+ <xscript> well, it will still be secure
+ <xscript> but I know it does not make sense per se
+ <xscript> I want to do some experiments with a simulator
+ <braunr> why do you want them non overlapping if they're separate ?
+ <xscript> well, in my simulator I wouldn't need to change the page tables,
+ protection is provided through other means
+ <braunr> segmentation ?
+ <xscript> that's one possibility
+ <xscript> (small address spaces)
+ <braunr> what do you have in mind ?
+ <braunr> it wouldn't be on top of mach anyway then
+ <braunr> mach implements paging
+ <xscript> what I'm simulating is something of the likes of Mondriaan
+ (http://www.cs.utexas.edu/~witchel/pubs/mmp-asplos2002.pdf)
+ <xscript> paging is ok for me
+ <braunr> 19:06 < xscript> well, in my simulator I wouldn't need to change
+ the page tables, protection is provided through other means
+ <braunr> it didn't sound so
+ <xscript> I meant switching page tables (cr3, etc)
+ <braunr> mach does that
+ <xscript> I know, I know, I can just ignore that part for the moment
+ <braunr> ok
+ <xscript> for now, I'd like to morph hurd into a SASOS using one page table
+ per process
+ <xscript> I just wanted to know how hard that would be, without starting
+ with a full dive into the code
+ <xscript> there are other options (OSes, microkernels), but none of them
+ provides as many readily-available applications as hurd
+ <xscript> I suppose MINIX would also be easy to modify, but there's less
+ apps there, and I also would like to tamper with MIG
+ <xscript> I just wonder how hard it would be to modify MIG
diff --git a/open_issues/some_todo_list.mdwn b/open_issues/some_todo_list.mdwn
index 80592abf..48c2944d 100644
--- a/open_issues/some_todo_list.mdwn
+++ b/open_issues/some_todo_list.mdwn
@@ -42,6 +42,21 @@ From Marcus, 2002:
* Translators
* Does settrans -g work? -fg?
* Does fsysopts work? Does setting options with fsysopts work?
+
+ IRC, freenode, #hurd, 2013-05-23:
+
+ <gnu_srs> fsysopts /servers/socket/2 works by /1 gives Operation not
+ supported.
+
+ [[!taglink open_issue_hurd]].
+
+ <braunr> ah right, some servers don't implement that
+ <braunr> work around this by using showtrans
+ <braunr> fsysopts asks the server itself how it's running, usually giving
+ its command name and options
+ <braunr> showtrans asks the parent how it starts a passive translator
+ attached to the node
+ <gnu_srs> Yes showtrans works :), thanks.
* Does stat() work on all translated nodes and give proper data?
* What about chown, chmod (some translators should pass this through to the underlying node, esp in /dev!)
* Does statfs give correct data?
diff --git a/open_issues/translator_stdout_stderr.mdwn b/open_issues/translator_stdout_stderr.mdwn
index 14ea1c6d..89efd4e1 100644
--- a/open_issues/translator_stdout_stderr.mdwn
+++ b/open_issues/translator_stdout_stderr.mdwn
@@ -1,5 +1,5 @@
-[[!meta copyright="Copyright © 2008, 2009, 2010, 2011 Free Software Foundation,
-Inc."]]
+[[!meta copyright="Copyright © 2008, 2009, 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
@@ -9,25 +9,69 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]
-[[!tag open_issue_hurd]]
+[[!toc]]
-There have been several discussions and proposals already, about adding a
-suitable logging mechanism to translators, for example.
+# "Weird Issue"
-Decide / implement / fix that (all?) running (passive?) translators' output
-should show up on the (Mach / Hurd) console / syslog.
+## IRC, freenode, #hurd, 2013-07-01
+[[!tag open_issue_hurd]]
-[[!taglink open_issue_documentation]]: [[!message-id
-"87oepj1wql.fsf@becket.becket.net"]]
+ <teythoon> oh, btw, there is this weird issue that I cannot figure out
+ <teythoon> I noticed that there is no newline printed by /hurd/init after
+ printing " proc" and " auth"
+ <teythoon> but there *is* a printf("\n"); fflush(stdout); in there
+ <teythoon> it's just not working
+ <pinotree> iirc a newline is supposed to be printed after all the essential
+ servers have been started
+ <pinotree> that one
+ <teythoon> yes
+ <teythoon> but this doesn't happen
+ <teythoon> for whatever reason printf("foo"); yields no output
+ <braunr> how are proc and auth printed ?
+ <teythoon> neither does printf("%s", "foo");
+ <teythoon> using printf
+ <teythoon> but printf("%i fooo", 4); works
+ <youpi> uh
+ <braunr> ??
+ <youpi> and does printf("loooooooooong line") worker?
+ <teythoon> no
+ <youpi> uh
+ <youpi> -er
+ <teythoon> and yes, the code is always fflushing stdout
+ <youpi> perhaps trying to put a sleep(1); to check for timing issues?
+ <teythoon> yes, I suspect something like that
+ <teythoon> b/c *sometimes* my hurd just freezes at this point
+ <braunr> ???
+ <teythoon> after printing proc auth and not printing the newline
+ <braunr> such horror stories .
+ <braunr> ..
+ <teythoon> and I *think* that putting more printfs there for testing
+ purposes makes this worse, but I'm not sure about this
+ <braunr> in case you need to debug using printf, there is the mach_print
+ system call
+ <braunr> (in -dbg kernels)
+[[microkernel/mach/gnumach/interface/syscall/mach_print]].
-[[!taglink open_issue_documentation]]: Neal once had written an email on this
-topic.
+ <teythoon> what's wrong with using printf?
+ <braunr> you need to write the little assembly call yourself, where you
+ intend to use it, because it's not exported by glibc
+ <braunr> printf is an RPC
+ <braunr> teythoon: RPCs are complicated stuff
+ <braunr> in particular in core glibc parts like signal handling
+ <youpi> and printf goes through the console translator
+ <braunr> also, if you don't yet have a console server available, it comes
+ in handy
+ <youpi> better direct output directly to the kernel
-IRC, freenode, #hurd, 2011-11-06
+# `stderr` buffered
+
+## IRC, freenode, #hurd, 2011-11-06
+
+[[!tag open_issue_hurd]]
<youpi> about CLI_DEBUG, you can use #define CLI_DEBUG(fmt, ...) {
fprintf(stderr, fmt, ## __VA_ARGS__); fflush(stderr); }
@@ -40,7 +84,24 @@ IRC, freenode, #hurd, 2011-11-06
<tschwinge> That sounds wrong.
-IRC, freenode, #hurd, 2011-11-23
+# Logging
+
+[[!tag open_issue_hurd]]
+
+There have been several discussions and proposals already, about adding a
+suitable logging mechanism to translators, for example.
+
+Decide / implement / fix that (all?) running (passive?) translators' output
+should show up on the (Mach / Hurd) console / syslog.
+
+[[!taglink open_issue_documentation]]: [[!message-id
+"87oepj1wql.fsf@becket.becket.net"]]
+
+[[!taglink open_issue_documentation]]: Neal once had written an email on this
+topic.
+
+
+## IRC, freenode, #hurd, 2011-11-23
<braunr> we'd need a special logging task for hurd servers
<pinotree> if syslog would work, that could be used optionally
diff --git a/open_issues/user-space_device_drivers.mdwn b/open_issues/user-space_device_drivers.mdwn
index 8cde8281..7331bb54 100644
--- a/open_issues/user-space_device_drivers.mdwn
+++ b/open_issues/user-space_device_drivers.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2009, 2011, 2012 Free Software Foundation,
+[[!meta copyright="Copyright © 2009, 2011, 2012, 2013 Free Software Foundation,
Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -154,12 +154,100 @@ A similar problem is described in
< braunr> s/disk/storage/
-### IRC, freenode, #hurd, 2012-04-25
+#### IRC, freenode, #hurd, 2012-04-25
<youpi> btw, remember the initrd thing?
<youpi> I just came across task.c in libstore/ :)
+#### IRC, freenode, #hurd, 2013-06-24
+
+ <youpi> we added a new initrd command to gnumach, to expose a new mach
+ device, which ext2fs can open and unzip
+ <youpi> we consider replacing that with simply putting the data in a dead
+ process
+ <youpi> s/process/task
+ <youpi> and let ext2fs read data from the task, and kill it when done
+ <teythoon> ok
+ <youpi> alternatively, tmps would work with an initial .tar.gz payload
+ <youpi> that would be best for memory usage
+ <youpi> tmpfs*
+ <teythoon> can't we replace the initrd concept with sub/neighbourhood?
+ <youpi> setting up tmpfs with an initial payload could be done with a
+ bootstrap subhurd
+ <teythoon> yes
+ <youpi> but it seems to me that having tmpfs being able to have an initial
+ payload is interesting
+ <teythoon> is there any advantage of the tmpfs translator prefilled with a
+ tarball over ext2fs with copy & bunzip?
+ <youpi> memory usage
+ <youpi> ext2fs with copy&bunzip takes memory for zeroes
+ <youpi> and we have to forecast how much data might be stored
+ <youpi> (if writable)
+ <teythoon> ah sure
+ <teythoon> but why would it have to be in the tmpfs translator? I why not
+ start the translator and have tar extract stuff there?
+ <teythoon> with the livecd I had trouble replacing the root translator, but
+ when using subhurds that shouldn't be a prwoblem at all
+ <youpi> I don't have a real opinion on this
+ <youpi> except that people don't usually like initrd :)
+ <braunr> 12:43 < teythoon> but why would it have to be in the tmpfs
+ translator? I why not start the translator and have tar extract stuff
+ there?
+ <braunr> that sounds an awful lot like an initramfs
+ <teythoon> yes, exactly, without actually having an initramfs of course
+ <braunr> yep
+ <braunr> i actually prefer that way too
+ <teythoon> a system on a r/o isofs cannot do much, but it can do this
+ <braunr> on the other hand, i wouldn't spend much time on a virtio disk
+ driver for now
+ <braunr> the hurd as it is can't boot on a device that isn't managed by the
+ kernel
+ <braunr> we'd need to change the boot protocol
+
+
+#### IRC, freenode, #hurd, 2013-06-28
+
+ <teythoon> I'm tempted to redo a livecd, simpler and without the initrd
+ hack that youpi used for d-i
+ <braunr> initrd hack ?
+ <braunr> you mean more a la initramfs then ?
+ <teythoon> no, I thought about using a r/o isofs translator, but instead of
+ fixing that one up with a r/w overlay and lot's of firmlinks like I used
+ to, it would just start an ext2fs translator with copy on an image stored
+ on the iso and start a subhurd
+ <braunr> why a subhurd ?
+ <teythoon> neighbourhurd even
+ <teythoon> b/c back in the days I had trouble replacing /
+ <braunr> yes, that's hard
+ <teythoon> subhurd would take of that for free
+ <braunr> are you sure ?
+ <teythoon> somewhat
+ <braunr> i'm not, but this requires thorough thinking
+ <braunr> and i'm not there yet
+ <teythoon> y would it not?
+ <teythoon> just start a subhurd and let that one take over the console and
+ let the user and d-i play nicely in that environment
+ <teythoon> no hacks involved
+ <braunr> because it would require sharing things between the two system
+ instances, and that's not easy
+ <teythoon> no but the bootstrap system does nothing after launching the
+ subhurd
+ <teythoon> I mean yes, technically true, but why would it be hard to share
+ with someone who does nothing?
+ <braunr> the context isn't well defined enough to clearly state anything
+ <braunr> if you don't use the resources of the first hurd, that's ok
+ <braunr> otherwise, it may be easy or not, i don't know yet
+ <teythoon> you think it's worth a shot and see what issues crop up?
+ <braunr> sure
+ <braunr> definitely
+ <teythoon> it doesn't sound complicated at all
+ <braunr> it's easy enough to the point we see something goes wrong or works
+ completely
+ <braunr> so worth testin
+ <teythoon> cool :)
+
+
### IRC, freenode, #hurd, 2012-07-17
<bddebian> OK, here is a stupid question I have always had. If you move
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-26 23:09:06 +0000