From 70ede59e5cda31278f7f8c7ba121a4d9b14ebc17 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 10 May 2012 10:43:01 +0800 Subject: open_issues/fork_deadlock: New. --- open_issues/fork_deadlock.mdwn | 65 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 65 insertions(+) create mode 100644 open_issues/fork_deadlock.mdwn (limited to 'open_issues') diff --git a/open_issues/fork_deadlock.mdwn b/open_issues/fork_deadlock.mdwn new file mode 100644 index 00000000..cfb6b743 --- /dev/null +++ b/open_issues/fork_deadlock.mdwn @@ -0,0 +1,65 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc]] + +This started appearing when Jérémie's [[glibc]] signal patches were integrated: +very sporadically, but still now and then, `fork` will hand, as follows, and +typically in `/bin/sh`. + +From a `libtool` invocation: + + #0 0x0107b13c in swtch_pri () at /build/eglibc-Q9jlik/eglibc-2.13/build-tree/hurd-i386-libc/mach/swtch_pri.S:2 + No locals. + #1 0x0107c9c4 in __spin_lock_solid (lock=0x125080c) at spin-solid.c:27 + No locals. + #2 0x01091427 in __spin_lock (__lock=) at ../mach/lock-intern.h:55 + No locals. + #3 _hurd_sigstate_lock (ss=0x1250008) at hurdsig.c:172 + No locals. + #4 0x011261ec in _hurd_critical_section_unlock (our_lock=) at ../hurd/hurd/signal.h:235 + No locals. + #5 __fork () at ../sysdeps/mach/hurd/fork.c:706 + env = {{__jmpbuf = {18784244, 19197896, 1, 16925832, 16925460, 17980399}, __mask_was_saved = 0, __saved_mask = 33}} + pid = 0 + err = + __PRETTY_FUNCTION__ = "__fork" + ss = 0x1250008 + threads = 0x0 + nthreads = 0 + stopped = 1 + i = 6 + [...] + + +Another one in `dash`: + + #0 0x0105927c in swtch_pri () at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/mach/swtch_pri.S:2 + No locals. + #1 0x0105ac44 in __spin_lock_solid (lock=0x123580c) at spin-solid.c:27 + No locals. + #2 0x010701c7 in __spin_lock (__lock=) at ../mach/lock-intern.h:55 + No locals. + #3 _hurd_sigstate_lock (ss=0x1235008) at hurdsig.c:172 + No locals. + #4 0x011048f0 in _hurd_critical_section_unlock (our_lock=0x1235008) at ../hurd/hurd/signal.h:235 + ss = 0x1235008 + pending = + #5 __fork () at ../sysdeps/mach/hurd/fork.c:706 + env = {{__jmpbuf = {18780148, 19087304, 134621988, 0, 16938700, 17842902}, __mask_was_saved = 0, __saved_mask = 4294967295}} + pid = 0 + err = 0 + __PRETTY_FUNCTION__ = "__fork" + ss = 0x1235008 + threads = 0x0 + nthreads = 0 + stopped = 1 + i = 6 + [...] -- cgit v1.2.3 From aafa79365242913132b45344bf85ceabf57415e6 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawmOlZj6Ku6rQ8E1D1Wl2ExOtSuLcJNVfyY" Date: Thu, 10 May 2012 16:26:43 +0200 Subject: --- open_issues/fork_deadlock.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'open_issues') diff --git a/open_issues/fork_deadlock.mdwn b/open_issues/fork_deadlock.mdwn index cfb6b743..6b90aa0a 100644 --- a/open_issues/fork_deadlock.mdwn +++ b/open_issues/fork_deadlock.mdwn @@ -11,7 +11,7 @@ License|/fdl]]."]]"""]] [[!tag open_issue_glibc]] This started appearing when Jérémie's [[glibc]] signal patches were integrated: -very sporadically, but still now and then, `fork` will hand, as follows, and +very sporadically, but still now and then, `fork` will hang, as follows, and typically in `/bin/sh`. From a `libtool` invocation: -- cgit v1.2.3 From 85af96d6372927375f60167ba86f907b788e25b4 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sat, 12 May 2012 11:04:21 +0800 Subject: open_issues/glibc: t/dup3 and t/init-first.c resolved. --- open_issues/glibc.mdwn | 17 ----------------- 1 file changed, 17 deletions(-) (limited to 'open_issues') diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn index b15c880a..a5ce402c 100644 --- a/open_issues/glibc.mdwn +++ b/open_issues/glibc.mdwn @@ -39,29 +39,12 @@ git log --reverse --pretty=fuller --stat=$COLUMNS,$COLUMNS -p -C --cc ..sourcewa Last reviewed up to the [[Git mirror's d40c5d54cb551acba4ef1617464760c5b3d41a14 (2012-02-28) sources|source_repositories/glibc]]. - * t/dup3 - - [[tschwinge]] is not convinced that - 22542dcc89805af8d9bd9209129259d2737372b5 (and then also - ff3f3a789ba08b656dbaa3901091b6410bb883f8) are correct. - - * 94b7cc3711b0b74c1d3ae18b9a2e019e51a8e0bf -- dup3 changes; relevant for - `t/dup3`: hidden def. ed690b2f24bbc4d9c541fc81a7c67e6dc5678a96 -- why - not for dup3, too? Because it is a syscall (that is always inlined)? - * `t/hurdsig-fixes` hurdsig.c: In function '_hurd_internal_post_signal': hurdsig.c:1188:26: warning: 'pending' may be used uninitialized in this function [-Wmaybe-uninitialized] hurdsig.c:1168:12: note: 'pending' was declared here - * `t/init-first.c` - - Follow up here: [[!message-id "20070722171859.GN25744@fencepost.gnu.org"]] - or [[!message-id "87mxe4kwws.fsf@gnu.org"]]. Close [[!GNU_Savannah_bug - 17647]]. Debian: [[!message-id "E1Qup1U-0006Zc-39@vasks.debian.org"]] - (part of Ludo's patch; the part that is not harmful to GCC 4.4). - * `t/kernel-features.h_includes` Before running `tg update`, review for additional changes: -- cgit v1.2.3 From 6f9c0342f33f52a2bda98d3709fbefd678bd46d9 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 13 May 2012 06:06:11 +0200 Subject: IRC. --- .../discussion.mdwn | 64 ++++++++++ hurd/console.mdwn | 111 +++++++++++++++- hurd/translator/devfs.mdwn | 36 +++++- hurd/translator/ext2fs.mdwn | 13 +- .../ext2fs/hurd-specific_extensions.mdwn | 23 ++++ hurd/translator/ext2fs/page_cache.mdwn | 31 +++++ hurd/translator/procfs/jkoenig/discussion.mdwn | 61 ++++++++- open_issues/bpf.mdwn | 23 ++++ open_issues/glibc.mdwn | 83 +++++++++++- open_issues/glibc/getlogin_r.mdwn | 45 +++++++ open_issues/glibc/octave.mdwn | 35 +++++ open_issues/gnumach_memory_management.mdwn | 17 +++ open_issues/gnumach_page_cache_policy.mdwn | 35 +++++ open_issues/gnumach_vm_map_red-black_trees.mdwn | 142 +++++++++++++++++++++ open_issues/libpthread.mdwn | 53 +++----- open_issues/libpthread_CLOCK_MONOTONIC.mdwn | 58 +++++++++ open_issues/libpthread_dlopen.mdwn | 49 ++++++- open_issues/o_exec.mdwn | 54 ++++++++ open_issues/packaging_libpthread.mdwn | 114 ++++++++++++++--- open_issues/system_call_mechanism.mdwn | 43 ++++++- open_issues/user-space_device_drivers.mdwn | 10 +- 21 files changed, 1025 insertions(+), 75 deletions(-) create mode 100644 community/gsoc/project_ideas/namespace-based_translator_selection/discussion.mdwn create mode 100644 hurd/translator/ext2fs/hurd-specific_extensions.mdwn create mode 100644 hurd/translator/ext2fs/page_cache.mdwn create mode 100644 open_issues/glibc/getlogin_r.mdwn create mode 100644 open_issues/glibc/octave.mdwn create mode 100644 open_issues/gnumach_page_cache_policy.mdwn create mode 100644 open_issues/gnumach_vm_map_red-black_trees.mdwn create mode 100644 open_issues/libpthread_CLOCK_MONOTONIC.mdwn create mode 100644 open_issues/o_exec.mdwn (limited to 'open_issues') diff --git a/community/gsoc/project_ideas/namespace-based_translator_selection/discussion.mdwn b/community/gsoc/project_ideas/namespace-based_translator_selection/discussion.mdwn new file mode 100644 index 00000000..befd680a --- /dev/null +++ b/community/gsoc/project_ideas/namespace-based_translator_selection/discussion.mdwn @@ -0,0 +1,64 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + + +# IRC, freenode, #hurd, 2012-04-22 + + btw, I was wondering, when working on namespace mangling, did they + think about automatitioning ? + autopartitioning, I meant + i.e. with a foo.img file, open foo.img,,part1 + what are you referring to with namespace mangling + and voila + I don't remember the exact term they used + you mean there is a hurd library that parses names and can direct + to different services depending on part of the name ? + namespace-based_translator_selection + yes + i thought it only handled directories + well, the classical path representation + * civodul finds it ugly + civodul: because of potential conflict, and the not-too-nice ",," + part? + actually I wonder whether using directory access would be nicer + i.e. you have a foo.gz, just open foo.gz/gunzip to get the unzipped + content + and for foo.img.gz, open foo.img.gz/gunzip/part/1 + youpi: because of the interpretation of special chars in file + names + users should be free to use any character they like in file names + foo.gz/gunzip looks nicer to me + ok, so we agree + that said, the user could choose the separator + the namespace can be not run by root for everybody, but just for + your shell, run by yourself + civodul: the user can't use any character anyways... '/' and '\0' + are reserved :-P + antrik: '/' isn't quite reserved on the Hurd :-) + you could implement dir_lookup such that it does something + special about it + (server-side) + civodul: as for overloading '/', although I haven't thought it + through entirely, I guess that would work for nodes that present as files + normally. however, it would *not* work for directory nodes + which would be quite a serious limitation IMHO + I can think of various kinds of useful directory translators + what's more, one of the main use cases I originally had in mind is + a policy filter + you could pass a directory name with a appropriate filter applied + to tar for example, so it wouldn't try to follow any translators + I don't see why taking an obscure prefix like ,, would be much of + a problem in practice anyways + (also, it doesn't strictly prevent the user from having such file + names... you just need to escape it if accessing such files through the + namespace multiplexer. though admittedly that would need some special + handling in *some* programs to work properly) diff --git a/hurd/console.mdwn b/hurd/console.mdwn index f7230011..55581870 100644 --- a/hurd/console.mdwn +++ b/hurd/console.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2002, 2003, 2004, 2005, 2006, 2007, 2009, 2011 -Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2003, 2004, 2005, 2006, 2007, 2009, 2011, +2012 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -9,6 +9,11 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] +[[!toc]] + + +# Architecture: client and server + The Hurd console's implementation is broken into two pieces each running on it's own process, the console client and server. @@ -79,9 +84,9 @@ blocking operations and a blocked `input_dequeue` necessarily needs an `ports_manage_multithreaded` API. ---- +# Old stuff -/!\ old content; [[!taglink open_issue_documentation]]: cleanup needed. +[[!taglink open_issue_documentation]]: cleanup needed. The below is a reworked version of Marcus Brinkmann's [letter to the debian-hurd list](http://lists.debian.org/debian-hurd/2002/debian-hurd-200209/msg00054.html). It describes how to setup the new console server for the Hurd. I am testing this right now, so this document is a work in progress. @@ -357,3 +362,101 @@ An [experimental plugin to load XKB keymaps](http://kilobug.free.fr/hurd/xkb-0.3 Added examples that use repeaters needed by X. -- [[Main/OgnyanKulev]] - 18 Sep 2004 + + +# IRC, freenode #hurd, 2012-04-23 + + is there any way to get copy/paste in hurd? + with the console server + like you get with gpm + Tekk_: by implementing it + Tekk_: that's something for the console client, not the server + (or perhaps both? not entirely sure) + antrik: I'm not entirely sure how the client works + does it start a new client with each tty? + or one client handles all of them? + the client only should be enough + it handles all input already anyway + the client handles all ttys + it just hops over them according to alt-Fx shortcuts + Tekk_: there is only one client for all, but a separate console + *server* for each tty + antrik: ah, the ever confusing X scheme + no + the client handles multiplexing and actual terminal I/O + the servers handle the state of the virtual terminals, and provide + the device nodes + this doesn't fit with the X scheme in any way + (where everything is basically in one big monolithic server + process) + antrik: I mean that you're running multiple servers and there's one + big client running on the other end + which always pretty well confuses everyone to start with + I totally fail to see the connection + there is usually one X server, with potentially many clients + nevermind + doesn't really matter to anything + so yeah, copy/paste would be in the client? + unless you mean a termial server, running actual client programs, + connected to various terminals, running X servers... which is where it + gets confusing in a way ;-) + but there is really no relation at all here + antrik: exactly ;) + I meant in the traditional sense, where you're on a thin client + running an X server and the remote server is running X clients + copy/paste probably isn't really too bad + applications are also clients of the terminal server processes; + but having a completely different role (and using completely different + requests) than the console client + you have a buffer, when something is highlighted you strncpy the + highlighted text into the buffer. when middle click happens you send the + text to the right virtual terminal + right. what I was considering is whether the pasting (and possibly + also grabbing) the text might be done through some separate protocol + implemented in the console server, rather than the ordinary console + client interfaces... but probably no need for that + nah, as long as you have a way of getting a highlighted area and + then the text contained in it + and then of course a way to insert text where the cursor is, but + I'm pretty sure you can safely assume that one :P + well, the client has a way to send keystrokes to the server, + obviously. the question here is whether pretending the pasting is + keystrokes is good enough, or whether it might be useful to have an + explicit way to push the pasted stuff to the server + (the cursor position is relevant only for echo) + antrik: I'll try to grab the console source some time this week and + take a look + maybe I can try to get it working + good luck :-) + it's probably not too hard + I'm sure I'll need it :) + the whole console machinery is quite hard to grasp (and I still + find myself confused sometimes, although I gained a pretty good + understanding I think when writing my thesis) + but for this specific task, not much knowlegde should be needed + about the various confusing aspects + hmm. looks like copy/paste won + 't be a quick thing, actually + wait, no. there must be a way to get mouse events + how else could you move the mouse.. + (with by moving your mouse, not cons_mouse_move) + by moving your mouse* + started typing something different + + +# Graphics/Higher Resolution + +## IRC, freenode #hurd, 2012-04-24 + + does the console support higher resolutions yet? + no + it's just textonly + Tekk_: the main reason why I originally started on the KGI work + was to get a graphical console... but I never finished that part + (since KGI is obsolete anyways) + BTW, there is a KMS-based userspace console now for Linux... I + guess it should be easy to adapt to other systems having KMS support + I don't think it actually makes much sense for Linux, as it's one + of the hardest and least profitable things to move out of a monolithic + kernel... + well, not hardest I guess; but most problematic diff --git a/hurd/translator/devfs.mdwn b/hurd/translator/devfs.mdwn index 8784e998..a9cc307f 100644 --- a/hurd/translator/devfs.mdwn +++ b/hurd/translator/devfs.mdwn @@ -12,7 +12,7 @@ License|/fdl]]."]]"""]] in there in a dynamic fashion -- as compared to static passive translator settings as they're used now. -`devfs` has not yet been written. +`devfs` has not yet been written. [[!tag open_issue_hurd]] --- @@ -23,6 +23,8 @@ path is resident at all times. # IRC, freenode, #hurd, 2012-01-29 +[[!tag open_issue_documentation]] + what would be an hurdish way to achieve something like the various system (udev, devfs, devd, etc) for populating devices files automatically according to the found system devices? @@ -37,3 +39,35 @@ path is resident at all times. /dev directory with unique device names... probably need some unionfs-like translator that collects the individual driver nodes in an intelligent manner + + +# IRC, freenode, #hurd, 2012-04-22 + + braunr: I don't think it's a problem that translators are invoked + when listing /dev + the problem is that they linger around although they are very + unlikely to be needed again any time soon + for now it's not too much a problem because there aren't too many + but that can become problematic + a devfs on /dev could also fill it with new devices + but only with the ones that actually exist + yeah + antrik: i mean, the hurd may lack a feature allowing the same + translator to be used for several nodes not hierarically related + antrik: or rather, it's a special case that we should implement + differently + (with e.g. a devfs that can route requests for different nodes to + a same translator + ) + I agree BTW that some intermediary for /dev would be helpful -- + but I don't think it should actually take over any RPC handling; rather, + only redirect the requests as appropriate (with the actual device nodes + in a hierarchical bus-centric layout) + right + braunr: actually, the Hurd *does* have a feature allowing the same + translator to be attached to several unrelated nodes + i keep getting surprised :) + though it's only used in very few places right now + pfinet and ptys at least ? + yeah, and console client IIRC + diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn index fff2e74b..ad79c7b9 100644 --- a/hurd/translator/ext2fs.mdwn +++ b/hurd/translator/ext2fs.mdwn @@ -1,18 +1,23 @@ -[[!meta copyright="Copyright © 2007, 2008, 2010, 2011 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2012 Free Software +Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + # Implementation * [[filetype]] option + * [[Hurd-specific_extensions]] + + * [[Page_cache]] + ## Large Stores diff --git a/hurd/translator/ext2fs/hurd-specific_extensions.mdwn b/hurd/translator/ext2fs/hurd-specific_extensions.mdwn new file mode 100644 index 00000000..774f1cf3 --- /dev/null +++ b/hurd/translator/ext2fs/hurd-specific_extensions.mdwn @@ -0,0 +1,23 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_documentation]] + + +# IRC, freenode, #hurd, 2012-04-20 + + what are the extensions to ext2? + that hurd uses + tha ability to store passive translator command lines in the + inodes + the* + well, also a fourth set of permission bits, and an "author" field + right + both very obscure features that better never existed... diff --git a/hurd/translator/ext2fs/page_cache.mdwn b/hurd/translator/ext2fs/page_cache.mdwn new file mode 100644 index 00000000..e8a964ed --- /dev/null +++ b/hurd/translator/ext2fs/page_cache.mdwn @@ -0,0 +1,31 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_documentation]] + +This is not at all specific to ext2fs, so should be integrated elsewhere. + + +# IRC, freenode, #hurd, 2012-04-22 + + is there any particular reason ext2fs takes so much memory? + it beats everything on my system hands down at 100 MB + ext2fs contains the page cache + so it's no wonder it takes memory + it's all the mapped files + any way I can cut down on that? + my system only has 512 meg :/ + gnumach is supposed to automatically cut it down as needed + what is the actual symptom that you see? + youpi: 360 MB of memory usage when I'm doing nothing + oh, is it just intelligent enough to cut down when I'm using more + memory? + Tekk_: yes + awesome. I was worried :) diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn index 339fab50..e7fdf46e 100644 --- a/hurd/translator/procfs/jkoenig/discussion.mdwn +++ b/hurd/translator/procfs/jkoenig/discussion.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -218,3 +219,61 @@ Needed by glibc's `pldd` tool (commit # `/proc/self/exe` [[!message-id "alpine.LFD.2.02.1110111111260.2016@akari"]] + + +# `/proc/[PID]/fd/` + +## IRC, freenode, #hurd, 2012-04-24 + + braunr: /proc/*/fd can be implemented in several ways. none of + them would require undue centralisation + braunr: the easiest would be adding one more type of magic lookup + to the existing magic lookup mechanism + wait, I mean /proc/self... for /proc/*/fd it's even more + straighforward -- we might even have a magic lookup for that already + i guess the ideal thing would be implement that fd logic in + libps + pinotree: nope. it doesn't need to ask proc (or any other server) + at all. it's local information. that's what we have the magic lookups for + one option we were considering at some point would be using the + object migration mechanism, so the actual handling would still happen + client-side, but the server could supply the code doing it. this would + allow servers to add arbitrary magic lookup methods without any global + modifications... but has other downsides :-) + youpi: How much info for /proc/*/fd is possible to get from + libps? Re: d-h@ + see my mail + I don't think there is an interface for that + processes handle fds themselves + so libps would have to peek in there + and I don't remember having seen any code like that + 10:17:17< antrik> wait, I mean /proc/self... for /proc/*/fd it's + even more straighforward -- we might even have a magic lookup for that + already + pinotree: For me that does not ring a bell on RPCs. Don't know + what magic means,, + for /proc/self/fd we have a magic lookup + for /proc/pid/fd, I don't think we have + magic lookup* + magic lookup == RPC? + magic lookup is a kind of answer to the lookup RPC + that basically says "it's somewhere else, see there" + the magic FD lookup tells the process "it's your FD number x" + which works for /proc/self/fd, but not /proc/pid/fd + youpi, gnu_srs: regarding FDs, there the msg_get_fd RPC that + could be used + `msgport' should have --get-fd, actually + civodul: I assumed that the reason why msgport doesn't have it is + that it didn't exist + so we can get a port on the fd + but then how to know what it is? + youpi: ah, you mean for the /proc/X/fd symlinks? + good question + it's not designed to be mapped back to names, indeed :-) + youpi: yeah, I realized myself that only /proc/self/fd is trivial + BTW, in Linux it's nor real symlinks. it's magic, with some very + strange (but useful in certain situations) semantics + not real symlinks + it's very weird for example for fd connected to files that have + been unlinked. it looks like a broken symlink, but when dereferencing + (e.g. with cp), you get the actual file contents... diff --git a/open_issues/bpf.mdwn b/open_issues/bpf.mdwn index 2a8c897a..e24d761b 100644 --- a/open_issues/bpf.mdwn +++ b/open_issues/bpf.mdwn @@ -562,3 +562,26 @@ This is a collection of resources concerning *Berkeley Packet Filter*s. DDE accordingly antrik: i agree antrik: eth-multiplexer would be the right place + + +## IRC, freenode, #hurd, 2012-04-24 + + braunr: Is BPF fully supported by now? Can it be used for + isc-dhcp? + gnu_srs: bpf isn't supported at all + gnu_srs: instead of emulating it, i added a hurd-specific module + in libpcap + if isc-dhcp can use libpcap, then fine + (otherwise we could create a hurd-specific patch for dhcp that + uses the in-kernel bpf filter implementation) + gnu_srs: can't it use a raw socket ? + it can + it's just that the shape of the patch to do so wasn't exactly how + they needed it + so they have to rework it a bit + and that takes time + ok + antrik: for now, we prefer encapsulating the system specific code + in libpcap, and let users of that library benefit from it + instead of implementing the low level bpf interface, which + nonetheless has some system-specific variants .. diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn index b15c880a..26fa6012 100644 --- a/open_issues/glibc.mdwn +++ b/open_issues/glibc.mdwn @@ -202,11 +202,59 @@ Last reviewed up to the [[Git mirror's d40c5d54cb551acba4ef1617464760c5b3d41a14 `CLOCK_REALTIME_ALARM`, `O_PATH`, `PTRACE_*` (for example, cbff0d9689c4d68578b6a4f0a17807232506ea27), `RLIMIT_RTTIME`, `SEEK_DATA` (`unistd.h`), `SEEK_HOLE` (`unistd.h`) - `clock_adjtime`, `fallocate`, `fallocate64`, `getcontext` (and - `setcontext`), `name_to_handle_at`, `open_by_handle_at`, - `process_vm_readv`, `process_vm_writev`, `sendmmsg`, + `clock_adjtime`, `fallocate`, `fallocate64`, `name_to_handle_at`, + `open_by_handle_at`, `process_vm_readv`, `process_vm_writev`, `sendmmsg`, `setns`, `sync_file_range` + * `getcontext`/`setcontext` + + Needed for [[gccgo]]. + + IRC, freenode, #hurd, 2012-04-19: + + How much work/knowledge is needed to implement + getcontext/setcontext? + Any already implemented alternatives available? + x86 registers knowledge, as well as unix signal masks + there's the linux implementation that can be taken as an + exxample, but the signal part has to be rewritten + Well, it's a pity they are not implemented. That's the + remaining hurdle to get gccgo working :-( + uh :/ + Everything builds, but the testsuite fails due to these + missing functions. + Regarding getcontext/setcontext they seem to be written + in assembly for linux but the code is not very long. + How much effort would it be to write something similar + for Hurd? Anybody fluent in asm? + And registers and signals. + gnu_srs: Signals is the key thing -- everything else we + can probably just copy. I have never/not yet looked at it, + though. + For kfreebsd it is written in C: kern_context.c, 3/4 in + one file: getcontext, setcontext, swapcontext, not makecontext. + Dunno how much assembly calls used though. + Hi, any preferences about implementing get/setcontext in + C or Asm? + gnu_srs: I think these will have to be implemented in + assembly. Based on the Linux x86 variants. + + IRC, freenode, #hurd, 2012-04-20: + + youpi: Your understanding of that is better than mine + -- the *context stuff can't be very useful at the moment, because + when the user changes uc_stack.ss_sp (which the glibc tests are + doing), we're losing access to the _hurd_threadvars. Correct? + At least the getcontext test works, the other get a + SIGILL. + others + _hurd_threadvars issue is just guessing. + tschwinge: yes, threadvars are on the stack + threadvars is not much code, it should just work, but care + has to be taken on the libpthread/libthread side, which does some + initialization + OK, that at least matches my understanding. + * `syncfs` We should be easily able to implement that one. @@ -264,6 +312,35 @@ Last reviewed up to the [[Git mirror's d40c5d54cb551acba4ef1617464760c5b3d41a14 * `timespec_get` (74033a2507841cf077e31221de2481ff30b43d51) + * `waitflags.h` (`WEXITED`, `WNOWAIT`, `WSTOPPED`, `WCONTINUED`) + + IRC, freenode, #hurd, 2012-04-20: + + in glibc, we use the generic waitflags.h which, unlike + linux's version, does not define WEXITED, WNOWAIT, WSTOPPED, + WCONTINUED + should the generic bits/waitflags.h define them anyway, + since they are posix? + well, we'd have to implement them anyway + but otherwise, I'd say yes + sure, but since glibc headers should expose at least + everything declared by posix, i thought they should be defined + anyway + that might bring bugs + some applications might be #ifdefing them + and break when they are defined but not working + i guess they would define them to 0, andd having them to + non-zero values shouldn't break them (since those values don't do + anything, so they would act as if they were 0.. or not?) + no, I mean they would do something else, not define them to + 0 + like posix/tst-waitid.c, you mean? + yes + + For specific packages: + + * [[octave]] + * Create `t/cleanup_kernel-features.h`. * Add tests from Linux kernel commit messages for `t/dup3` et al. diff --git a/open_issues/glibc/getlogin_r.mdwn b/open_issues/glibc/getlogin_r.mdwn new file mode 100644 index 00000000..9980ea1f --- /dev/null +++ b/open_issues/glibc/getlogin_r.mdwn @@ -0,0 +1,45 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="getlogin_r"]] + +[[!tag open_issue_glibc]] + + +# IRC, freenode, #hurd, 2012-04-23 + + * pinotree spots how our getlogin_r() implementation uses a static + buffer... + oO + braunr: yeah, the _r means "reentrantbutnotreally" xD + pinotree: that's amazing .. + pinotree: without having checked the actual implementation, that + doesn't sound like a problem... + caching doesn't break reentrancy. the problem with the plain + getlogin() is that a static buffer is *returned to the user* + antrik: http://paste.debian.net/164727/ + ah, caching + i don't think this is caching at all + pinotree: OK, not actually caching... but same effect as far as I + can tell + pinotree: or is it the fixed size of the temporary variable you + are concerned about? + antrik: my concern was about the "static" of the buffer used for + the get_login rpc + pinotree: I'm not sure that's a problem. can the login actually + ever change for a running process? + dunno + but if so, it would be pointless to do the rpc every time + instead of just once + pinotree: true + * pinotree would just make it non-static and be safe + pinotree: well, one might argue that allocating a KiB of stack + space is not very friendly, especially in a low-level library... + not sure what the general policy is about such things in libc diff --git a/open_issues/glibc/octave.mdwn b/open_issues/glibc/octave.mdwn new file mode 100644 index 00000000..b12b7558 --- /dev/null +++ b/open_issues/glibc/octave.mdwn @@ -0,0 +1,35 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc]] + + +# IRC, OFTC, #debian-hurd, 2012-04-23 + + diffing the octave i386 vs hurd-i386 build logs gives + interesting surprises + checking whether this system has an arbitrary file name length + limit... no | checking whether this system has an arbitrary + file name length limit... yes + ? + not only that + checking whether getcwd handles long file names properly... yes + | checking whether getcwd handles long file names properly... no, but it + is partly worki+ + ? + -checking whether fdopendir works... yes + +checking whether fdopendir works... no + (- is i386, + is hurd-i386) + -checking whether getlogin_r works with small buffers... yes + +checking whether getlogin_r works with small buffers... no + -checking for working mkstemp... yes + +checking for working mkstemp... no + +checking for working nanosleep... no (mishandles large + arguments) diff --git a/open_issues/gnumach_memory_management.mdwn b/open_issues/gnumach_memory_management.mdwn index f8e27e62..9feb30c8 100644 --- a/open_issues/gnumach_memory_management.mdwn +++ b/open_issues/gnumach_memory_management.mdwn @@ -2116,3 +2116,20 @@ There is a [[!FF_project 266]][[!tag bounty]] on this task. remember) use "physical" instead of "real memory" braunr: thank you. + + +# IRC, freenode, #hurd, 2012-04-22 + + youpi: tschwinge: when the slab code was added, a few new files + made into gnumach that come from my git repo and are used in other + projects as well + they're licensed under BSD upstream and GPL in gnumach, and though + it initially didn't disturb me, now it does + i think i should fix this by leaving the original copyright and + adding the GPL on top + sure, submit a patch + hm i have direct commit acces if im right + then fix it :) + do you want to review ? + I don't think there is any need to + ok diff --git a/open_issues/gnumach_page_cache_policy.mdwn b/open_issues/gnumach_page_cache_policy.mdwn new file mode 100644 index 00000000..75fcdd88 --- /dev/null +++ b/open_issues/gnumach_page_cache_policy.mdwn @@ -0,0 +1,35 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach]] + + +# IRC, freenode, #hurd, 2012-04-26 + + another not-too-long improvement would be changing the page cache + policy + to drop the 4000 objects limit, you mean ? + yes + do you still have my patch attempt ? + no + let me grab that + oh i won't start it right away you know + i'll ask for it when i do + k + (otherwise i fell i'll just loose it again eh) + :) + but i imagine it's not too hard to achieve + yes + i also imagine to set a large threshold of free pages to avoid + deadlocks + which will still be better than the current situation where we + have either lots of free pages because tha max limit is reached, or lots + of pressure and system freezes :/ + yes diff --git a/open_issues/gnumach_vm_map_red-black_trees.mdwn b/open_issues/gnumach_vm_map_red-black_trees.mdwn new file mode 100644 index 00000000..d77bea32 --- /dev/null +++ b/open_issues/gnumach_vm_map_red-black_trees.mdwn @@ -0,0 +1,142 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach]] + + +# IRC, freenode, #hurd, 2012-04-23 + + btw, i'm running a gnumach version using red-black trees for vm + map entries + braunr: sounds fashionable ;-) + braunr: with some perf improvement? + looks promising for our ext2fs instances showing several thousands + of map entries + youpi: i'm not using it for lookups yet + but the tree is there, maintained, used for both regular and copy + maps, and it doesn't crash + good :) + antrik: isn't it ? :) + youpi: and the diff stat is like 50/15 + braunr: what's the goal of using the fashionable trees? + antrik: speeding up lookups in address spaces + braunr: so the idea is that if we have a heavily fragmented + address space, the performance penalty is smaller? + yes + OK + I take it you gave up on attempts to actually decrease + fragmentation?... + it's not as good as reducing fragmentation, which requires + implementing a powerful merge, but it's still better + yes + it's too messy for my brain :/ + I see + oh + it will add some overhead though + I guess log(n) ? + but if there is a significant performance gain, it'll be worth it + yes + i was more thinking about the memory overhead + right now it's a linear list? + I don't think we care nowadays :) + antrik: yes + ouch + antrik: yes ... :> + the original authors expected vm maps to have like 30 entries + so they used a list for the maps, and a hash table for the + object/offset to physical page lookups + there is a small lookup cache though, which is a nice optimization + my code now uses it first, and falls back to the RB tree if the + hint didn't help + braunr: well, don't forget to check whether it actually *is* still + an optimisation, when using fashionable trees ;-) + antrik: i checked that already :) + i did the same in x15 + I see + both bsd and linux uses a similar technique + use* + (well, bsd actually use what is done in mach :) + (or perhaps the other way around... ;-) ) + i don't think so, as the bsd vm is really the mach vm + but we don't care much + oh, right... that part actually went full circle + youpi: i have a patch ready for test on machines with significant + amounts of map entries (e.g. the buildds ..) + youpi: i won't have time for tests tonight, are you interested ? + (i've been running it for 15 minutes without any issue for now) + I'd say post to the list + ok + braunr: your patch uses the rb tree for lookups, right? + braunr: the buildd using rbtree seems swift + but maybe it's just a psychologic effect :) + the chroot ext2fs already has 1392 lines in vminfo + an rbtree can't hurt there :) + braunr: it really seems faster + the reboot might have helped too + benchmarks shall say + for now, I'll just let ironforge use it + youpi: it's always fast after a reboot ;-) + sure + but still + I mean + *obviously* the reboot has helped + but it might not be all + at least it feels so + and obviously only benchmarks can say + the major benefit AIUI is rather that the slowdown happening over + time will be less noticable + +[[performance/degradation]]. + + "over time" is actually quite fast + ext2 fills up very quickly when you build a package + it went up to 1700 lines very quickly + and stabilized around there + yeah, it can be very fast under heavy load + that's why I say reboot seems not all + it's already not so fresh + with 1700 lines in vminfo + well, I don't know how much of the slowdown I'm experiencing + (after doing stuff under memory pressure) is actually related to VM map + fragmentation... + might be all, might be none, might be something in between + then try his patch + guess I should play a bit with vminfo... + well, currently I actually experience pretty little slowdown, as + for certain reasons (only indirectly related to the Hurd) I'm not running + mutt on this machine, so I don't really have memory pressure... + + +## IRC, freenode, #hurd, 2012-04-24 + + youpi: yes, it uses bst lookups + youpi: FYI, the last time i checked, one ext2fs instance had 4k+ + map entries, and another around 7.5k + (on ironforge) + + +## IRC, freenode, #hurd, 2012-04-24 + + braunr: $ sudo vminfo 624 | wc -l + 22957 + there's no way it can not help :) + youpi: 23k, that's really huge + + +## IRC, freenode, #hurd, 2012-04-26 + + youpi: any new numbers wrt the rbtree patch ? + well, buildd times are not really accurate :) + but what I can tell is that it managed to build qtwebkit fine + ok + so the patch is probably safe :) + i'll commit it soon then + I'd say feel free to, yes + thanks diff --git a/open_issues/libpthread.mdwn b/open_issues/libpthread.mdwn index 614f1271..c5054b7f 100644 --- a/open_issues/libpthread.mdwn +++ b/open_issues/libpthread.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -25,43 +26,19 @@ There is a [[!FF_project 275]][[!tag bounty]] on this task. [[!inline pages=community/gsoc/project_ideas/pthreads feeds=no]] +## IRC, freenode, #hurd, 2012-04-26 -# pthread/stubs issue w/ dlopen'ed libraries + youpi: just to be sure: even if libpthread is compiled inside + glibc (with proper symbols forwarding etc), it doesn't change that you + cannot use both cthreads and pthreads in the same app, right? -IRC, freenode, #hurd, 2010-01-24 +[[Packaging_libpthread]]. - youpi: hm, thought about the pthread/stubs issue w/ dlopen'ed - libraries - currently looks like libstdc++ on hurd links to pthread-stubs, - we're the only one with such configuration - i was looking at the gcc 4.4 patch hurd-pthread.diff, could it - be it does not set THREADLIBS in the configure.ac switch case? - that's expected - on linux the libc provides hooks itself, on hurd-i386 it's - pthread-stubs - why not explicitly link to pthread though? - because there is no strict need to, for applications that don't - need libpthread - the dlopen case is a tricky case that pthread-stubs had not thought - about - hm - what if the pthread stubs would be moved in our glibc? - that's what we should do yes - (ideally) - but for this we need to build libpthread along glibc, to get it - really working - and that's the tricky part (Makefile & such) which hasn't been done - yet - why both (stubs + actual libpthread)? - because you need the stubs to be able to call the actual libpthread - as soon libpthread gets dlopened for instance - +as - i see - (remember that nptl does this if you want to see how) - (it's the libc files in nptl/) - (and forward.c) - also if libpthreads gets integrated with glibc don't we need to - switch the hurd from cthreads then? Which has been the blocker all this - time AFAIR? - we don't _need_ to - ok + it's the same libpthread + symbol forwarding does not magically resolve that libpthread lacks + some libthread features :) + i know, i was referring about the clash between actively using + both + there'll still be the issue that only one will be initialized + and one that provides libc thread safety functions, etc. + that's what i wanted to knew, thanks :) diff --git a/open_issues/libpthread_CLOCK_MONOTONIC.mdwn b/open_issues/libpthread_CLOCK_MONOTONIC.mdwn new file mode 100644 index 00000000..f9195540 --- /dev/null +++ b/open_issues/libpthread_CLOCK_MONOTONIC.mdwn @@ -0,0 +1,58 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="libpthread: CLOCK_MONOTONIC"]] + +[[!tag open_issue_glibc open_issue_libpthread]] + +[[!message-id "201204220058.37328.toscano.pino@tiscali.it"]] + + +# IRC, freenode, #hurd- 2012-04-22 + + youpi: what i thought would be creating a + glib/hurd/hurdtime.{c,h}, adding _hurd_gettimeofday and + _hurd_clock_{gettime,settime,getres} to it and making the current .c in + sysdeps call those + yep + that's unfortunate, but that's what nptl actually does + this way we could add inside hurdtime.c the mapped time stuff + too + most probably a noobish question, but why does rt link to + pthread? + no idea :) + possibly due to aio implementation + ./sysdeps/pthread/aio_cancel.c + probably due to that + (and others) + + +## IRC, freenode, #hurd- 2012-04-23 + + pinotree: about librt vs libpthread, don't worry too much for now + libpthread can lib against the already-installed librt + it does work + youpi: wouldn't that cause a dependency loop? + pinotree: what dependency loop? + youpi: librt wouldd link to pthread, no? + and ? + I don't think it's an issue that .so link with each other + it isn't? + well, try + * pinotree never did that + but I don't think it will pose problem + well, perhaps initialization order + anyway, I now have packages built, I'll test that + pinotree: ok, it seems it doesn't work indeed :) + early in initialization + pinotree: the initialization bug might actually not be due to librt + at all + pinotree: yes, things work even with -lrt + wow diff --git a/open_issues/libpthread_dlopen.mdwn b/open_issues/libpthread_dlopen.mdwn index fb665c67..05a07ef2 100644 --- a/open_issues/libpthread_dlopen.mdwn +++ b/open_issues/libpthread_dlopen.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -10,7 +10,52 @@ License|/fdl]]."]]"""]] [[!tag open_issue_libpthread]] -IRC, OFTC, #debian-hurd, 2011-07-21. +[[!toc]] + + +# IRC, freenode, #hurd, 2010-01-24 + + youpi: hm, thought about the pthread/stubs issue w/ dlopen'ed + libraries + currently looks like libstdc++ on hurd links to pthread-stubs, + we're the only one with such configuration + i was looking at the gcc 4.4 patch hurd-pthread.diff, could it + be it does not set THREADLIBS in the configure.ac switch case? + that's expected + on linux the libc provides hooks itself, on hurd-i386 it's + pthread-stubs + why not explicitly link to pthread though? + because there is no strict need to, for applications that don't + need libpthread + the dlopen case is a tricky case that pthread-stubs had not thought + about + hm + what if the pthread stubs would be moved in our glibc? + that's what we should do yes + (ideally) + but for this we need to build libpthread along glibc, to get it + really working + +[[Packaging_libpthread]]. + + and that's the tricky part (Makefile & such) which hasn't been done + yet + why both (stubs + actual libpthread)? + because you need the stubs to be able to call the actual libpthread + as soon libpthread gets dlopened for instance + +as + i see + (remember that nptl does this if you want to see how) + (it's the libc files in nptl/) + (and forward.c) + also if libpthreads gets integrated with glibc don't we need to + switch the hurd from cthreads then? Which has been the blocker all this + time AFAIR? + we don't _need_ to + ok + + +# IRC, OFTC, #debian-hurd, 2011-07-21 there's one known issue with pthreads you can't dlopen() it diff --git a/open_issues/o_exec.mdwn b/open_issues/o_exec.mdwn new file mode 100644 index 00000000..3f77a0f2 --- /dev/null +++ b/open_issues/o_exec.mdwn @@ -0,0 +1,54 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="O_EXEC"]] + +[[!tag open_issue_glibc open_issue_hurd]] + + +# IRC, freenode, #hurd, 2012-04-24 + + interesting, glibc on every OS except hurd (so including linux + too) does not define O_EXEC + can somebody please help me understand a POSIX behaviour? + it's about fexecve: + http://pubs.opengroup.org/onlinepubs/9699919799/functions/fexecve.html + basically, it seems to me (reading the "errors" and "application + usage" sections) that O_EXEC for open() the fd is not mandatory, and if + not used fexecve will check for file permission at call time? + because currently libdiskfs and libnetfs require the fd to be + open with O_EXEC + "Since execute permission is checked by fexecve(), the file + description fd need not have been opened with the O_EXEC flag" + this one makes it clear checking for O_EXEC is wrong + it looks like O_EXEC is only needed when you want to have files + for which only the execution permission is set + but not the read one + (i don't understand the "and write" part though) + "exec will fail if the mode of the file associated with fd does + not grant execute permission to the calling process at the time fexecve() + is called." + this one strengthens the impression you have, that fexecve indeed + checks file permissions at the time it's called + pinotree: hope it helps + so it implies the following: + O_RDONLY → exec works if the file is readable + exec works if the file is readable and/or executable (although + without read permissions you can't check it) + (well, fexecve) + O_EXEC → exec requires that the permission of the file at + fexecve() time have +x + i'd say ye so far + yes + so we need to fix lib{disk,net}fs then + seems so + enlighting, merci braunr + de rien + :) diff --git a/open_issues/packaging_libpthread.mdwn b/open_issues/packaging_libpthread.mdwn index fa3d4312..f8ef4ae7 100644 --- a/open_issues/packaging_libpthread.mdwn +++ b/open_issues/packaging_libpthread.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -10,9 +11,13 @@ License|/fdl]]."]]"""]] [[!tag open_issue_libpthread open_issue_glibc]] -IRC, #hurd, 2010-07-31 +[[!toc]] - My idea was to have a separate libpthread package. What do you think about that? + +# IRC, freenode, #hurd, 2010-07-31 + + My idea was to have a separate libpthread package. What do you + think about that? in the long term, that can't work with glibc because of the thread stub stuff @@ -21,30 +26,103 @@ IRC, #hurd, 2010-07-31 it's not really possible to keep synchronized because you have to decide which package you unpack first (when upgrading) - Hmm, how is that different if two shared libraries are in one package vs. two packages? It isn't atomic either way? Aren't sonames / versioned library packages solving that? + Hmm, how is that different if two shared libraries are in one + package vs. two packages? It isn't atomic either way? Aren't sonames / + versioned library packages solving that? ... for incompatible forward changes? that'd be a mess to maintain - Drepper doesn't have this constraint and thus adds members of private fields at will - OK, but how is it different then if the libpthread is in the Hurd package? + Drepper doesn't have this constraint and thus adds members of + private fields at will + OK, but how is it different then if the libpthread is in the + Hurd package? I'm not saying it's better to have libpthread in the Hurd package OK. - I'm saying it's useless to package it separately when Drepper makes everything to have us put it along glibc + I'm saying it's useless to package it separately when Drepper makes + everything to have us put it along glibc Then, to goal is to have it in glibc? OK. :-) - OK, I can accommodate to that. Isn't not that we'd want to switch libpthread to something else so quickly. - So our official goal is to have libpthread in glibc, at least for Debian purposese? + OK, I can accommodate to that. Isn't not that we'd want to + switch libpthread to something else so quickly. + So our official goal is to have libpthread in glibc, at least + for Debian purposese? for any port purpose Ack. - provided you're using glibc, you're deemed to ship libpthread with it + provided you're using glibc, you're deemed to ship libpthread with + it because of the strong relations Drepper puts between them - (just to remind: we already have bugs just because our current libpthread isn't bound enough to glibc: dlopen()ing a library depending on libpthread doesn't work, for instance) - yeah, pthread-stubs is linked to almost everywhere -lpthread isn't used + (just to remind: we already have bugs just because our current + libpthread isn't bound enough to glibc: dlopen()ing a library depending + on libpthread doesn't work, for instance) + yeah, pthread-stubs is linked to almost everywhere -lpthread + isn't used (would be nice to not have those issues anymore...) - So -- what do we need to put it into glibc? We can make libpthread a Git submodule (or move the code; but it's shared also for Neal's viengoos, so perhaps the submodule is better?), plus some glibc make foo, plus some other adaptions (stubs, etc.) - Does that sound about right, or am I missing something fundamental? + So -- what do we need to put it into glibc? We can make + libpthread a Git submodule (or move the code; but it's shared also for + Neal's viengoos, so perhaps the submodule is better?), plus some glibc + make foo, plus some other adaptions (stubs, etc.) + Does that sound about right, or am I missing something + fundamental? I actually don't know what a git submodule permits :) looks like a good thing for this, yes - Unfortunately I can't allocate much time at the moment to work on this. :-/ - well, as long as I know where we're going, I can know how to package stuff in Debian - That sounds like a plan to me. libpthread -> glibc as submodule. - (note: actually, the interface between glibc and the libpthread is the responsibility of the libpthread: it gives a couple of .c files to be shipped in libc.so) + Unfortunately I can't allocate much time at the moment to work + on this. :-/ + well, as long as I know where we're going, I can know how to + package stuff in Debian + That sounds like a plan to me. libpthread -> glibc as + submodule. + (note: actually, the interface between glibc and the libpthread is + the responsibility of the libpthread: it gives a couple of .c files to be + shipped in libc.so) + + +# IRC, freenode, #hurd, 2012-04-21 + + had you tried to build libpthread as a glibc addon? + youpi: No, I only know about libpthread in Hurd build system, + and libpthread stand-alone (with the Auto* stuff that I added), but not + yet as a glibc add-on. + k + I'm trying it atm + Oh, OK. + that should fix the no-add-needed issue in gcc/binutils, as well as + the pthread_threads assertion errors in threaded plugins + (once I add forward.c, but that part should not be hard) + that means also less use of pthread-stubs^ + ? + tschwinge: do you remember whether sysdeps/mach/bits/spin* are used + by anybody? + they are half-finished (no __PTHREAD_SPIN_LOCK_INITIALIZER), and + come in the way when building in glibc + also, any reason for using ia32 and not i386? glibc uses the latter + pinotree: rid of pthread-stubs yes + \o/ + youpi: You mean sysdeps/mach/i386/machine-lock.h? No idea + about that one, sorry. + I'm talking about libpthread + not glibc + Oh. + sysdeps/ia32/bits/spin-lock.h:# define + __PTHREAD_SPIN_LOCK_INITIALIZER ((__pthread_spinlock_t) 0) + Anyway, no idea about that either. + that one is meant to be used with the spin-lock.h just below + +-inline + also, I guess signal/ was for the l4 port? + youpi: I guess so. + tschwinge: I have an issue with sysdeps pt files: + sysdeps/hurd/pt-getspecific.c is not looked for by libc ; symlinking into + sysdeps/mach/hurd/pt-getspecific.c works + we don't have a non-mach sysdeps directory? + youpi: if you add sysdeps/mach/hurd/Implies containing only + "hurd", does sysdeps/hurd work? + ah, right + youpi: did it work? (and, it was needed in sysdeps/mach/hurd, or + in libpthread/sysdeps/mach/hurd?) + pinotree: it worked, it was for libpthread + good: I got libpthread built and forward working + + +## IRC, freenode, #hurd, 2012-04-23 + + phew + confirmed that moving libpthread to glibc fixes the gcc/binutils + no-add-needed issue diff --git a/open_issues/system_call_mechanism.mdwn b/open_issues/system_call_mechanism.mdwn index 5598148c..68418097 100644 --- a/open_issues/system_call_mechanism.mdwn +++ b/open_issues/system_call_mechanism.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -10,8 +10,47 @@ License|/fdl]]."]]"""]] [[!tag open_issue_gnumach]] -IRC, freenode, #hurd, 2011-05-07 +[[!toc]] + + +# IRC, freenode, #hurd, 2011-05-07 very simple examples: system calls use old call gates, which are the slowest path to kernel space modern processors have dedicated instructions now + + +# IRC, freenode, #hurd, 2012-04-22 + + rah: basically, system calls are slower on mach because they use + call gates instead of newer sysenter/sysexit + braunr: sysenter/exit is a x86_64 thing + rah: apart from that, the code can't get much simpler, and *I* + know, for i have studied it, and wrote a compatible version in a clone + attempt + braunr: on a x86_64 port we'd probably use sysenter/exit + youpi: no there are 32-bits instructions, i don't remember if + they're called sysenter, it's in my thesis though so i'm sure of it :) + braunr: ah, the other part + is linux-x86 using them? + youpi: yes, glibc uses them + and does it really change much nowadays? + what is the actual difference between int 80 and sysenter? + less checking + checking what? + the idt? + ring levels for example + well, checking a ring is fast :) + depending on the original and requested levels, there are lookups + in tables + sysenter always assume 3 to 0 and 0 to 3 for sysexit + ah, also it assumes things about segments + so that indeed makes context things simpler + right + but mach doesn't uses int 0x80 + it uses an lcall + which is a bit slower from what I could read some time ago + (not sure if it's still relevant) + actually in 64bit mode I had to catch lcall from the invalid + instruction trap + perhaps it got dropped in 64bit mode diff --git a/open_issues/user-space_device_drivers.mdwn b/open_issues/user-space_device_drivers.mdwn index 70c3c6dc..25168fce 100644 --- a/open_issues/user-space_device_drivers.mdwn +++ b/open_issues/user-space_device_drivers.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2009, 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009, 2011, 2012 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -64,7 +65,7 @@ Also see [[device drivers and IO systems]]. ## System Boot -IRC, freenode, #hurd, 2011-07-27 +### IRC, freenode, #hurd, 2011-07-27 < braunr> btw, was there any formulation of the modifications required to have disk drivers in userspace ? @@ -88,6 +89,11 @@ IRC, freenode, #hurd, 2011-07-27 < Tekk_> mhm < braunr> s/disk/storage/ +### IRC, freenode, #hurd, 2012-04-25 + + btw, remember the initrd thing? + I just came across task.c in libstore/ :) + # Plan -- cgit v1.2.3 From b75e038615d51cb62c200e336e59202519db8cae Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 13 May 2012 22:36:45 +0800 Subject: IRC. --- open_issues/file_system_exerciser.mdwn | 16 +++++++++++++- open_issues/glibc.mdwn | 29 +++++++++++++++++++++++++ open_issues/gnumach_rpc_timeouts.mdwn | 19 ++++++++++++++++ open_issues/gnumach_vm_map_red-black_trees.mdwn | 12 ++++++++++ open_issues/largefile.mdwn | 21 ++++++++++++++++++ open_issues/packaging_libpthread.mdwn | 11 ++++++++++ 6 files changed, 107 insertions(+), 1 deletion(-) create mode 100644 open_issues/gnumach_rpc_timeouts.mdwn create mode 100644 open_issues/largefile.mdwn (limited to 'open_issues') diff --git a/open_issues/file_system_exerciser.mdwn b/open_issues/file_system_exerciser.mdwn index 4277e5e7..c51863b9 100644 --- a/open_issues/file_system_exerciser.mdwn +++ b/open_issues/file_system_exerciser.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -13,3 +13,17 @@ License|/fdl]]."]]"""]] Test our file system implementations with the File System Exerciser. * + + +# Alternatives + + +## fs_mark + + +### IRC, freenode, #hurd, 2012-04-30 + + mcsim: http://sourceforge.net/projects/fsmark/ + mcsim: just saw it in debian's NEW queue and from the + description it seemed like something it could be helpful for you + (and in general to test fs'es) diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn index 6c52cc7f..1ce47560 100644 --- a/open_issues/glibc.mdwn +++ b/open_issues/glibc.mdwn @@ -189,6 +189,35 @@ Last reviewed up to the [[Git mirror's d40c5d54cb551acba4ef1617464760c5b3d41a14 `open_by_handle_at`, `process_vm_readv`, `process_vm_writev`, `sendmmsg`, `setns`, `sync_file_range` + * `chflags` + + IRC, OFTC, #debian-hurd, 2012-04-27: + + Does anyone have any idea why int main(void) { return + chflags(); } will compile with gcc but not with g++ ? It says + that "chflags" was not declared in this scope. + I get the same error on FreeBSD, but including sys/stat.h + makes it work + Can't find a solution on Hurd though :/ + the Hurd doesn't have chflags + apparently linux neither + what does it do? + change flags :) + Are you sure the Hurd does not have chflags ? Because gcc + does not complain + there is no chflags function in /usr/include + but what flags does it change? + According to the FreeBSD manpage, it can set flags such as + UF_NODUMP, UF_IMMUTABLE etc. + Hum, there is actually a chflags() definition + but no declaration + so actually chflags is supported, but the declaration was + forgotten + probably because since linux doens't have it, it has never + been a problem up to now + so I'd say ignore the error for now, we'll add the + declaration + * `getcontext`/`setcontext` Needed for [[gccgo]]. diff --git a/open_issues/gnumach_rpc_timeouts.mdwn b/open_issues/gnumach_rpc_timeouts.mdwn new file mode 100644 index 00000000..68cfcb5a --- /dev/null +++ b/open_issues/gnumach_rpc_timeouts.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach]] + + +# IRC, freenode, #hurd, 2012-04-28 + + uhm, apparently mach cannot handle timeouts for rpc's of more + than (2^(sizeof(mach_msg_timeout_t) * 8) - 1) / HZ + it seems that how ticks are calculated in mach, it becomes 0 + +because of diff --git a/open_issues/gnumach_vm_map_red-black_trees.mdwn b/open_issues/gnumach_vm_map_red-black_trees.mdwn index d77bea32..17263099 100644 --- a/open_issues/gnumach_vm_map_red-black_trees.mdwn +++ b/open_issues/gnumach_vm_map_red-black_trees.mdwn @@ -140,3 +140,15 @@ License|/fdl]]."]]"""]] i'll commit it soon then I'd say feel free to, yes thanks + + +## IRC, freenode, #hurd, 2012-04-27 + + elmig: don't expect anything grand though, this patch is mostly + useful when address spaces get really fragmented, which mainly happens on + buildds + (and it only speeds lookups, which isn't as good as reducing + fragmentation; things like fork still have to copy thousands of map + entries) + +[[glibc/fork]]. diff --git a/open_issues/largefile.mdwn b/open_issues/largefile.mdwn new file mode 100644 index 00000000..a6f76a0e --- /dev/null +++ b/open_issues/largefile.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + + +# IRC, freenode, #hurd, 2012-04-26 + + i kind of understood why (at least in some parts) largefile doesn't seem to work properly + libdiskfs/io-seek.c, SEEK_SET case: cred->po->filepointer = offset; + offset is off_t, which becomes off64_t when compiled with largefile, but filepointer seems to be... int + at least in libdiskfs/diskfs.h, while in libnetfs/netfs.h seems ok (loff_t) + diskfs.h is a public header though :/ + well, we can change the soname to mark ABI change diff --git a/open_issues/packaging_libpthread.mdwn b/open_issues/packaging_libpthread.mdwn index f8ef4ae7..d243aaaa 100644 --- a/open_issues/packaging_libpthread.mdwn +++ b/open_issues/packaging_libpthread.mdwn @@ -126,3 +126,14 @@ License|/fdl]]."]]"""]] phew confirmed that moving libpthread to glibc fixes the gcc/binutils no-add-needed issue + + +## IRC, freenode, #hurd, 2012-04-27 + + youpi: wouldn't be the case to rename ia32 subdirs to i386 in + libpthread? + after all, Makefile hardcodes it, Makefile.am sets the variable + for it, and glibc expects i386 + I know, I've asked tschwinge about it + it's not urging anyway + right -- cgit v1.2.3