From 9933cec0a18ae2a3d752f269d1bb12c19f51199d Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 21 Jul 2013 15:35:02 -0400 Subject: IRC. --- hurd/coding_style.mdwn | 59 +++++++++++ hurd/console/discussion.mdwn | 10 +- hurd/debugging.mdwn | 27 ++++++ hurd/debugging/rpctrace.mdwn | 4 + hurd/translator.mdwn | 2 + hurd/translator/auth.mdwn | 13 ++- hurd/translator/firmlink.mdwn | 14 ++- hurd/translator/netio.mdwn | 2 + hurd/translator/proc.mdwn | 53 ++++++++++ hurd/translator/procfs/jkoenig/discussion.mdwn | 20 ---- hurd/translator/socketio.mdwn | 30 ++++++ hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn | 129 ++++++++++++++++++++++++- 12 files changed, 337 insertions(+), 26 deletions(-) create mode 100644 hurd/coding_style.mdwn create mode 100644 hurd/translator/proc.mdwn create mode 100644 hurd/translator/socketio.mdwn (limited to 'hurd') diff --git a/hurd/coding_style.mdwn b/hurd/coding_style.mdwn new file mode 100644 index 00000000..cc1e3cf3 --- /dev/null +++ b/hurd/coding_style.mdwn @@ -0,0 +1,59 @@ +[[!meta copyright="Copyright © 2013 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_documentation]] + +Some coding style comments that are specific to Hurd systems. + +[[!toc]] + + +# Freeing Port Rights + +## IRC, freenode, #hurd, 2013-07-01 + + do I have to explicitly free ports in a short lived process like + mount? + better take the habit of doing that anyway + how do I recognize that I have to free something? mig spec? + i'd say no + mig does it for you + gnumach reference manual + not memory, like port rights + but no, really, for short lived processes it's ok + yes, port rights + like memory, you don't free stuff in short lived processes :p + mach does it correctly when the task is destroyed + but there are two use cases for rights + those you create manually + and those mig creates for its own purpose + ignore those used by mig, they matter only in very specific parts + of glibc and other very low level stuff + teythoon: keep in mind that there are two flavours of resources + with port rights + but how do I *know* from looking at say fs.defs that I have to + free anything I get? + rights themselves, and the user reference count per right + eh, that's complicated + in a complete RPC call, you must watch two things usually + out of line memory + and right references + except otherwise mentioned, you don't have to free anything + freeing passed memory should be obvious (e.g. "out" keyword on a + memory range) + for right references, it's less obvious + refer to the mach server writing guide i guess + what does the dealloc qualifier do in mig defs? + basically, send rights can be created from a receive right + (make_send), or another send right (copy_send) + it tells mig which function to call once an RPC has returned + all this is described in the mach server writing guide + and it's tricky + quite error-prone so check with portinfo diff --git a/hurd/console/discussion.mdwn b/hurd/console/discussion.mdwn index f887d826..0022ec23 100644 --- a/hurd/console/discussion.mdwn +++ b/hurd/console/discussion.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2012, 2013 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -10,6 +10,8 @@ License|/fdl]]."]]"""]] [[!tag open_issue_documentation]] +[[!toc]] + # IRC, OFTC, #debian-hurd, 2012-09-24 @@ -40,3 +42,9 @@ License|/fdl]]."]]"""]] hacking? to fix that is… some hacking yes + + +# IRC, freenode, #hurd, 2013-07-10 + + http://xkbcommon.org/ ‘¡û sounds interesting for our console + translator diff --git a/hurd/debugging.mdwn b/hurd/debugging.mdwn index f4b5eba5..ae9b7bef 100644 --- a/hurd/debugging.mdwn +++ b/hurd/debugging.mdwn @@ -26,3 +26,30 @@ License|/fdl]]."]]"""]] * [[glibc]] * [[translator]]s * [[trap_in_the_kernel]] + + +# IRC, freenode, #hurd, 2013-06-30 + + braunr: I don't understand your question totally, but I want to + know how do you do this inspecting? i have a small test program + that creates a thread, and inspect its state before any thread dies + i use portinfo + and rpctrace + (there is also vminfo but you're not likely to need it for what + you're doing right now) + I have used rpctrace before, but portinfo, I will try it. + is portinfo show a process's all port use log? + not log + current state + dump the port name space? + yes + I found some names are not continuous. how this come out? + continuous ? + 101:send 103:send + missing 102 + some are freed + a lot actually + every RPC needs a reply port + a temporary receive right to get replies from servers + so we can reuse the name which are freed before + of course diff --git a/hurd/debugging/rpctrace.mdwn b/hurd/debugging/rpctrace.mdwn index a5c1a6e9..1570df4c 100644 --- a/hurd/debugging/rpctrace.mdwn +++ b/hurd/debugging/rpctrace.mdwn @@ -182,6 +182,10 @@ See `rpctrace --help` about how to use it. uhu, there's a TODO just above that assertion :) +* IRC, freenode, #hurd, 2013-07-05 + + wish: make rpctrace decode the results of io_stat rpcs + # See Also diff --git a/hurd/translator.mdwn b/hurd/translator.mdwn index d4eaf950..37dac794 100644 --- a/hurd/translator.mdwn +++ b/hurd/translator.mdwn @@ -90,6 +90,7 @@ The [[concept|concepts]] of translators creates its own problems, too: * [[hello]] * [[auth]] * [[exec]] +* [[proc]] * [[pfinet]] * [[pflocal]] * [[hostmux]] @@ -112,6 +113,7 @@ The [[concept|concepts]] of translators creates its own problems, too: * [[procfs]] * [[nsmux]] * [[netio]] +* [[socketio]] * [[tarfs]] * [[gopherfs]] * [[smbfs]] diff --git a/hurd/translator/auth.mdwn b/hurd/translator/auth.mdwn index d9e70ec2..7fd4832c 100644 --- a/hurd/translator/auth.mdwn +++ b/hurd/translator/auth.mdwn @@ -1,12 +1,19 @@ -[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2013 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +The *auth server* (or, *authentification server*). + +It is stated by `/hurd/init`. + + +# Documentation [[*The_Authentication_Server*|documentation/auth]], the transcript of a talk about the details of the authentication mechanisms in the Hurd by Wolfgang diff --git a/hurd/translator/firmlink.mdwn b/hurd/translator/firmlink.mdwn index 038879db..b53396b0 100644 --- a/hurd/translator/firmlink.mdwn +++ b/hurd/translator/firmlink.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2012, 2013 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -20,3 +20,15 @@ License|/fdl]]."]]"""]] infinity0: firmlinks ah thanks i'll look that up braunr: oh, true, I forgot about that one + + +# Open Issues + + * [[!GNU_Savannah_bug 29809]] + + * IRC, freenode, #hurd, 2013-07-07 + + ok, found the firmlink-mv issue + will commit that + \o/ + (bit of mach_print in translators, took just a few hours) diff --git a/hurd/translator/netio.mdwn b/hurd/translator/netio.mdwn index 44c35cf1..429072d4 100644 --- a/hurd/translator/netio.mdwn +++ b/hurd/translator/netio.mdwn @@ -11,6 +11,8 @@ License|/fdl]]."]]"""]] `netio` is a translator designed for creating socket ports through the filesystem. +See also [[socketio]]. + # Source diff --git a/hurd/translator/proc.mdwn b/hurd/translator/proc.mdwn new file mode 100644 index 00000000..98940f87 --- /dev/null +++ b/hurd/translator/proc.mdwn @@ -0,0 +1,53 @@ +[[!meta copyright="Copyright © 2012, 2013 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +The *proc server* (or, *process server*) implements some aspects of [[Unix]] +processes. + +It is stated by `/hurd/init`. + + +# "Unusual" PIDs + +[[!tag open_issue_hurd]] + + +## IRC, freenode, #hurd, 2012-08-10 + + too bad the proc server has pid 0 + top & co won't show it + + +## IRC, OFTC, #debian-hurd, 2012-09-18 + + youpi: did you see + https://enc.com.au/2012/09/careful-with-pids/' + ? + nope + + +## IRC, OFTC, #debian-hurd, 2013-06-23 + + I've got this idea about the pid 1 issue you mentioned + can't we just make init pid 1? + I mean the mapping is rather arbitrary, we could make our init + pid 2 or something and start sysvs init as pid 1 + not totally sure it is that arbitrary up to the first 4-5 pids + y is that? + at least i see in hurd's code that /hurd/init is assumed as + pid=1 + hurds init that has to stick around for the fs translator sync? + hurd's init does the basic server startup + iirc it also takes care of shutdown/reboot + that's what I meant + and if it wouldn't have to stick around for the translator sync + it could just exec sysvinit + I just think it's easier to patch hurd than to remove the + assumption that init is pid 1 from sysvinit diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn index 197461b8..fcda453e 100644 --- a/hurd/translator/procfs/jkoenig/discussion.mdwn +++ b/hurd/translator/procfs/jkoenig/discussion.mdwn @@ -441,26 +441,6 @@ Needed by glibc's `pldd` tool (commit on "internal" (but exported) glibc functions -# "Unusual" PIDs - -Not actually related to procfs, but here seems to be a convenient place for -filing these: - - -## IRC, freenode, #hurd, 2012-08-10 - - too bad the proc server has pid 0 - top & co won't show it - - -## IRC, OFTC, #debian-hurd, 2012-09-18 - - youpi: did you see - https://enc.com.au/2012/09/careful-with-pids/' - ? - nope - - # CPU Usage ## IRC, freenode, #hurd, 2013-01-30 diff --git a/hurd/translator/socketio.mdwn b/hurd/translator/socketio.mdwn new file mode 100644 index 00000000..479d5749 --- /dev/null +++ b/hurd/translator/socketio.mdwn @@ -0,0 +1,30 @@ +[[!meta copyright="Copyright © 2010, 2013 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +`socketio` is a translator designed for creating socket ports through the +filesystem. + +See also [[netio]]. + + +# IRC, freenode, #hurd, 2013-06-30 + + http://lists.gnu.org/archive/html/bug-hurd/2003-05/msg00069.html + this was supposed to be much better than our current netio + (which doesn't really have any documentation btw) + + http://web.archive.org/web/20060117085538/http://duesseldorf.ccc.de/~moritz/files/socketio.c.gz + youpi: socketio looks nice. any reason in particular why you are + working on it? + teythoon: I was looking at the firewall stuff, and wondering about + Zheng Da's work, and seen netio, thus wondered "what is it about + already?" and found there was no documentation, so dug into the mailing + list archives, only to find it was supposed to be precated in favour of + socketio, etc. :) diff --git a/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn b/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn index 5228515f..16a23405 100644 --- a/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn +++ b/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011, 2013 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -270,3 +271,129 @@ See also: [[open_issues/resource_management_problems/pagers]]. only problem is that the current defpager implementation can't really handle that... at least that's my understanding of the situation + + +# IRC, freenode, #hurd, 2013-07-05 + + btw, why does the tmpfs translator have to talk to the pager? + to get more control about how the memory is paged out? + read lot's of irc logs about tmpfs on the wiki, but I couldn't + find the answer to that + teythoon: did you read this? + http://www.gnu.org/software/hurd/hurd/translator/tmpfs/tmpfs_vs_defpager.html + mcsim: I did + teythoon: Last discussion, i think has very good point. + To provide memory objects you should implement pager interface + And if you implement pager interface you are the one who is asked + to write data to backing storage to evict them + But tmpfs doesn't do this + mmm, clients doing mmap... + teythoon: You don't have mmap + teythoon: mmap is implemented on top of mach interface + teythoon: I mean you don't have mmap at this level + mcsim: sure, but that's close enough for me at this point + teythoon: diskfs interface requires implementor to provide a memory + object port (send right) + Guest8183: Why tmpfs requires defpager + how did you get to talk about that ? + I was just asked + Guest8183: it's just so unsettling that tmpfs has to be started + as root :/ + teythoon: why ? + *** Guest8183 (~rbraun@dalaran.sceen.net) is now known as braunr_ + braunr_: b/c starting translators isn't a privileged operation, + and starting a tmpfs translator that doesn't even access any device but + "just" memory shouldn't require any special privileges as well imho + so why is tmpfs not based on say libnetfs? b/c it is used for + d-i and someone (apt?) mmaps stuff? + being libdiskfs-based isn't much the issue, iirc + http://lists.gnu.org/archive/html/bug-hurd/2013-03/msg00014.html + too + teythoon: AFAIK apt uses mmap, yes + teythoon: right + a ramfs is actually tricky to implement well + braunr_: What do you mean under "to implement well"? + as efficiently as possible + i.e. being as close as possible to the page cache for minimum + overhead + braunr: AFAIK ramfs should not use swap partition, so page cache + shouldn't be relevant for it. + i'm talking about a ramfs in general + not the specific linux ramfs + in linux, what they call ramfs is the tiny version of tmpfs that + doesn't use swap + i actually don't like "tmpfs" much + memfs may be more appropriate + anyway + braunr: I see. And do you consider defpager variant as "close as + possible to the page cache"? + not far at least + if we were able to use it for memory obects, it would be nice + but defpager only gets attached to objects when they're evicted + before that, anonymous (or temporary, in mach terminology) objects + have no backing store + this was probably designed without having tmpfs in mind + i wonder if it's possible to create a memory object without a + backing store + what should happen to it if kernel decides to evict it? + it sets the default pager as its backing store and pushes it out + that's how it works now, but you said "create a memory object + without a backing store" + mach can do that + i was wondering if we could do that too from userspace + mach does not evict such objects, unless it bound a defpager to + them + but how can you handle this in userspace? + i mean, create a memory object with a null control port + mcsim: is that clearer ? + suppose you create such object, how kernel will evict it if kernel + does not know who is responsible for eviction of this object? + it does + 16:41 < braunr> it sets the default pager as its backing store and + pushes it out + that's how i intend to do it on x15 at least + but it's much simpler there because uvm provides better separation + between anonymous and file memory + whereas they're much too similar in mach vm + than what the difference between current situation, when you + explicitly invoke defpager to create object and implicit method you + propose? + you don't need a true defpager unless you actually have swap + ok + now I see + it also saves the communication overhead when initializing the + object + thank you + which may be important since we use ramfs for speed mostly + agree + it should also simplify the defpager implementation, since it + would only have a single client, the kernel + which may also be important with regard to global design + one thing which is in my opinion very wrong with mach is that it + may be a client + a well designed distributed system should normally not allow on + component to act as both client and server toward another + i.e. the kernel should only be a server, not a client + and there should be a well designed server hierarchy to avoid + deadlocks + (such as the one we had in libpager because of that) + And how about filesystem? It acts both as server and as client + yes + but not towards the same other component + application -> file system -> kernel + no "<->" + the qnx documentation explains that quite well + let me see if i can find the related description + Basically, I've got your point. And I would rather agree that + kernel should not act as client + mcsim: + http://www.qnx.com/developers/docs/6.4.0/neutrino/sys_arch/ipc.html#Robust + one way to implement that (and qnx does that too) is to make + pagers act as client only + they sleep in the kernel, waiting for a reply + and when the kernel needs to evict something, a reply is sent + (qnx doesn't actually do that for paging, but it's a general idea) + braunr: how hierarchy of senders is enforced? + it's not + developers must take care + same as locking, be careful about it -- cgit v1.2.3