summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--community/gsoc/project_ideas/namespace-based_translator_selection/discussion.mdwn64
-rw-r--r--hurd/console.mdwn111
-rw-r--r--hurd/translator/devfs.mdwn36
-rw-r--r--hurd/translator/ext2fs.mdwn13
-rw-r--r--hurd/translator/ext2fs/hurd-specific_extensions.mdwn23
-rw-r--r--hurd/translator/ext2fs/page_cache.mdwn31
-rw-r--r--hurd/translator/procfs/jkoenig/discussion.mdwn61
-rw-r--r--open_issues/bpf.mdwn23
-rw-r--r--open_issues/glibc.mdwn83
-rw-r--r--open_issues/glibc/getlogin_r.mdwn45
-rw-r--r--open_issues/glibc/octave.mdwn35
-rw-r--r--open_issues/gnumach_memory_management.mdwn17
-rw-r--r--open_issues/gnumach_page_cache_policy.mdwn35
-rw-r--r--open_issues/gnumach_vm_map_red-black_trees.mdwn142
-rw-r--r--open_issues/libpthread.mdwn53
-rw-r--r--open_issues/libpthread_CLOCK_MONOTONIC.mdwn58
-rw-r--r--open_issues/libpthread_dlopen.mdwn49
-rw-r--r--open_issues/o_exec.mdwn54
-rw-r--r--open_issues/packaging_libpthread.mdwn114
-rw-r--r--open_issues/system_call_mechanism.mdwn43
-rw-r--r--open_issues/user-space_device_drivers.mdwn10
21 files changed, 1025 insertions, 75 deletions
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
+
+ <youpi> btw, I was wondering, when working on namespace mangling, did they
+ think about automatitioning ?
+ <youpi> autopartitioning, I meant
+ <youpi> i.e. with a foo.img file, open foo.img,,part1
+ <braunr> what are you referring to with namespace mangling
+ <youpi> and voila
+ <youpi> I don't remember the exact term they used
+ <braunr> you mean there is a hurd library that parses names and can direct
+ to different services depending on part of the name ?
+ <youpi> namespace-based_translator_selection
+ <youpi> yes
+ <braunr> i thought it only handled directories
+ <braunr> well, the classical path representation
+ * civodul finds it ugly
+ <youpi> civodul: because of potential conflict, and the not-too-nice ",,"
+ part?
+ <youpi> actually I wonder whether using directory access would be nicer
+ <youpi> i.e. you have a foo.gz, just open foo.gz/gunzip to get the unzipped
+ content
+ <youpi> and for foo.img.gz, open foo.img.gz/gunzip/part/1
+ <civodul> youpi: because of the interpretation of special chars in file
+ names
+ <civodul> users should be free to use any character they like in file names
+ <civodul> foo.gz/gunzip looks nicer to me
+ <youpi> ok, so we agree
+ <youpi> that said, the user could choose the separator
+ <youpi> the namespace can be not run by root for everybody, but just for
+ your shell, run by yourself
+ <antrik> civodul: the user can't use any character anyways... '/' and '\0'
+ are reserved :-P
+ <civodul> antrik: '/' isn't quite reserved on the Hurd :-)
+ <civodul> you could implement dir_lookup such that it does something
+ special about it
+ <civodul> (server-side)
+ <antrik> 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
+ <antrik> which would be quite a serious limitation IMHO
+ <antrik> I can think of various kinds of useful directory translators
+ <antrik> what's more, one of the main use cases I originally had in mind is
+ a policy filter
+ <antrik> you could pass a directory name with a appropriate filter applied
+ to tar for example, so it wouldn't try to follow any translators
+ <antrik> I don't see why taking an obscure prefix like ,, would be much of
+ a problem in practice anyways
+ <antrik> (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
+
+ <Tekk_> is there any way to get copy/paste in hurd?
+ <Tekk_> with the console server
+ <Tekk_> like you get with gpm
+ <youpi> Tekk_: by implementing it
+ <antrik> Tekk_: that's something for the console client, not the server
+ <antrik> (or perhaps both? not entirely sure)
+ <Tekk_> antrik: I'm not entirely sure how the client works
+ <Tekk_> does it start a new client with each tty?
+ <Tekk_> or one client handles all of them?
+ <youpi> the client only should be enough
+ <youpi> it handles all input already anyway
+ <youpi> the client handles all ttys
+ <youpi> it just hops over them according to alt-Fx shortcuts
+ <antrik> Tekk_: there is only one client for all, but a separate console
+ *server* for each tty
+ <Tekk_> antrik: ah, the ever confusing X scheme
+ <antrik> no
+ <antrik> the client handles multiplexing and actual terminal I/O
+ <antrik> the servers handle the state of the virtual terminals, and provide
+ the device nodes
+ <antrik> this doesn't fit with the X scheme in any way
+ <antrik> (where everything is basically in one big monolithic server
+ process)
+ <Tekk_> antrik: I mean that you're running multiple servers and there's one
+ big client running on the other end
+ <Tekk_> which always pretty well confuses everyone to start with
+ <antrik> I totally fail to see the connection
+ <antrik> there is usually one X server, with potentially many clients
+ <Tekk_> nevermind
+ <Tekk_> doesn't really matter to anything
+ <Tekk_> so yeah, copy/paste would be in the client?
+ <antrik> 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 ;-)
+ <antrik> but there is really no relation at all here
+ <Tekk_> antrik: exactly ;)
+ <Tekk_> 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
+ <Tekk_> copy/paste probably isn't really too bad
+ <antrik> applications are also clients of the terminal server processes;
+ but having a completely different role (and using completely different
+ requests) than the console client
+ <Tekk_> 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
+ <antrik> 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
+ <Tekk_> nah, as long as you have a way of getting a highlighted area and
+ then the text contained in it
+ <Tekk_> 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
+ <antrik> 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
+ <antrik> (the cursor position is relevant only for echo)
+ <Tekk_> antrik: I'll try to grab the console source some time this week and
+ take a look
+ <Tekk_> maybe I can try to get it working
+ <antrik> good luck :-)
+ <antrik> it's probably not too hard
+ <Tekk_> I'm sure I'll need it :)
+ <antrik> 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)
+ <antrik> but for this specific task, not much knowlegde should be needed
+ about the various confusing aspects
+ <Tekk_> hmm. looks like copy/paste won
+ <Tekk_> 't be a quick thing, actually
+ <Tekk_> wait, no. there must be a way to get mouse events
+ <Tekk_> how else could you move the mouse..
+ <Tekk_> (with by moving your mouse, not cons_mouse_move)
+ <Tekk_> by moving your mouse*
+ <Tekk_> started typing something different
+
+
+# Graphics/Higher Resolution
+
+## IRC, freenode #hurd, 2012-04-24
+
+ <Tekk_> does the console support higher resolutions yet?
+ <youpi> no
+ <youpi> it's just textonly
+ <antrik> Tekk_: the main reason why I originally started on the KGI work
+ was to get a graphical console... but I never finished that part
+ <antrik> (since KGI is obsolete anyways)
+ <antrik> 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
+ <antrik> 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...
+ <antrik> 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]]
+
<pinotree> 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
+
+ <antrik> braunr: I don't think it's a problem that translators are invoked
+ when listing /dev
+ <antrik> the problem is that they linger around although they are very
+ unlikely to be needed again any time soon
+ <youpi> for now it's not too much a problem because there aren't too many
+ <youpi> but that can become problematic
+ <pinotree> a devfs on /dev could also fill it with new devices
+ <youpi> but only with the ones that actually exist
+ <pinotree> yeah
+ <braunr> antrik: i mean, the hurd may lack a feature allowing the same
+ translator to be used for several nodes not hierarically related
+ <braunr> antrik: or rather, it's a special case that we should implement
+ differently
+ <braunr> (with e.g. a devfs that can route requests for different nodes to
+ a same translator
+ <braunr> )
+ <antrik> 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)
+ <braunr> right
+ <antrik> braunr: actually, the Hurd *does* have a feature allowing the same
+ translator to be attached to several unrelated nodes
+ <braunr> i keep getting surprised :)
+ <antrik> though it's only used in very few places right now
+ <youpi> pfinet and ptys at least ?
+ <antrik> 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
+
+ <Tekk_> what are the extensions to ext2?
+ <Tekk_> that hurd uses
+ <braunr> tha ability to store passive translator command lines in the
+ inodes
+ <braunr> the*
+ <antrik> well, also a fourth set of permission bits, and an "author" field
+ <braunr> right
+ <antrik> 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
+
+ <Tekk_> is there any particular reason ext2fs takes so much memory?
+ <Tekk_> it beats everything on my system hands down at 100 MB
+ <youpi> ext2fs contains the page cache
+ <youpi> so it's no wonder it takes memory
+ <youpi> it's all the mapped files
+ <Tekk_> any way I can cut down on that?
+ <Tekk_> my system only has 512 meg :/
+ <youpi> gnumach is supposed to automatically cut it down as needed
+ <youpi> what is the actual symptom that you see?
+ <Tekk_> youpi: 360 MB of memory usage when I'm doing nothing
+ <Tekk_> oh, is it just intelligent enough to cut down when I'm using more
+ memory?
+ <youpi> Tekk_: yes
+ <Tekk_> 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
+
+ <antrik> braunr: /proc/*/fd can be implemented in several ways. none of
+ them would require undue centralisation
+ <antrik> braunr: the easiest would be adding one more type of magic lookup
+ to the existing magic lookup mechanism
+ <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> i guess the ideal thing would be implement that fd logic in
+ libps
+ <antrik> 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
+ <antrik> 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 :-)
+ <gnu_srs> youpi: How much info for /proc/*/fd is possible to get from
+ libps? Re: d-h@
+ <youpi> see my mail
+ <youpi> I don't think there is an interface for that
+ <youpi> processes handle fds themselves
+ <youpi> so libps would have to peek in there
+ <youpi> and I don't remember having seen any code like that
+ <gnu_srs> 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
+ <gnu_srs> pinotree: For me that does not ring a bell on RPCs. Don't know
+ what magic means,,
+ <youpi> for /proc/self/fd we have a magic lookup
+ <youpi> for /proc/pid/fd, I don't think we have
+ <gnu_srs> magic lookup*
+ <gnu_srs> magic lookup == RPC?
+ <youpi> magic lookup is a kind of answer to the lookup RPC
+ <youpi> that basically says "it's somewhere else, see there"
+ <youpi> the magic FD lookup tells the process "it's your FD number x"
+ <youpi> which works for /proc/self/fd, but not /proc/pid/fd
+ <civodul> youpi, gnu_srs: regarding FDs, there the msg_get_fd RPC that
+ could be used
+ <civodul> `msgport' should have --get-fd, actually
+ <youpi> civodul: I assumed that the reason why msgport doesn't have it is
+ that it didn't exist
+ <youpi> so we can get a port on the fd
+ <youpi> but then how to know what it is?
+ <civodul> youpi: ah, you mean for the /proc/X/fd symlinks?
+ <civodul> good question
+ <civodul> it's not designed to be mapped back to names, indeed :-)
+ <antrik> youpi: yeah, I realized myself that only /proc/self/fd is trivial
+ <antrik> BTW, in Linux it's nor real symlinks. it's magic, with some very
+ strange (but useful in certain situations) semantics
+ <antrik> not real symlinks
+ <antrik> 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
<braunr> antrik: i agree
<braunr> antrik: eth-multiplexer would be the right place
+
+
+## IRC, freenode, #hurd, 2012-04-24
+
+ <gnu_srs> braunr: Is BPF fully supported by now? Can it be used for
+ isc-dhcp?
+ <braunr> gnu_srs: bpf isn't supported at all
+ <braunr> gnu_srs: instead of emulating it, i added a hurd-specific module
+ in libpcap
+ <braunr> if isc-dhcp can use libpcap, then fine
+ <braunr> (otherwise we could create a hurd-specific patch for dhcp that
+ uses the in-kernel bpf filter implementation)
+ <braunr> gnu_srs: can't it use a raw socket ?
+ <youpi> it can
+ <youpi> it's just that the shape of the patch to do so wasn't exactly how
+ they needed it
+ <youpi> so they have to rework it a bit
+ <youpi> and that takes time
+ <braunr> ok
+ <braunr> antrik: for now, we prefer encapsulating the system specific code
+ in libpcap, and let users of that library benefit from it
+ <braunr> 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 a5ce402c..6c52cc7f 100644
--- a/open_issues/glibc.mdwn
+++ b/open_issues/glibc.mdwn
@@ -185,11 +185,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:
+
+ <gnu_srs> How much work/knowledge is needed to implement
+ getcontext/setcontext?
+ <gnu_srs> Any already implemented alternatives available?
+ <youpi> x86 registers knowledge, as well as unix signal masks
+ <youpi> there's the linux implementation that can be taken as an
+ exxample, but the signal part has to be rewritten
+ <gnu_srs> Well, it's a pity they are not implemented. That's the
+ remaining hurdle to get gccgo working :-(
+ <youpi> uh :/
+ <gnu_srs> Everything builds, but the testsuite fails due to these
+ missing functions.
+ <gnu_srs> Regarding getcontext/setcontext they seem to be written
+ in assembly for linux but the code is not very long.
+ <gnu_srs> How much effort would it be to write something similar
+ for Hurd? Anybody fluent in asm?
+ <gnu_srs> And registers and signals.
+ <tschwinge> gnu_srs: Signals is the key thing -- everything else we
+ can probably just copy. I have never/not yet looked at it,
+ though.
+ <gnu_srs> For kfreebsd it is written in C: kern_context.c, 3/4 in
+ one file: getcontext, setcontext, swapcontext, not makecontext.
+ <gnu_srs> Dunno how much assembly calls used though.
+ <gnu_srs> Hi, any preferences about implementing get/setcontext in
+ C or Asm?
+ <tschwinge> gnu_srs: I think these will have to be implemented in
+ assembly. Based on the Linux x86 variants.
+
+ IRC, freenode, #hurd, 2012-04-20:
+
+ <tschwinge> 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?
+ <tschwinge> At least the getcontext test works, the other get a
+ SIGILL.
+ <tschwinge> others
+ <tschwinge> _hurd_threadvars issue is just guessing.
+ <youpi> tschwinge: yes, threadvars are on the stack
+ <youpi> threadvars is not much code, it should just work, but care
+ has to be taken on the libpthread/libthread side, which does some
+ initialization
+ <tschwinge> OK, that at least matches my understanding.
+
* `syncfs`
We should be easily able to implement that one.
@@ -247,6 +295,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:
+
+ <pinotree> in glibc, we use the generic waitflags.h which, unlike
+ linux's version, does not define WEXITED, WNOWAIT, WSTOPPED,
+ WCONTINUED
+ <pinotree> should the generic bits/waitflags.h define them anyway,
+ since they are posix?
+ <youpi> well, we'd have to implement them anyway
+ <youpi> but otherwise, I'd say yes
+ <pinotree> sure, but since glibc headers should expose at least
+ everything declared by posix, i thought they should be defined
+ anyway
+ <youpi> that might bring bugs
+ <youpi> some applications might be #ifdefing them
+ <youpi> and break when they are defined but not working
+ <pinotree> i guess they would define them to 0, andd having them to
+ non-zero values shouldn't break them (since those values don't do
+ anything, so they would act as if they were 0.. or not?)
+ <youpi> no, I mean they would do something else, not define them to
+ 0
+ <pinotree> like posix/tst-waitid.c, you mean?
+ <youpi> yes
+
+ 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...
+ <braunr> oO
+ <pinotree> braunr: yeah, the _r means "reentrantbutnotreally" xD
+ <braunr> pinotree: that's amazing ..
+ <antrik> pinotree: without having checked the actual implementation, that
+ doesn't sound like a problem...
+ <antrik> caching doesn't break reentrancy. the problem with the plain
+ getlogin() is that a static buffer is *returned to the user*
+ <pinotree> antrik: http://paste.debian.net/164727/
+ <braunr> ah, caching
+ <pinotree> i don't think this is caching at all
+ <antrik> pinotree: OK, not actually caching... but same effect as far as I
+ can tell
+ <antrik> pinotree: or is it the fixed size of the temporary variable you
+ are concerned about?
+ <pinotree> antrik: my concern was about the "static" of the buffer used for
+ the get_login rpc
+ <antrik> pinotree: I'm not sure that's a problem. can the login actually
+ ever change for a running process?
+ <pinotree> dunno
+ <pinotree> but if so, it would be pointless to do the rpc every time
+ instead of just once
+ <antrik> pinotree: true
+ * pinotree would just make it non-static and be safe
+ <antrik> pinotree: well, one might argue that allocating a KiB of stack
+ space is not very friendly, especially in a low-level library...
+ <antrik> 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
+
+ <pinotree> diffing the octave i386 vs hurd-i386 build logs gives
+ interesting surprises
+ <youpi> checking whether this system has an arbitrary file name length
+ limit... no | checking whether this system has an arbitrary
+ file name length limit... yes
+ <youpi> ?
+ <pinotree> not only that
+ <youpi> checking whether getcwd handles long file names properly... yes
+ | checking whether getcwd handles long file names properly... no, but it
+ is partly worki+
+ <youpi> ?
+ <pinotree> -checking whether fdopendir works... yes
+ <pinotree> +checking whether fdopendir works... no
+ <pinotree> (- is i386, + is hurd-i386)
+ <pinotree> -checking whether getlogin_r works with small buffers... yes
+ <pinotree> +checking whether getlogin_r works with small buffers... no
+ <pinotree> -checking for working mkstemp... yes
+ <pinotree> +checking for working mkstemp... no
+ <pinotree> +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)
<braunr> use "physical" instead of "real memory"
<mcsim> braunr: thank you.
+
+
+# IRC, freenode, #hurd, 2012-04-22
+
+ <braunr> 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
+ <braunr> they're licensed under BSD upstream and GPL in gnumach, and though
+ it initially didn't disturb me, now it does
+ <braunr> i think i should fix this by leaving the original copyright and
+ adding the GPL on top
+ <youpi> sure, submit a patch
+ <braunr> hm i have direct commit acces if im right
+ <youpi> then fix it :)
+ <braunr> do you want to review ?
+ <youpi> I don't think there is any need to
+ <braunr> 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
+
+ <braunr> another not-too-long improvement would be changing the page cache
+ policy
+ <youpi> to drop the 4000 objects limit, you mean ?
+ <braunr> yes
+ <youpi> do you still have my patch attempt ?
+ <braunr> no
+ <youpi> let me grab that
+ <braunr> oh i won't start it right away you know
+ <braunr> i'll ask for it when i do
+ <youpi> k
+ <braunr> (otherwise i fell i'll just loose it again eh)
+ <youpi> :)
+ <braunr> but i imagine it's not too hard to achieve
+ <youpi> yes
+ <braunr> i also imagine to set a large threshold of free pages to avoid
+ deadlocks
+ <braunr> 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 :/
+ <youpi> 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
+
+ <braunr> btw, i'm running a gnumach version using red-black trees for vm
+ map entries
+ <antrik> braunr: sounds fashionable ;-)
+ <youpi> braunr: with some perf improvement?
+ <braunr> looks promising for our ext2fs instances showing several thousands
+ of map entries
+ <braunr> youpi: i'm not using it for lookups yet
+ <braunr> but the tree is there, maintained, used for both regular and copy
+ maps, and it doesn't crash
+ <youpi> good :)
+ <braunr> antrik: isn't it ? :)
+ <braunr> youpi: and the diff stat is like 50/15
+ <antrik> braunr: what's the goal of using the fashionable trees?
+ <braunr> antrik: speeding up lookups in address spaces
+ <antrik> braunr: so the idea is that if we have a heavily fragmented
+ address space, the performance penalty is smaller?
+ <braunr> yes
+ <antrik> OK
+ <antrik> I take it you gave up on attempts to actually decrease
+ fragmentation?...
+ <braunr> it's not as good as reducing fragmentation, which requires
+ implementing a powerful merge, but it's still better
+ <braunr> yes
+ <braunr> it's too messy for my brain :/
+ <antrik> I see
+ <antrik> oh
+ <braunr> it will add some overhead though
+ <youpi> I guess log(n) ?
+ <braunr> but if there is a significant performance gain, it'll be worth it
+ <braunr> yes
+ <braunr> i was more thinking about the memory overhead
+ <antrik> right now it's a linear list?
+ <youpi> I don't think we care nowadays :)
+ <braunr> antrik: yes
+ <antrik> ouch
+ <braunr> antrik: yes ... :>
+ <braunr> the original authors expected vm maps to have like 30 entries
+ <braunr> so they used a list for the maps, and a hash table for the
+ object/offset to physical page lookups
+ <braunr> there is a small lookup cache though, which is a nice optimization
+ <braunr> my code now uses it first, and falls back to the RB tree if the
+ hint didn't help
+ <antrik> braunr: well, don't forget to check whether it actually *is* still
+ an optimisation, when using fashionable trees ;-)
+ <braunr> antrik: i checked that already :)
+ <braunr> i did the same in x15
+ <antrik> I see
+ <braunr> both bsd and linux uses a similar technique
+ <braunr> use*
+ <braunr> (well, bsd actually use what is done in mach :)
+ <antrik> (or perhaps the other way around... ;-) )
+ <braunr> i don't think so, as the bsd vm is really the mach vm
+ <braunr> but we don't care much
+ <antrik> oh, right... that part actually went full circle
+ <braunr> youpi: i have a patch ready for test on machines with significant
+ amounts of map entries (e.g. the buildds ..)
+ <braunr> youpi: i won't have time for tests tonight, are you interested ?
+ <braunr> (i've been running it for 15 minutes without any issue for now)
+ <youpi> I'd say post to the list
+ <braunr> ok
+ <youpi> braunr: your patch uses the rb tree for lookups, right?
+ <youpi> braunr: the buildd using rbtree seems swift
+ <youpi> but maybe it's just a psychologic effect :)
+ <youpi> the chroot ext2fs already has 1392 lines in vminfo
+ <youpi> an rbtree can't hurt there :)
+ <youpi> braunr: it really seems faster
+ <youpi> the reboot might have helped too
+ <youpi> benchmarks shall say
+ <youpi> for now, I'll just let ironforge use it
+ <antrik> youpi: it's always fast after a reboot ;-)
+ <youpi> sure
+ <youpi> but still
+ <youpi> I mean
+ <youpi> *obviously* the reboot has helped
+ <youpi> but it might not be all
+ <youpi> at least it feels so
+ <youpi> and obviously only benchmarks can say
+ <antrik> the major benefit AIUI is rather that the slowdown happening over
+ time will be less noticable
+
+[[performance/degradation]].
+
+ <youpi> "over time" is actually quite fast
+ <youpi> ext2 fills up very quickly when you build a package
+ <youpi> it went up to 1700 lines very quickly
+ <youpi> and stabilized around there
+ <antrik> yeah, it can be very fast under heavy load
+ <youpi> that's why I say reboot seems not all
+ <youpi> it's already not so fresh
+ <youpi> with 1700 lines in vminfo
+ <antrik> 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...
+ <antrik> might be all, might be none, might be something in between
+ <youpi> then try his patch
+ <antrik> guess I should play a bit with vminfo...
+ <antrik> 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
+
+ <braunr> youpi: yes, it uses bst lookups
+ <braunr> youpi: FYI, the last time i checked, one ext2fs instance had 4k+
+ map entries, and another around 7.5k
+ <braunr> (on ironforge)
+
+
+## IRC, freenode, #hurd, 2012-04-24
+
+ <youpi> braunr: $ sudo vminfo 624 | wc -l
+ <youpi> 22957
+ <youpi> there's no way it can not help :)
+ <braunr> youpi: 23k, that's really huge
+
+
+## IRC, freenode, #hurd, 2012-04-26
+
+ <braunr> youpi: any new numbers wrt the rbtree patch ?
+ <youpi> well, buildd times are not really accurate :)
+ <youpi> but what I can tell is that it managed to build qtwebkit fine
+ <braunr> ok
+ <youpi> so the patch is probably safe :)
+ <braunr> i'll commit it soon then
+ <youpi> I'd say feel free to, yes
+ <braunr> 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
+ <pinotree> 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]].
- <pinotree> youpi: hm, thought about the pthread/stubs issue w/ dlopen'ed
- libraries
- <pinotree> currently looks like libstdc++ on hurd links to pthread-stubs,
- we're the only one with such configuration
- <pinotree> 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?
- <youpi> that's expected
- <youpi> on linux the libc provides hooks itself, on hurd-i386 it's
- pthread-stubs
- <pinotree> why not explicitly link to pthread though?
- <youpi> because there is no strict need to, for applications that don't
- need libpthread
- <youpi> the dlopen case is a tricky case that pthread-stubs had not thought
- about
- <pinotree> hm
- <pinotree> what if the pthread stubs would be moved in our glibc?
- <youpi> that's what we should do yes
- <youpi> (ideally)
- <youpi> but for this we need to build libpthread along glibc, to get it
- really working
- <youpi> and that's the tricky part (Makefile & such) which hasn't been done
- yet
- <pinotree> why both (stubs + actual libpthread)?
- <youpi> because you need the stubs to be able to call the actual libpthread
- <youpi> as soon libpthread gets dlopened for instance
- <youpi> +as
- <pinotree> i see
- <youpi> (remember that nptl does this if you want to see how)
- <youpi> (it's the libc files in nptl/)
- <youpi> (and forward.c)
- <guillem> 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?
- <youpi> we don't _need_ to
- <guillem> ok
+ <youpi> it's the same libpthread
+ <youpi> symbol forwarding does not magically resolve that libpthread lacks
+ some libthread features :)
+ <pinotree> i know, i was referring about the clash between actively using
+ both
+ <youpi> there'll still be the issue that only one will be initialized
+ <youpi> and one that provides libc thread safety functions, etc.
+ <pinotree> 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
+
+ <pinotree> 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
+ <youpi> yep
+ <youpi> that's unfortunate, but that's what nptl actually does
+ <pinotree> this way we could add inside hurdtime.c the mapped time stuff
+ too
+ <pinotree> most probably a noobish question, but why does rt link to
+ pthread?
+ <youpi> no idea :)
+ <youpi> possibly due to aio implementation
+ <youpi> ./sysdeps/pthread/aio_cancel.c
+ <youpi> probably due to that
+ <youpi> (and others)
+
+
+## IRC, freenode, #hurd- 2012-04-23
+
+ <youpi> pinotree: about librt vs libpthread, don't worry too much for now
+ <youpi> libpthread can lib against the already-installed librt
+ <youpi> it does work
+ <pinotree> youpi: wouldn't that cause a dependency loop?
+ <youpi> pinotree: what dependency loop?
+ <pinotree> youpi: librt wouldd link to pthread, no?
+ <youpi> and ?
+ <youpi> I don't think it's an issue that .so link with each other
+ <pinotree> it isn't?
+ <youpi> well, try
+ * pinotree never did that
+ <youpi> but I don't think it will pose problem
+ <youpi> well, perhaps initialization order
+ <youpi> anyway, I now have packages built, I'll test that
+ <youpi> pinotree: ok, it seems it doesn't work indeed :)
+ <youpi> early in initialization
+ <youpi> pinotree: the initialization bug might actually not be due to librt
+ at all
+ <youpi> pinotree: yes, things work even with -lrt
+ <pinotree> 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
+
+ <pinotree> youpi: hm, thought about the pthread/stubs issue w/ dlopen'ed
+ libraries
+ <pinotree> currently looks like libstdc++ on hurd links to pthread-stubs,
+ we're the only one with such configuration
+ <pinotree> 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?
+ <youpi> that's expected
+ <youpi> on linux the libc provides hooks itself, on hurd-i386 it's
+ pthread-stubs
+ <pinotree> why not explicitly link to pthread though?
+ <youpi> because there is no strict need to, for applications that don't
+ need libpthread
+ <youpi> the dlopen case is a tricky case that pthread-stubs had not thought
+ about
+ <pinotree> hm
+ <pinotree> what if the pthread stubs would be moved in our glibc?
+ <youpi> that's what we should do yes
+ <youpi> (ideally)
+ <youpi> but for this we need to build libpthread along glibc, to get it
+ really working
+
+[[Packaging_libpthread]].
+
+ <youpi> and that's the tricky part (Makefile & such) which hasn't been done
+ yet
+ <pinotree> why both (stubs + actual libpthread)?
+ <youpi> because you need the stubs to be able to call the actual libpthread
+ <youpi> as soon libpthread gets dlopened for instance
+ <youpi> +as
+ <pinotree> i see
+ <youpi> (remember that nptl does this if you want to see how)
+ <youpi> (it's the libc files in nptl/)
+ <youpi> (and forward.c)
+ <guillem> 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?
+ <youpi> we don't _need_ to
+ <guillem> ok
+
+
+# IRC, OFTC, #debian-hurd, 2011-07-21
<youpi> there's one known issue with pthreads
<youpi> 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
+
+ <pinotree> interesting, glibc on every OS except hurd (so including linux
+ too) does not define O_EXEC
+ <pinotree> can somebody please help me understand a POSIX behaviour?
+ <pinotree> it's about fexecve:
+ http://pubs.opengroup.org/onlinepubs/9699919799/functions/fexecve.html
+ <pinotree> 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?
+ <pinotree> because currently libdiskfs and libnetfs require the fd to be
+ open with O_EXEC
+ <braunr> "Since execute permission is checked by fexecve(), the file
+ description fd need not have been opened with the O_EXEC flag"
+ <braunr> this one makes it clear checking for O_EXEC is wrong
+ <braunr> it looks like O_EXEC is only needed when you want to have files
+ for which only the execution permission is set
+ <braunr> but not the read one
+ <braunr> (i don't understand the "and write" part though)
+ <braunr> "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."
+ <braunr> this one strengthens the impression you have, that fexecve indeed
+ checks file permissions at the time it's called
+ <braunr> pinotree: hope it helps
+ <pinotree> so it implies the following:
+ <pinotree> O_RDONLY → exec works if the file is readable
+ <braunr> exec works if the file is readable and/or executable (although
+ without read permissions you can't check it)
+ <braunr> (well, fexecve)
+ <pinotree> O_EXEC → exec requires that the permission of the file at
+ fexecve() time have +x
+ <braunr> i'd say ye so far
+ <braunr> yes
+ <pinotree> so we need to fix lib{disk,net}fs then
+ <braunr> seems so
+ <pinotree> enlighting, merci braunr
+ <braunr> de rien
+ <pinotree> :)
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]]
- <tschwinge> My idea was to have a separate libpthread package. What do you think about that?
+
+# IRC, freenode, #hurd, 2010-07-31
+
+ <tschwinge> My idea was to have a separate libpthread package. What do you
+ think about that?
<youpi> in the long term, that can't work with glibc
<youpi> because of the thread stub stuff
@@ -21,30 +26,103 @@ IRC, #hurd, 2010-07-31
<youpi> it's not really possible to keep synchronized
<youpi> because you have to decide which package you unpack first
<youpi> (when upgrading)
- <tschwinge> 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?
+ <tschwinge> 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?
<tschwinge> ... for incompatible forward changes?
<youpi> that'd be a mess to maintain
- <youpi> Drepper doesn't have this constraint and thus adds members of private fields at will
- <tschwinge> OK, but how is it different then if the libpthread is in the Hurd package?
+ <youpi> Drepper doesn't have this constraint and thus adds members of
+ private fields at will
+ <tschwinge> OK, but how is it different then if the libpthread is in the
+ Hurd package?
<youpi> I'm not saying it's better to have libpthread in the Hurd package
<tschwinge> OK.
- <youpi> I'm saying it's useless to package it separately when Drepper makes everything to have us put it along glibc
+ <youpi> I'm saying it's useless to package it separately when Drepper makes
+ everything to have us put it along glibc
<tschwinge> Then, to goal is to have it in glibc?
<tschwinge> OK. :-)
- <tschwinge> OK, I can accommodate to that. Isn't not that we'd want to switch libpthread to something else so quickly.
- <tschwinge> So our official goal is to have libpthread in glibc, at least for Debian purposese?
+ <tschwinge> OK, I can accommodate to that. Isn't not that we'd want to
+ switch libpthread to something else so quickly.
+ <tschwinge> So our official goal is to have libpthread in glibc, at least
+ for Debian purposese?
<youpi> for any port purpose
<tschwinge> Ack.
- <youpi> provided you're using glibc, you're deemed to ship libpthread with it
+ <youpi> provided you're using glibc, you're deemed to ship libpthread with
+ it
<youpi> because of the strong relations Drepper puts between them
- <youpi> (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)
- <pinotree> yeah, pthread-stubs is linked to almost everywhere -lpthread isn't used
+ <youpi> (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)
+ <pinotree> yeah, pthread-stubs is linked to almost everywhere -lpthread
+ isn't used
<pinotree> (would be nice to not have those issues anymore...)
- <tschwinge> 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.)
- <tschwinge> Does that sound about right, or am I missing something fundamental?
+ <tschwinge> 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.)
+ <tschwinge> Does that sound about right, or am I missing something
+ fundamental?
<youpi> I actually don't know what a git submodule permits :)
<youpi> looks like a good thing for this, yes
- <tschwinge> Unfortunately I can't allocate much time at the moment to work on this. :-/
- <youpi> well, as long as I know where we're going, I can know how to package stuff in Debian
- <tschwinge> That sounds like a plan to me. libpthread -> glibc as submodule.
- <youpi> (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)
+ <tschwinge> Unfortunately I can't allocate much time at the moment to work
+ on this. :-/
+ <youpi> well, as long as I know where we're going, I can know how to
+ package stuff in Debian
+ <tschwinge> That sounds like a plan to me. libpthread -> glibc as
+ submodule.
+ <youpi> (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
+
+ <youpi> had you tried to build libpthread as a glibc addon?
+ <tschwinge> 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.
+ <youpi> k
+ <youpi> I'm trying it atm
+ <tschwinge> Oh, OK.
+ <youpi> that should fix the no-add-needed issue in gcc/binutils, as well as
+ the pthread_threads assertion errors in threaded plugins
+ <youpi> (once I add forward.c, but that part should not be hard)
+ <pinotree> that means also less use of pthread-stubs^
+ <pinotree> ?
+ <youpi> tschwinge: do you remember whether sysdeps/mach/bits/spin* are used
+ by anybody?
+ <youpi> they are half-finished (no __PTHREAD_SPIN_LOCK_INITIALIZER), and
+ come in the way when building in glibc
+ <youpi> also, any reason for using ia32 and not i386? glibc uses the latter
+ <youpi> pinotree: rid of pthread-stubs yes
+ <pinotree> \o/
+ <tschwinge> youpi: You mean sysdeps/mach/i386/machine-lock.h? No idea
+ about that one, sorry.
+ <youpi> I'm talking about libpthread
+ <youpi> not glibc
+ <tschwinge> Oh.
+ <tschwinge> sysdeps/ia32/bits/spin-lock.h:# define
+ __PTHREAD_SPIN_LOCK_INITIALIZER ((__pthread_spinlock_t) 0)
+ <tschwinge> Anyway, no idea about that either.
+ <youpi> that one is meant to be used with the spin-lock.h just below
+ <youpi> +-inline
+ <youpi> also, I guess signal/ was for the l4 port?
+ <tschwinge> youpi: I guess so.
+ <youpi> 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
+ <youpi> we don't have a non-mach sysdeps directory?
+ <pinotree> youpi: if you add sysdeps/mach/hurd/Implies containing only
+ "hurd", does sysdeps/hurd work?
+ <youpi> ah, right
+ <pinotree> youpi: did it work? (and, it was needed in sysdeps/mach/hurd, or
+ in libpthread/sysdeps/mach/hurd?)
+ <youpi> pinotree: it worked, it was for libpthread
+ <youpi> good: I got libpthread built and forward working
+
+
+## IRC, freenode, #hurd, 2012-04-23
+
+ <youpi> phew
+ <youpi> 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
<braunr> very simple examples: system calls use old call gates, which are
the slowest path to kernel space
<braunr> modern processors have dedicated instructions now
+
+
+# IRC, freenode, #hurd, 2012-04-22
+
+ <braunr> rah: basically, system calls are slower on mach because they use
+ call gates instead of newer sysenter/sysexit
+ <youpi> braunr: sysenter/exit is a x86_64 thing
+ <braunr> 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
+ <youpi> braunr: on a x86_64 port we'd probably use sysenter/exit
+ <braunr> 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 :)
+ <youpi> braunr: ah, the other part
+ <youpi> is linux-x86 using them?
+ <braunr> youpi: yes, glibc uses them
+ <youpi> and does it really change much nowadays?
+ <youpi> what is the actual difference between int 80 and sysenter?
+ <braunr> less checking
+ <youpi> checking what?
+ <youpi> the idt?
+ <braunr> ring levels for example
+ <youpi> well, checking a ring is fast :)
+ <braunr> depending on the original and requested levels, there are lookups
+ in tables
+ <braunr> sysenter always assume 3 to 0 and 0 to 3 for sysexit
+ <youpi> ah, also it assumes things about segments
+ <youpi> so that indeed makes context things simpler
+ <braunr> right
+ <braunr> but mach doesn't uses int 0x80
+ <braunr> it uses an lcall
+ <braunr> which is a bit slower from what I could read some time ago
+ <braunr> (not sure if it's still relevant)
+ <youpi> actually in 64bit mode I had to catch lcall from the invalid
+ instruction trap
+ <youpi> 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
+
+ <youpi> btw, remember the initrd thing?
+ <youpi> I just came across task.c in libstore/ :)
+
# Plan