summaryrefslogtreecommitdiff
path: root/hurd/translator
diff options
context:
space:
mode:
Diffstat (limited to 'hurd/translator')
-rw-r--r--hurd/translator/auth.mdwn13
-rw-r--r--hurd/translator/firmlink.mdwn14
-rw-r--r--hurd/translator/netio.mdwn2
-rw-r--r--hurd/translator/proc.mdwn53
-rw-r--r--hurd/translator/procfs/jkoenig/discussion.mdwn20
-rw-r--r--hurd/translator/socketio.mdwn30
-rw-r--r--hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn129
7 files changed, 236 insertions, 25 deletions
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]]."]]"""]]
<braunr> infinity0: firmlinks
<infinity0> ah thanks i'll look that up
<kilobug> braunr: oh, true, I forgot about that one
+
+
+# Open Issues
+
+ * [[!GNU_Savannah_bug 29809]]
+
+ * IRC, freenode, #hurd, 2013-07-07
+
+ <youpi> ok, found the firmlink-mv issue
+ <youpi> will commit that
+ <pinotree> \o/
+ <youpi> (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
+
+ <braunr> too bad the proc server has pid 0
+ <braunr> top & co won't show it
+
+
+## IRC, OFTC, #debian-hurd, 2012-09-18
+
+ <pinotree> youpi: did you see
+ https://enc.com.au/2012/09/careful-with-pids/'
+ <pinotree> ?
+ <youpi> nope
+
+
+## IRC, OFTC, #debian-hurd, 2013-06-23
+
+ <teythoon> I've got this idea about the pid 1 issue you mentioned
+ <teythoon> can't we just make init pid 1?
+ <teythoon> I mean the mapping is rather arbitrary, we could make our init
+ pid 2 or something and start sysvs init as pid 1
+ <pinotree> not totally sure it is that arbitrary up to the first 4-5 pids
+ <teythoon> y is that?
+ <pinotree> at least i see in hurd's code that /hurd/init is assumed as
+ pid=1
+ <teythoon> hurds init that has to stick around for the fs translator sync?
+ <pinotree> hurd's init does the basic server startup
+ <pinotree> iirc it also takes care of shutdown/reboot
+ <teythoon> that's what I meant
+ <teythoon> and if it wouldn't have to stick around for the translator sync
+ it could just exec sysvinit
+ <teythoon> 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
-
- <braunr> too bad the proc server has pid 0
- <braunr> top & co won't show it
-
-
-## IRC, OFTC, #debian-hurd, 2012-09-18
-
- <pinotree> youpi: did you see
- https://enc.com.au/2012/09/careful-with-pids/'
- <pinotree> ?
- <youpi> 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
+
+ <youpi> http://lists.gnu.org/archive/html/bug-hurd/2003-05/msg00069.html
+ <youpi> this was supposed to be much better than our current netio
+ <youpi> (which doesn't really have any documentation btw)
+ <teythoon>
+ http://web.archive.org/web/20060117085538/http://duesseldorf.ccc.de/~moritz/files/socketio.c.gz
+ <teythoon> youpi: socketio looks nice. any reason in particular why you are
+ working on it?
+ <youpi> 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]].
<antrik> only problem is that the current defpager implementation can't
really handle that...
<antrik> at least that's my understanding of the situation
+
+
+# IRC, freenode, #hurd, 2013-07-05
+
+ <teythoon> btw, why does the tmpfs translator have to talk to the pager?
+ <teythoon> to get more control about how the memory is paged out?
+ <teythoon> read lot's of irc logs about tmpfs on the wiki, but I couldn't
+ find the answer to that
+ <mcsim> teythoon: did you read this?
+ http://www.gnu.org/software/hurd/hurd/translator/tmpfs/tmpfs_vs_defpager.html
+ <teythoon> mcsim: I did
+ <mcsim> teythoon: Last discussion, i think has very good point.
+ <mcsim> To provide memory objects you should implement pager interface
+ <mcsim> And if you implement pager interface you are the one who is asked
+ to write data to backing storage to evict them
+ <mcsim> But tmpfs doesn't do this
+ <teythoon> mmm, clients doing mmap...
+ <mcsim> teythoon: You don't have mmap
+ <mcsim> teythoon: mmap is implemented on top of mach interface
+ <mcsim> teythoon: I mean you don't have mmap at this level
+ <teythoon> mcsim: sure, but that's close enough for me at this point
+ <mcsim> teythoon: diskfs interface requires implementor to provide a memory
+ object port (send right)
+ <mcsim> Guest8183: Why tmpfs requires defpager
+ <Guest8183> how did you get to talk about that ?
+ <mcsim> I was just asked
+ <teythoon> Guest8183: it's just so unsettling that tmpfs has to be started
+ as root :/
+ <Guest8183> teythoon: why ?
+ *** Guest8183 (~rbraun@dalaran.sceen.net) is now known as braunr_
+ <teythoon> 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
+ <teythoon> so why is tmpfs not based on say libnetfs? b/c it is used for
+ d-i and someone (apt?) mmaps stuff?
+ <pinotree> being libdiskfs-based isn't much the issue, iirc
+ <pinotree> http://lists.gnu.org/archive/html/bug-hurd/2013-03/msg00014.html
+ too
+ <kilobug> teythoon: AFAIK apt uses mmap, yes
+ <braunr_> teythoon: right
+ <braunr_> a ramfs is actually tricky to implement well
+ <mcsim> braunr_: What do you mean under "to implement well"?
+ <braunr_> as efficiently as possible
+ <braunr_> i.e. being as close as possible to the page cache for minimum
+ overhead
+ <mcsim> braunr: AFAIK ramfs should not use swap partition, so page cache
+ shouldn't be relevant for it.
+ <braunr> i'm talking about a ramfs in general
+ <braunr> not the specific linux ramfs
+ <braunr> in linux, what they call ramfs is the tiny version of tmpfs that
+ doesn't use swap
+ <braunr> i actually don't like "tmpfs" much
+ <braunr> memfs may be more appropriate
+ <braunr> anyway
+ <mcsim> braunr: I see. And do you consider defpager variant as "close as
+ possible to the page cache"?
+ <braunr> not far at least
+ <braunr> if we were able to use it for memory obects, it would be nice
+ <braunr> but defpager only gets attached to objects when they're evicted
+ <braunr> before that, anonymous (or temporary, in mach terminology) objects
+ have no backing store
+ <braunr> this was probably designed without having tmpfs in mind
+ <braunr> i wonder if it's possible to create a memory object without a
+ backing store
+ <mcsim> what should happen to it if kernel decides to evict it?
+ <braunr> it sets the default pager as its backing store and pushes it out
+ <mcsim> that's how it works now, but you said "create a memory object
+ without a backing store"
+ <braunr> mach can do that
+ <braunr> i was wondering if we could do that too from userspace
+ <mcsim> mach does not evict such objects, unless it bound a defpager to
+ them
+ <mcsim> but how can you handle this in userspace?
+ <braunr> i mean, create a memory object with a null control port
+ <braunr> mcsim: is that clearer ?
+ <mcsim> suppose you create such object, how kernel will evict it if kernel
+ does not know who is responsible for eviction of this object?
+ <braunr> it does
+ <braunr> 16:41 < braunr> it sets the default pager as its backing store and
+ pushes it out
+ <braunr> that's how i intend to do it on x15 at least
+ <braunr> but it's much simpler there because uvm provides better separation
+ between anonymous and file memory
+ <braunr> whereas they're much too similar in mach vm
+ <mcsim> than what the difference between current situation, when you
+ explicitly invoke defpager to create object and implicit method you
+ propose?
+ <braunr> you don't need a true defpager unless you actually have swap
+ <mcsim> ok
+ <mcsim> now I see
+ <braunr> it also saves the communication overhead when initializing the
+ object
+ <mcsim> thank you
+ <braunr> which may be important since we use ramfs for speed mostly
+ <mcsim> agree
+ <braunr> it should also simplify the defpager implementation, since it
+ would only have a single client, the kernel
+ <braunr> which may also be important with regard to global design
+ <braunr> one thing which is in my opinion very wrong with mach is that it
+ may be a client
+ <braunr> a well designed distributed system should normally not allow on
+ component to act as both client and server toward another
+ <braunr> i.e. the kernel should only be a server, not a client
+ <braunr> and there should be a well designed server hierarchy to avoid
+ deadlocks
+ <braunr> (such as the one we had in libpager because of that)
+ <mcsim> And how about filesystem? It acts both as server and as client
+ <braunr> yes
+ <braunr> but not towards the same other component
+ <braunr> application -> file system -> kernel
+ <braunr> no "<->"
+ <braunr> the qnx documentation explains that quite well
+ <braunr> let me see if i can find the related description
+ <mcsim> Basically, I've got your point. And I would rather agree that
+ kernel should not act as client
+ <braunr> mcsim:
+ http://www.qnx.com/developers/docs/6.4.0/neutrino/sys_arch/ipc.html#Robust
+ <braunr> one way to implement that (and qnx does that too) is to make
+ pagers act as client only
+ <braunr> they sleep in the kernel, waiting for a reply
+ <braunr> and when the kernel needs to evict something, a reply is sent
+ <braunr> (qnx doesn't actually do that for paging, but it's a general idea)
+ <mcsim> braunr: how hierarchy of senders is enforced?
+ <braunr> it's not
+ <braunr> developers must take care
+ <braunr> same as locking, be careful about it