diff options
Diffstat (limited to 'open_issues/anatomy_of_a_hurd_system.mdwn')
| -rw-r--r-- | open_issues/anatomy_of_a_hurd_system.mdwn | 146 |
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 :) |