Merge remote-tracking branch 'fp/master'

Conflicts:
	open_issues/dbus.mdwn

1 files changed, 145 insertions, 1 deletions

diff --git a/open_issues/anatomy_of_a_hurd_system.mdwn b/open_issues/anatomy_of_a_hurd_system.mdwn
index 13599e19..99ef170b 100644
--- a/open_issues/anatomy_of_a_hurd_system.mdwn
+++ b/open_issues/anatomy_of_a_hurd_system.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
@@ -122,3 +122,147 @@ IRC, OFTC, #debian-hurd, 2011-11-02:
       system (via libdiskfs).
     <tschwinge> sekon_: This may help a bit:
       http://www.gnu.org/software/hurd/hurd/hurd_hacking_guide.html
+
+---
+
+IRC, freenode, #hurd, 2012-01-08:
+
+    <abique> can you tell me how is done in hurd:  "ls | grep x" ?
+    <abique> in bash
+    <youpi> ls's standard output is a port to the pflocal server, and grep x's
+      standard input is a port to the pflocal server
+    <youpi> the connexion between both ports inside the pflocal server being
+      done by bash when it calls pipe()
+    <abique> youpi, so STDOUT_FILENO, STDIN_FILENO, STDERR_FILENO still exists
+      ?
+    <youpi> sure, hurd is compatible with posix
+    <abique> so bash 1) creates T1 (ls) and T2 (grep), then create a pipe at
+      the pflocal server, then connects both ends to T1 and T2, then start(T1),
+      start(T2) ?
+    <youpi> not exactly
+    <youpi> it's like on usual unix, bash creates the pipe before creating the
+      tasks
+    <youpi> then forks to create both of them, handling them each side of the
+      pipe
+    <abique> ok I see
+    <youpi> s/handling/handing/
+    <abique> but when you do pipe() on linux, it creates a kernel object, this
+      time it's 2 port on the pflocal ?
+    <youpi> yes
+    <abique> how are spawned tasks ?
+    <abique> with fork() ?
+    <youpi> yes
+    <youpi> which is just task_create() and duplicating the ports into the new
+      task
+    <abique> ok
+    <abique> so it's easy to rewrite fork() with a good control of duplicated
+      fd
+    <abique> about threading, mutexes, conditions, etc.. are kernel objects or
+      just userland objects ?
+    <youpi> just ports
+    <youpi> (only threads are kernel objects)
+    <abique> so, about efficiency, are pipes and mutexes efficient ?
+    <youpi> depends what you call "efficient"
+    <youpi> it's less efficient than on linux, for sure
+    <youpi> but enough for a workable system
+    <abique> maybe hurd is the right place for a userland thread library like
+      pth or any fiber library
+    <abique> ?
+    <youpi> hurd already uses a userland thread library
+    <youpi> libcthreads
+    <abique> is it M:N ?
+    <youpi> libthreads, actually
+    <youpi> yes
+    <abique> nice
+    <abique> is the task scheduler in the kernel ?
+    <youpi> the kernel thread scheduler, yes, of course
+    <youpi> there has to be one
+    <abique> are the posix open()/readdir()/etc... the direct vfs or wraps an
+      hurd layer libvfs ?
+    <youpi> they wrap RPCs to the filesystem servers
+    <antrik> the Bushnell paper is probably the closest we have to a high-level
+      documentation of these concepts...
+    <antrik> the Hurd does not have a central VFS component at all. name
+      lookups are performed directly on the individual FS servers
+    <antrik> that's probably the most fundamental design feature of the Hurd
+    <antrik> (all filesystem operations actually, not only lookups)
+
+IRC, freenode, #hurd, 2012-01-09:
+
+    <braunr> youpi: are you sure cthreads are M:N ? i'm almost sure they're 1:1
+    <braunr> and no modern OS is a right place for any thread userspace
+      library, as they wouldn't have support to run threads on different
+      processors (unless processors can be handled by userspace servers, but
+      still, it requires intimate cooperation between the threading library and
+      the kernel/userspace server in any case
+    <youpi> braunr: in libthreads, they are M:N
+    <youpi> you can run threads on different processors by using several kernel
+      threads, there's no problem in there, a lot of projects do this
+    <braunr> a pure userspace library can't use kernel threads
+    <braunr> at least pth was explacitely used on systems like bsd at a time
+      when they didn't have kernel threads exactly for that reason
+    <braunr> explicitely*
+    <braunr> and i'm actually quite surprised to learn that we have an M:N
+      threading model :/
+    <youpi> why do you say "can't" ?
+    <braunr> but i wanted to reply to abique and he's not around
+    <youpi> of course you need kernel threads
+    <youpi> but all you need is to bind them
+    <braunr> well, what i call a userspace threading library is a library that
+      completely implement threads without the support of the kernel
+    <braunr> or only limited support, like signals
+    <youpi> errr, you can't implement anything with absolutely no support of
+      the kernel
+    <braunr> pth used only SIGALRM iirc
+    <youpi> asking for more kernel threads to use more processors doesn't seem
+      much
+    <braunr> it's not
+    <braunr> but i'm refering to what abique said
+    <braunr> 01:32 < abique> maybe hurd is the right place for a userland
+      thread library like pth or any fiber library
+    <youpi> well, it's indeed more, because the glibc lets external libraries
+      provide their mutex
+    <youpi> while on linux, glibc doesn't
+    <braunr> i believe he meant removing thread support from the kernel :p
+    <youpi> ah
+    <braunr> and replying "nice" to an M:N threading model is also suspicious,
+      since experience seems to show 1:1 models are better
+    <youpi> "better" ????
+    <braunr> yes
+    <youpi> well
+    <youpi> I don't have any time to argue  about that
+    <youpi> because that'd be extremely long
+    <braunr> simpler, so far less bugs, and also less headache concerning posix
+      conformance
+    <youpi> but there's no absolute "better" here
+    <youpi> but less performant
+    <youpi> less flexible
+    <braunr> that's why i mention experience :)
+    <youpi> I mean experience too
+    <braunr> why less performant ?
+    <youpi> because you pay kernel transition
+    <youpi> because you don't know anything about the application threads
+    <youpi> etc.
+    <braunr> really ?
+    <youpi> yes
+    <braunr> i fail to see where the overhead is
+    <youpi> I'm not saying m:n is generally better than 1:1 either
+    <youpi> thread switch, thread creation, etc.
+    <braunr> creation is slower, i agree, but i'm not sure it's used frequently
+      enough to really matter
+    <youpi> it is sometimes used frequently enough
+    <youpi> and in those cases it would be a headache to avoid it
+    <braunr> ok
+    <braunr> i thought thread pools were used in those cases
+    <youpi> synchronized with kernel mutexes ?
+    <youpi> that's still slow
+    <braunr> it reduces to the thread switch overhead
+    <braunr> which, i agree is slightly slower
+    <braunr> ok, i's a bit less performant :)
+    <braunr> well don't futexes exist just for that too ?
+    <youpi> yes and no
+    <youpi> in that case they don't help
+    <youpi> because they do sleep
+    <youpi> they help only when the threads are living
+    <braunr> ok
+    <youpi> now as I said I don't have to talk much more, I have to leave :)