From 006dece71b7f87012847d12960048826a3feba03 Mon Sep 17 00:00:00 2001 From: "http://musial.pip.verisignlabs.com/" Date: Fri, 19 Apr 2013 19:51:58 +0200 Subject: --- user/musial.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/user/musial.mdwn b/user/musial.mdwn index 09992930..dd92024c 100644 --- a/user/musial.mdwn +++ b/user/musial.mdwn @@ -10,7 +10,7 @@ License|/fdl]]."]]"""]] ~musial (Robert Musial) - Cleveland, OH -http://t-n.us/.musial/ +http://nyumbu.org/.musial/ email: musial@gnu.org -- cgit v1.2.3 From 28008b559ac4bf6714417e67aadd4af5aba4d8e4 Mon Sep 17 00:00:00 2001 From: "http://musial.pip.verisignlabs.com/" Date: Fri, 19 Apr 2013 23:22:17 +0200 Subject: --- user/musial.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/user/musial.mdwn b/user/musial.mdwn index dd92024c..5a8c15ce 100644 --- a/user/musial.mdwn +++ b/user/musial.mdwn @@ -10,7 +10,7 @@ License|/fdl]]."]]"""]] ~musial (Robert Musial) - Cleveland, OH -http://nyumbu.org/.musial/ +http://tangent.cc/.musial/ email: musial@gnu.org -- cgit v1.2.3 From 390bfea46950c9685f3b14eab971d955defae8da Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sat, 20 Apr 2013 09:44:45 +0200 Subject: Fix broken links to microkernel/mach/gnumach/interface/device/time. --- open_issues/clock_gettime.mdwn | 2 +- open_issues/dde.mdwn | 2 +- open_issues/libpthread_CLOCK_MONOTONIC.mdwn | 2 +- open_issues/performance/io_system/read-ahead.mdwn | 2 +- open_issues/vdso.mdwn | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/open_issues/clock_gettime.mdwn b/open_issues/clock_gettime.mdwn index 5ba6b418..98454d45 100644 --- a/open_issues/clock_gettime.mdwn +++ b/open_issues/clock_gettime.mdwn @@ -15,7 +15,7 @@ License|/fdl]]."]]"""]] Missing `clock_gettime(CLOCK_MONOTONIC)` (e.g. for iceweasel) It could be a mere matter of extending the -[[mapped-time_interface|master/microkernel/mach/gnumach/interface/device/time]]: +[[mapped-time_interface|microkernel/mach/gnumach/interface/device/time]]: add it to `mapped_time_value_t` in gnumach, handle it in `gnumach/kern/mach_clock.c`, and make `clock_gettime` use it. diff --git a/open_issues/dde.mdwn b/open_issues/dde.mdwn index f0f7cae0..65d84886 100644 --- a/open_issues/dde.mdwn +++ b/open_issues/dde.mdwn @@ -394,7 +394,7 @@ After the microkernel devroom at [[community/meetings/FOSDEM_2013]]. so ZhengDa preferred to make jiffies a macro which calls a function which reads the mapped time -[[Mapped-time_interface|master/microkernel/mach/gnumach/interface/device/time]]. +[[Mapped-time_interface|microkernel/mach/gnumach/interface/device/time]]. however, that break any use of the work "jiffies", e.g. structure members & such diff --git a/open_issues/libpthread_CLOCK_MONOTONIC.mdwn b/open_issues/libpthread_CLOCK_MONOTONIC.mdwn index 37ee548b..9f732fbe 100644 --- a/open_issues/libpthread_CLOCK_MONOTONIC.mdwn +++ b/open_issues/libpthread_CLOCK_MONOTONIC.mdwn @@ -26,7 +26,7 @@ License|/fdl]]."]]"""]] this way we could add inside hurdtime.c the mapped time stuff too -[[Mapped-time_interface|master/microkernel/mach/gnumach/interface/device/time]]. +[[Mapped-time_interface|microkernel/mach/gnumach/interface/device/time]]. most probably a noobish question, but why does rt link to pthread? diff --git a/open_issues/performance/io_system/read-ahead.mdwn b/open_issues/performance/io_system/read-ahead.mdwn index 768dca93..cd39328f 100644 --- a/open_issues/performance/io_system/read-ahead.mdwn +++ b/open_issues/performance/io_system/read-ahead.mdwn @@ -1324,7 +1324,7 @@ License|/fdl]]."]]"""]] device_map() -- but IIRC the only one that does (besides mem of course) is maptime -- which is not a real driver either... -[[Mapped-time_interface|master/microkernel/mach/gnumach/interface/device/time]]. +[[Mapped-time_interface|microkernel/mach/gnumach/interface/device/time]]. oh btw, i didn't know you had a blog :) well, it would be possible to replace the device interface by diff --git a/open_issues/vdso.mdwn b/open_issues/vdso.mdwn index 2b2d2805..76c43aa8 100644 --- a/open_issues/vdso.mdwn +++ b/open_issues/vdso.mdwn @@ -35,7 +35,7 @@ Having vDSO code might be useful for: * `mach_*_self`: `mach_host_self`, `mach_task_self`, `mach_thread_self`? - * [[mapped-time_interface|master/microkernel/mach/gnumach/interface/device/time]] + * [[mapped-time_interface|microkernel/mach/gnumach/interface/device/time]] Every application can then use that via the regular `gettimeofday`/`clock_gettime` and similar calls instead of using the -- cgit v1.2.3 From 6b6842e344cba20f953c10f00c0e67b25599c998 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sat, 20 Apr 2013 09:50:11 +0200 Subject: Add some links. --- hurd/translator/pfinet/implementation.mdwn | 2 ++ open_issues/address_space_memory_mapping_entries.mdwn | 3 ++- open_issues/glibc/0.4.mdwn | 4 +++- open_issues/gnumach_memory_management.mdwn | 2 ++ 4 files changed, 9 insertions(+), 2 deletions(-) diff --git a/hurd/translator/pfinet/implementation.mdwn b/hurd/translator/pfinet/implementation.mdwn index 3232e0cc..9bcf62ef 100644 --- a/hurd/translator/pfinet/implementation.mdwn +++ b/hurd/translator/pfinet/implementation.mdwn @@ -30,6 +30,8 @@ implementation. # Reimplementation, [[!GNU_Savannah_task 5469]] +## [[community/gsoc/project_ideas/tcp_ip_stack]] + ## IRC, freenode, #hurd, 2013-04-03 [[!tag open_issue_hurd]] diff --git a/open_issues/address_space_memory_mapping_entries.mdwn b/open_issues/address_space_memory_mapping_entries.mdwn index 8ed69345..f1811b27 100644 --- a/open_issues/address_space_memory_mapping_entries.mdwn +++ b/open_issues/address_space_memory_mapping_entries.mdwn @@ -18,4 +18,5 @@ IRC, freenode, #hurd, 2011-05-07 a bare linked list which makes faults and page cache lookups even slower -A red-black tree was added to VM maps to speed up lookups. +A [[red-black tree|gnumach_vm_map_red-black_trees]] was added to VM maps to +speed up lookups. diff --git a/open_issues/glibc/0.4.mdwn b/open_issues/glibc/0.4.mdwn index a8892876..ceb5ea21 100644 --- a/open_issues/glibc/0.4.mdwn +++ b/open_issues/glibc/0.4.mdwn @@ -25,4 +25,6 @@ In context of [[packaging_libpthread]]/[[libpthread]]. the exec server IIRC... pochu: Oh, I have to re-read that discussion, but thanks for reminding! - pochu: Won't happen today or tomorrow, but "sometime". + +[[!GNU_Savannah_bug 28934]], [[user/pochu]], [[!message-id +"4BFA500A.7030502@gmail.com"]]. diff --git a/open_issues/gnumach_memory_management.mdwn b/open_issues/gnumach_memory_management.mdwn index 46454207..511d3f2b 100644 --- a/open_issues/gnumach_memory_management.mdwn +++ b/open_issues/gnumach_memory_management.mdwn @@ -832,6 +832,8 @@ There is a [[!FF_project 266]][[!tag bounty]] on this task. it could also be used to drop the overloaded (and probably over imbalanced) page cache hash table +[[gnumach_vm_map_red-black_trees]]. + # IRC, freenode, #hurd, 2011-05-03 -- cgit v1.2.3 From 6f9a01aecd44b44d99921679ae40cac069c9a610 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawlyLVajq_XluZ1wvTunv9vbM_kx1H0nd6Q" Date: Sun, 21 Apr 2013 14:15:11 +0200 Subject: Shell accounts aren't provided freely any more, recommend a virtual machine instead --- public_hurd_boxen.mdwn | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/public_hurd_boxen.mdwn b/public_hurd_boxen.mdwn index 268f177b..36e04ab1 100644 --- a/public_hurd_boxen.mdwn +++ b/public_hurd_boxen.mdwn @@ -12,8 +12,9 @@ License|/fdl]]."]]"""]] [[!tag stable_URL]] There are GNU/Hurd boxes that we're offering shell accounts on. These are -generally available for everyone interested in [[contributing]], or just having -a look at a GNU/Hurd system. +generally available for people interested in [[contributing]], and who have +already shown some level of involvement in the project. If you simply want to +try the Hurd, the easiest way is running it in a virtual machine. An alternative to online shell access may be using a [[QEMU image|hurd/running/qemu]]. -- cgit v1.2.3 From 083c79ac20394f47808c6007953646420bf59425 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Tue, 23 Apr 2013 11:57:58 +0200 Subject: community/gsoc/2012. --- community/gsoc.mdwn | 28 ++++------------------------ community/gsoc/2012.mdwn | 32 ++++++++++++++++++++++++++++++++ 2 files changed, 36 insertions(+), 24 deletions(-) create mode 100644 community/gsoc/2012.mdwn diff --git a/community/gsoc.mdwn b/community/gsoc.mdwn index efd29841..e3d52937 100644 --- a/community/gsoc.mdwn +++ b/community/gsoc.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2008, 2009, 2010, 2011, 2012 Free Software +[[!meta copyright="Copyright © 2008, 2009, 2010, 2011, 2012, 2013 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -57,26 +57,6 @@ subprojects. --> -Applications for 2012 are closed. - -# Accepted projects - -## Disk I/O Performance Tuning - -by Maksym Planeta - -See the project's -[public page](http://www.google-melange.com/gsoc/project/google/gsoc2012/mcsim/46002). - -## Virtualization Using Hurd Mechanisms - -by Pierre Thierry - -See the project's -[public page](http://www.google-melange.com/gsoc/project/google/gsoc2012/nowhereman/36001) -and [[complete proposal|gsoc/2012/virt/proposal]]. - - # Possible projects We have a list of [[project_ideas]], and students are likewise encouraged to @@ -105,6 +85,6 @@ if you aren't a student anyway. In 2006 and [[2007]], we participated in GSoC under the umbrella of the GNU project, getting one slot each year. In the following year, we successfully participated on our own, instead of as a suborganization of the GNU project. -Read about our five students' success on the [[2008]] page. The next two year, -we participated under the GNU umbrella with one slot in [[2009]], three in -[[2010]], and one again in [[2011]]. +Read about our five students' success on the [[2008]] page. In the next years, +we again participated under the GNU umbrella with one slot in [[2009]], three +in [[2010]], one in [[2011]], and two in [[2012]]. diff --git a/community/gsoc/2012.mdwn b/community/gsoc/2012.mdwn new file mode 100644 index 00000000..3bb6dd7e --- /dev/null +++ b/community/gsoc/2012.mdwn @@ -0,0 +1,32 @@ +[[!meta copyright="Copyright © 2008, 2009, 2010, 2011, 2012, 2013 Free Software +Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +The GNU Hurd project has again been participating in the [Google Summer of +Code](http://www.google-melange.com/) under the [GNU +umbrella](http://www.gnu.org/software/soc-projects/). + + +# Accepted projects + +## Disk I/O Performance Tuning + +by Maksym Planeta + +See the project's +[public page](http://www.google-melange.com/gsoc/project/google/gsoc2012/mcsim/46002). + +## Virtualization Using Hurd Mechanisms + +by Pierre Thierry + +See the project's +[public page](http://www.google-melange.com/gsoc/project/google/gsoc2012/nowhereman/36001) +and [[complete proposal|virt/proposal]]. -- cgit v1.2.3 From a2cd1c245297f5f4f64dd77b5bbaee4f22353ee7 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Tue, 23 Apr 2013 12:14:22 +0200 Subject: GSoC 2013. --- community/gsoc.mdwn | 14 +++++++++++++- news/2013-04-23.mdwn | 15 +++++++++++++++ sidebar.mdwn | 8 ++++++++ 3 files changed, 36 insertions(+), 1 deletion(-) create mode 100644 news/2013-04-23.mdwn diff --git a/community/gsoc.mdwn b/community/gsoc.mdwn index e3d52937..81a0740b 100644 --- a/community/gsoc.mdwn +++ b/community/gsoc.mdwn @@ -15,6 +15,12 @@ We're in! The GNU Hurd project is again participating in the [Google Summer of Code](http://www.google-melange.com/) under the [GNU umbrella](http://www.gnu.org/software/soc-projects/). +As of Monday, 2013-04-22 it's the *student application period*. This will last +until [Friday, +2013-05-03](http://www.google-melange.com/gsoc/events/google/gsoc2013), which +is plenty of time for preparing and discussing your applications -- but please +don't wait to the last minute! + + As we only have finite resources (meaning that we won't be able to accept all GNU Hurd applications even if we wanted to), we will eventually need to make a choice about whom to select. For this, it is a very good idea to be in contact @@ -48,7 +56,11 @@ how to do `X`, can someone please help me?* And, as we're not working next to each other in a conventional office or university setup, we'll need to establish and get used to different communication channels. -[Timeline](http://www.google-melange.com/gsoc/events/google/gsoc2011). As +[Timeline](http://www.google-melange.com/gsoc/events/google/gsoc2013). + + -- cgit v1.2.3 From f7ba080aaf91e641fd4f1687941369b0c1a09536 Mon Sep 17 00:00:00 2001 From: "http://musial.pip.verisignlabs.com/" Date: Tue, 23 Apr 2013 18:58:30 +0200 Subject: --- user/musial.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/user/musial.mdwn b/user/musial.mdwn index 5a8c15ce..a258448b 100644 --- a/user/musial.mdwn +++ b/user/musial.mdwn @@ -10,7 +10,7 @@ License|/fdl]]."]]"""]] ~musial (Robert Musial) - Cleveland, OH -http://tangent.cc/.musial/ +http://un9.org/.musial/ email: musial@gnu.org -- cgit v1.2.3 From 593f5417e7f695a1a9eabd0a10b0299078e0534b Mon Sep 17 00:00:00 2001 From: "http://musial.pip.verisignlabs.com/" Date: Wed, 24 Apr 2013 00:18:29 +0200 Subject: --- user/musial.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/user/musial.mdwn b/user/musial.mdwn index a258448b..fad6d8d7 100644 --- a/user/musial.mdwn +++ b/user/musial.mdwn @@ -10,7 +10,7 @@ License|/fdl]]."]]"""]] ~musial (Robert Musial) - Cleveland, OH -http://un9.org/.musial/ +http://affusion.org/.musial/ email: musial@gnu.org -- cgit v1.2.3 From 5b7216fd94b547675077065082b4656ea5d3ddc9 Mon Sep 17 00:00:00 2001 From: "http://musial.pip.verisignlabs.com/" Date: Wed, 24 Apr 2013 01:52:17 +0200 Subject: --- user/musial.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/user/musial.mdwn b/user/musial.mdwn index fad6d8d7..5a8c15ce 100644 --- a/user/musial.mdwn +++ b/user/musial.mdwn @@ -10,7 +10,7 @@ License|/fdl]]."]]"""]] ~musial (Robert Musial) - Cleveland, OH -http://affusion.org/.musial/ +http://tangent.cc/.musial/ email: musial@gnu.org -- cgit v1.2.3 From 6b366a25f9fd496777ff42932685924eb83696fc Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 24 Apr 2013 11:46:58 +0200 Subject: IRC. --- community/gsoc/project_ideas/mtab.mdwn | 93 +++++++++++++++++++- hurd/translator/ext2fs.mdwn | 7 ++ microkernel/mach/rpc/discussion.mdwn | 37 +++++++- open_issues/gdb_attach.mdwn | 29 ++++++- open_issues/gnumach_memory_management.mdwn | 34 ++++++++ open_issues/libpthread_assertion_thread_prevp.mdwn | 45 +++++++++- open_issues/libpthread_cancellation_points.mdwn | 98 ++++++++++++++++++++++ 7 files changed, 333 insertions(+), 10 deletions(-) diff --git a/community/gsoc/project_ideas/mtab.mdwn b/community/gsoc/project_ideas/mtab.mdwn index a60a8038..694effca 100644 --- a/community/gsoc/project_ideas/mtab.mdwn +++ b/community/gsoc/project_ideas/mtab.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 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 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]]."]]"""]] [[!meta title="mtab"]] @@ -72,3 +73,89 @@ Possible mentors: Olaf Buddenhagen (antrik), Carl Fredrik Hammar (cfhammar) Exercise: Make some improvement to any of the existing Hurd translators. Especially those in [hurdextras](http://www.nongnu.org/hurdextras/) are often quite rudimentary, and it shouldn't be hard to find something to improve. + + +# Related Discussion + +## IRC, freenode, #hurd, 2013-04-17 + + thinking how to get the listing. traversing would be + ineffecient, trying to come up with something better + what listing ? + and traversing what ? + mtab + well i assumed so + be more precise please + when the translator is done initalized are written to /etc/mtab will be provided + by the translator, and when some one want to read the info just read it + this way if their is some credentials like ftp sites pass username can be + masked by the translator + if some trans dont want to list them, no need to write to + file | while unmounting (sorry i couldnt find the right word) , it + will pass the mount node address | will have special + structure to remove/add mounts example "a /mount-to /mount-from" = add + , "r /mount-to" = remove here "/mount-to" will be unique for every + mount + this have a draw back , we would have to trust trans for the + listed data | also "/mount-to" + "/mount-from" could be used a + combination for making sure that other trans unable remove others trans + mount data + sorry but "also "/mount-to" + "/mount-from" could be used a + combination for making sure that other trans unable remove others trans + mount data" this is a bad idea if we had to print the whole thing + braunr, whats ur opinion? + you don't need a mtab to "unmount" things on hurd + kuldeepdhaka: hum, have you read the project idea ? + + http://darnassus.sceen.net/~hurd-web/community/gsoc/project_ideas/mtab/ + A more promising approach is to have mtab exported by a special + translator, which gathers the necessary information on demand. This could + work by traversing the tree of translators, asking each one for mount + points attached to it. + pinotree, not to unmount, i mean is to remove the + + for a first implementation, i'd suggest a recursive traversal of + root-owned translators + braunr, hum, but it did stated it as inefficient + where ? + para 5 , line 3 + and line 6 + no + traversing "all" nodes would be inefficient + translators which host the nodes of other translators could + maintain a simple list of active translators + ext2fs, e.g. (if that's not already the case) could keep the list + of the translators it started + we can already see that list with pstree for example + but this new list would only retain those relevant for mtab + i.e. root-owned ones + i would not limit to those though + and then filter on their type (e.g. file system ones) + pinotree: why ? + this way you could have proper per-user /proc/$pid/mounts info + we could also very easily have a denial of service + but how will the mount point and source point will be + listed? + they're returned by the translator + k + you ask /, it returns its store and its options, and asks its + children recursively + a /home translator would return its store and its options + etc.. + each translator would build the complete path before returning it + sort of, it's very basic + but that would be a very hurdish way to do it + shall /etc/mtab should be made seek-able and what should be + the filesize? content are generated on demand so, it could arise problem + (fsize:0 , seek-able:no), ur opinions? + kuldeepdhaka: it should have all the properties of a regular file + the filesize would be determined after it's generated + being empty doesn't imply it's not seekable + content is generated on demand so, could cause problem while + seeking and filesize, shall i still program as regular file? + in two different read, it could generate different content, + though same seek pos is used... + what ? + the content is generated on open + ooh, ok diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn index a89b40b1..20faed5e 100644 --- a/hurd/translator/ext2fs.mdwn +++ b/hurd/translator/ext2fs.mdwn @@ -137,6 +137,13 @@ small backend stores, like floppy devices. ah, there is the same parameter on diskfs_start_disk_pager +##### IRC, freenode, #hurd, 2013-04-23 + + and i'm working again on the ext2fs large store patch + i finished separating the libpager interface change from the rest, + as Thomas suggested, so a new version should be ready soon + + #### `EXT2FS_DEBUG` ##### IRC, freenode, #hurd, 2013-03-04 diff --git a/microkernel/mach/rpc/discussion.mdwn b/microkernel/mach/rpc/discussion.mdwn index 00e4a012..ee9f059a 100644 --- a/microkernel/mach/rpc/discussion.mdwn +++ b/microkernel/mach/rpc/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,8 +10,12 @@ License|/fdl]]."]]"""]] [[!tag open_issue_documentation]] +[[!toc]] -# IRC, freenode, #hurd, 2011-06-11 + +# Mach initiating RPCs to userspace tasks + +## IRC, freenode, #hurd, 2011-06-11 I don't think we have a precendence case of Mach initiating RPCs to userspace tasks @@ -115,3 +119,32 @@ License|/fdl]]."]]"""]] right, i really need to read about mig again it's pretty normal for a translator to both implement and use an interface + + +# `MACH_SEND_INTERRUPT`/`MACH_RCV_INTERRUPT` + +[[!tag open_issue_glibc open_issue_gnumach]] + + +## IRC, freenode, #hurd, 2013-03-22 + + i'm also testing glibc packages on darnassus with a patch that + removes the MACH_{SEND,RCV}_INTERRUPT options from mach_msg calls to + avoid taking the slow path because of them + if i got it right, almost every mach_msg call doesn't use any of + these options, except for select + it could slightly improve that, i'm not sure + but don't we need that to get EINTR ? + the options are purely userspace + i'll upload the patch + + http://www.sceen.net/~rbraun/0001-Mask-options-implemented-by-the-userspace-side-of-ma.patch + ah, ok, you mean userspace already implements what we need + + +## IRC, freenode, #hurd, 2013-04-23 + + i couldn't measure any difference with the glibc patch that + removes the mach_msg interrupt related flags + which isn't very surprising as it only concerns select as far as i + can tell diff --git a/open_issues/gdb_attach.mdwn b/open_issues/gdb_attach.mdwn index 8f1b7b48..b9114b69 100644 --- a/open_issues/gdb_attach.mdwn +++ b/open_issues/gdb_attach.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 @@ -54,3 +54,30 @@ License|/fdl]]."]]"""]] process That is supposed to work. If the permission match. + + +# `gdb --pid [PID]` + +That is, not explicitly specifying an `executable-file`. + + +## IRC, OFTC, debian-hurd, 2013-04-15 + + I don't seem to be able to run gdb + that happened on the buildd and happens on exodar too + #0 0x010c07cc in ?? () + #1 0x010c1078 in ?? () + #2 0x0109eabf in ?? () + [...] + Backtrace stopped: previous frame inner to this frame (corrupt + stack?) + that's pid 24235 on exodar + I did gdb -p 24235 and then bt + just the output above + I don't know about gdb -p + I usually run gdb + /home/paravoid/gdnsd-1.8.1/plugins/meta/libgdmaps/t/.libs/lt-t17_extn_empty.bin + 24235 + okay, that indeed works + I guess the support for finding out the binary automatically wasn't + done yet on hurd diff --git a/open_issues/gnumach_memory_management.mdwn b/open_issues/gnumach_memory_management.mdwn index 46454207..509a06d1 100644 --- a/open_issues/gnumach_memory_management.mdwn +++ b/open_issues/gnumach_memory_management.mdwn @@ -2227,3 +2227,37 @@ There is a [[!FF_project 266]][[!tag bounty]] on this task. (i mean, when i made my tests, it looked like there were few kernel map entries, but i may have missed corner cases that could cause more of them to be needed) + + +# IRC, freenode, #hurd, 2013-04-18 + + oh nice, i've found a big scalability issue with my slab allocator + it shouldn't affect gnumach much though + + +## IRC, freenode, #hurd, 2013-04-19 + + braunr: is it fixable? + yes + well, i'll do it in x15 for a start + again, i don't think gnumach is much affected + it's a scalability issue + when millions of objects are in use + gnumach rarely has more than a few hundred thousands + it's also related to heavy multithreading/smp + and by multithreading, i also mean preemption + gnumach isn't preemptible and uniprocessor + if the resulting diff is clean enough, i'll push it to gnumach + though :) + + +### IRC, freenode, #hurd, 2013-04-21 + + ArneBab_: i fixed the scalability problems btw + + +## IRC, freenode, #hurd, 2013-04-20 + + well, there is also a locking error in the slab allocator, + although not a problem for a non preemptible kernel like gnumach + non preemptible / uniprocessor diff --git a/open_issues/libpthread_assertion_thread_prevp.mdwn b/open_issues/libpthread_assertion_thread_prevp.mdwn index 1418bea1..e8160528 100644 --- a/open_issues/libpthread_assertion_thread_prevp.mdwn +++ b/open_issues/libpthread_assertion_thread_prevp.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 @@ -13,7 +13,8 @@ failed"]] [[!tag open_issue_libpthread]] -IRC, OFTC, #debian-hurd, 2011-10-21: + +# IRC, OFTC, #debian-hurd, 2011-10-21 [Python testsuite] [169/340/1] test_logging @@ -22,7 +23,8 @@ IRC, OFTC, #debian-hurd, 2011-10-21: __pthread_enqueue: Assertion `thread->prevp == 0' failed. sigh -IRC, freenode, #hurd, 2011-10-21: + +## IRC, freenode, #hurd, 2011-10-21 am i missing anything, or in libpthread the __pthread_threads list does not ever has elements removed from it? @@ -33,7 +35,8 @@ IRC, freenode, #hurd, 2011-10-21: maybe reusing the same next+prevp pointers in the __pthread struct for more than one list at the same time isn't a good idea... -2011-10-23: + +## IRC, freenode, #hurd, 2011-10-23 pinotree: I don't understand the relation between thread->prevp != 0 and the __pthread_threads list @@ -50,3 +53,37 @@ IRC, freenode, #hurd, 2011-10-21: yeah apparently prevp/next are used for lists of held waitcond/mutex/rwlock and free threads + + +# IRC, freenode, #hurd, 2013-03-20 + + aw + i hit the ext2fs.static: ./pthread/pt-internal.h:122: + __pthread_enqueue: Assertion `thread->prevp == 0' failed. + assertion + looks like there is a deadlock on assert + which might explain why i never saw progress when i tested that in + the past + + +## IRC, freenode, #hurd, 2013-04-21 + + damn, there still bugs in libpthread + (about prevp not being null when it should i mean) + braunr: found another trigger for that? + no + it's so random i wonder if it's not a completely unrelated + corruption + pinotree: also, i'm having more of these issues with my custom + hurd packages that let threads exit after some time from managing ports + (i removed the libports_stability patch) + i once had this : http://www.sceen.net/~rbraun/darnassus_crash.png + +[The assertion failure.] + + +## IRC, freenode, #hurd, 2013-04-23 + + 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) diff --git a/open_issues/libpthread_cancellation_points.mdwn b/open_issues/libpthread_cancellation_points.mdwn index af0efa9d..48f1acf5 100644 --- a/open_issues/libpthread_cancellation_points.mdwn +++ b/open_issues/libpthread_cancellation_points.mdwn @@ -39,3 +39,101 @@ type to asynchronous permits this testcase to terminate. We do have the pthread_setcanceltype glibc/libpthread hook in the forward structure, but we are not using it: the LIBC_CANCEL_ASYNC macros are void, and we're not using them in the mig msg call either. + + +# Provenance + +## IRC, OFTC, #debian-hurd, 2013-04-15 + + so, let me say a few things about the bug in the first place + the package builds and runs a test suite + the second test in the test suite blocks forever + a blocked pthread_join is what I see + I'm unsure why + have you seen anything like it before? + whenever the thread doesn't actually terminate, sure + what is the thread usually blocked on when you cancel it? + this is a hurd-specific issue + works on all other arches + could be just that all other archs have more relaxed behavior + thus the question of what exactly is supposed to be happening + apparently it is inside a select? + it seems select is not cancellable here + wasn't the patch you sent? + no, my patch was about signals + not cancellation + k + (even if that could be related, of course) + how did you see that? + what's the equivalent of strace? + thread 3 is inside _hurd_select + thread 1 is blocked on join + but the code is + if(gdmaps->reload_thread_spawned) { + pthread_cancel(gdmaps->reload_tid); + pthread_join(gdmaps->reload_tid, NULL); + } + so cancel should have killed the thread + cancelling a thread is a complex matter + there are cancellation points + e.g. a thread performing while(1); can't be cancelled + thread 3 is just a libev event loop + yes, "just" calling poll, the most complex system call of unix :) + paravoid: anyway, don't look for a bug in your program, it's most + likely a bug in glibc, thanks for the report + I think it all boils down to a problem cancelling a thread in + poll() + yes + paravoid: ok, actually with the latest libc it does work + oh? + where latest = not uploaded yet :/ + did you test this on exodar? + pinotree: that's the libpthread_cancellation.diff I guess + because I commented out the join :) + paravoid: in the root, yes + well, I tried my own program + oh, okay + which is indeed hanging inside select (or just read) in the chroot + but not in the root + ah, richard's patch + url? + I've installed the build-dep in the root, if you want to try + strange that root is newer than the chroot :) + paravoid: it's the usual eglibc debian source + tried in root, still fails + could you keep the process running? + done + Mmm, but the thread running gdmaps_reload_thread never set the + cancel type to async? + that said I guess read and select are supposed to be cancellation + points + thus cancel_deferred should be working, but they are not + it seems it's cancellation points which have just not been + implemented + (they happen to be one of the most obscure things in posix) + + +## IRC, freenode, #hurd, 2013-04-15 + + but yes, there is still an issue, with PTHREAD_CANCEL_DEFERRED + how calls like read() or select() are supposed to test + cancellation? + iirc there are the LIBC_CANCEL_* macros in glibc + eg sysdeps/unix/sysv/linux/pread.c + yes + but in our libpthredaD? + could it be we lack the libpthread → glibc bridge of + cancellation stuff? + we do have pthread_setcancelstate/type forwards + but it seems the default LIBC_CANCEL_ASYNC is void + i mean, so when you cancel a thread, you can get that cancel + status in libc proper, just like it seems done with LIBC_CANCEL_* macros + and nptl + as I said, the bridge is there + we're just not using it in glibc + I'm writing an open_issues page + + +### IRC, freenode, #hurd, 2013-04-16 + + youpi: yes, we said some time ago that it was lacking -- cgit v1.2.3 From c0b326c9ae836a8b798c9162f807b8c50407a33d Mon Sep 17 00:00:00 2001 From: "http://musial.pip.verisignlabs.com/" Date: Fri, 26 Apr 2013 18:05:03 +0200 Subject: --- user/musial.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/user/musial.mdwn b/user/musial.mdwn index 5a8c15ce..7ea58564 100644 --- a/user/musial.mdwn +++ b/user/musial.mdwn @@ -10,7 +10,7 @@ License|/fdl]]."]]"""]] ~musial (Robert Musial) - Cleveland, OH -http://tangent.cc/.musial/ +http://musial.in/.musial/ email: musial@gnu.org -- cgit v1.2.3 From ec26bf887b3cab54c04becfb7b1525b2c24063d5 Mon Sep 17 00:00:00 2001 From: "http://musial.pip.verisignlabs.com/" Date: Sun, 28 Apr 2013 07:15:10 +0200 Subject: --- user/musial.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/user/musial.mdwn b/user/musial.mdwn index 7ea58564..09992930 100644 --- a/user/musial.mdwn +++ b/user/musial.mdwn @@ -10,7 +10,7 @@ License|/fdl]]."]]"""]] ~musial (Robert Musial) - Cleveland, OH -http://musial.in/.musial/ +http://t-n.us/.musial/ email: musial@gnu.org -- cgit v1.2.3 From c5dc9558f8588d080b643399a780cfef3b8a03b9 Mon Sep 17 00:00:00 2001 From: "http://musial.pip.verisignlabs.com/" Date: Sun, 28 Apr 2013 09:30:00 +0200 Subject: --- user/musial.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/user/musial.mdwn b/user/musial.mdwn index 09992930..5a8c15ce 100644 --- a/user/musial.mdwn +++ b/user/musial.mdwn @@ -10,7 +10,7 @@ License|/fdl]]."]]"""]] ~musial (Robert Musial) - Cleveland, OH -http://t-n.us/.musial/ +http://tangent.cc/.musial/ email: musial@gnu.org -- cgit v1.2.3 From d739d4eef5ae267efbd246eb76b98d5c95458f3b Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 28 Apr 2013 15:50:12 +0200 Subject: open_issues/gdb: 6330ab576e18fb97912839fc116c7babb5fd8c70 (2013-04-28) --- open_issues/gdb.mdwn | 27 ++++++++++++++++++++++----- toolchain/logs | 2 +- 2 files changed, 23 insertions(+), 6 deletions(-) diff --git a/open_issues/gdb.mdwn b/open_issues/gdb.mdwn index 6b9cd135..eddc2fdc 100644 --- a/open_issues/gdb.mdwn +++ b/open_issues/gdb.mdwn @@ -27,14 +27,14 @@ Here's what's to be done for maintaining GNU GDB. -Last reviewed up to the [[Git mirror's 6b25dae901ddedb3f330803542d3eac73cdcae4b -(2013-03-13) sources|source_repositories/gdb]]. +Last reviewed up to the [[Git mirror's 6330ab576e18fb97912839fc116c7babb5fd8c70 +(2013-04-28) sources|source_repositories/gdb]]. * Globally @@ -71,7 +71,7 @@ Last reviewed up to the [[Git mirror's 6b25dae901ddedb3f330803542d3eac73cdcae4b Here's a log of a GDB build run; this is from our [[Git repository|source_repositories/gdb]]'s `tschwinge/Ferry_Tagscherer` branch, -commit 6b25dae901ddedb3f330803542d3eac73cdcae4b (2013-03-13), run on +commit 6330ab576e18fb97912839fc116c7babb5fd8c70 (2013-04-28), run on kepler.SCHWINGE and coulomb.SCHWINGE. $ export LC_ALL=C @@ -194,6 +194,12 @@ formats and more emulation vectors. + from ../../Ferry_Tagscherer/gdb/gnu-nat.c:56: +../../Ferry_Tagscherer/gdb/value.h:729:22: note: expected 'const char **' but argument is of type 'char **' + * 6b25dae901ddedb3f330803542d3eac73cdcae4b..6330ab576e18fb97912839fc116c7babb5fd8c70: + + gcc-4.7 -c -DHAVE_CONFIG_H -g -O2 -I. -I../../Ferry_Tagscherer/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic ../../Ferry_Tagscherer/libiberty/hashtab.c -o hashtab.o + +../../Ferry_Tagscherer/libiberty/hashtab.c: In function 'hash_pointer': + +../../Ferry_Tagscherer/libiberty/hashtab.c:1001:7: warning: right shift count >= width of type [enabled by default] + # Install @@ -363,4 +369,15 @@ GNU/Hurd, these generally are `gdb.multi/watchpoint-multi`, and an unknown *stopped,reason="signal-received",signal-name="SIGSEGV",signal-meaning="Segmentation fault",frame={addr="0x00014add",func="??",args=[],from="/lib/ld.so"},thread-id="4",stopped-threads="all" + * `gdb.arch/i386-float.exp: info float` + + Running ../../../Ferry_Tagscherer/gdb/testsuite/gdb.arch/i386-float.exp ... + PASS: gdb.arch/i386-float.exp: first stepi + FAIL: gdb.arch/i386-float.exp: info float + PASS: gdb.arch/i386-float.exp: second stepi + PASS: gdb.arch/i386-float.exp: info float + + Only fails for GNU/Hurd: the floating point stack initially is not + all-zeroes, which is expected, and which it is on GNU/Linux. + TODO. diff --git a/toolchain/logs b/toolchain/logs index 17ecfe30..caec9b02 160000 --- a/toolchain/logs +++ b/toolchain/logs @@ -1 +1 @@ -Subproject commit 17ecfe30c4c1cb2c5833bc58f0ec355ec38b107c +Subproject commit caec9b02d415769b560af271fb604fd2a9a06eda -- cgit v1.2.3 From 82494c860f5a37093f979c7dda54e142bbbf5fb3 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 28 Apr 2013 15:56:23 +0200 Subject: open_issues/binutils: Last run was still with GCC 4.6. --- open_issues/binutils.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/open_issues/binutils.mdwn b/open_issues/binutils.mdwn index 757ebbe9..1b916f6b 100644 --- a/open_issues/binutils.mdwn +++ b/open_issues/binutils.mdwn @@ -130,7 +130,7 @@ commit 944a6010b676b9f80f0a16c65183102b187822c5 (2013-02-08), run on kepler.SCHWINGE and coulomb.SCHWINGE. $ export LC_ALL=C - $ ../Paul_Desmond/configure --prefix="$PWD".install --enable-gold --with-sysroot=/ SHELL=/bin/dash CC=gcc-4.7 CXX=g++-4.7 2>&1 | tee log_build + $ ../Paul_Desmond/configure --prefix="$PWD".install --enable-gold --with-sysroot=/ SHELL=/bin/dash CC=gcc-4.6 CXX=g++-4.6 2>&1 | tee log_build [...] $ make 2>&1 | tee log_build_ [...] -- cgit v1.2.3 From 7faf82f8afa0302eb04907e54f251253f64c133f Mon Sep 17 00:00:00 2001 From: "http://musial.pip.verisignlabs.com/" Date: Sun, 28 Apr 2013 18:11:36 +0200 Subject: Received email from tschwinge re: homepage URL changing, and asking that it stop unless there was a valid reason. I was testing a federated social network program with a URL scraper and seeing how often it would detect changes. I didn't realize this was being monitored by anyone or causing problems. Resetting the URL to my default personal URL, and leaving it as such. Sorry for any issue this has caused. -musial. --- user/musial.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/user/musial.mdwn b/user/musial.mdwn index 5a8c15ce..dd92024c 100644 --- a/user/musial.mdwn +++ b/user/musial.mdwn @@ -10,7 +10,7 @@ License|/fdl]]."]]"""]] ~musial (Robert Musial) - Cleveland, OH -http://tangent.cc/.musial/ +http://nyumbu.org/.musial/ email: musial@gnu.org -- cgit v1.2.3 From 08c87e1fd38a290a3d9441868e51e829e20a3106 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Mon, 29 Apr 2013 11:00:16 +0200 Subject: open_issues/binutils: 5c3ec1ded654250e0ac27df79998b32b2403e81f (2013-04-29) --- open_issues/binutils.mdwn | 18 ++++++++++++------ toolchain/logs | 2 +- 2 files changed, 13 insertions(+), 7 deletions(-) diff --git a/open_issues/binutils.mdwn b/open_issues/binutils.mdwn index 1b916f6b..00941cac 100644 --- a/open_issues/binutils.mdwn +++ b/open_issues/binutils.mdwn @@ -33,14 +33,14 @@ though, as explained below. -Last reviewed up to the [[Git mirror's 944a6010b676b9f80f0a16c65183102b187822c5 -(2013-02-08) sources|source_repositories/binutils]]. +Last reviewed up to the [[Git mirror's 5c3ec1ded654250e0ac27df79998b32b2403e81f +(2013-04-29) sources|source_repositories/binutils]]. * Globally @@ -126,7 +126,7 @@ Last reviewed up to the [[Git mirror's 944a6010b676b9f80f0a16c65183102b187822c5 Here's a log of a binutils build run; this is from our [[Git repository|source_repositories/binutils]]'s `tschwinge/Paul_Desmond` branch, -commit 944a6010b676b9f80f0a16c65183102b187822c5 (2013-02-08), run on +commit 5c3ec1ded654250e0ac27df79998b32b2403e81f (2013-04-29), run on kepler.SCHWINGE and coulomb.SCHWINGE. $ export LC_ALL=C @@ -140,7 +140,7 @@ harmonized. Debian GCC (which is used in binutils' testsuite) likes to pass `--sysroot=/` to `ld`, so we need to configure binutils with support for sysroots. -This takes up around 900 MiB, and needs roughly 11 min on kepler.SCHWINGE and +This takes up around 950 MiB, and needs roughly 11 min on kepler.SCHWINGE and 42 min on coulomb.SCHWINGE.