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/eth-filter.mdwn37
-rw-r--r--hurd/translator/examples.mdwn8
-rw-r--r--hurd/translator/exec.mdwn8
-rw-r--r--hurd/translator/ext2fs.mdwn63
-rw-r--r--hurd/translator/fifo.mdwn48
-rw-r--r--hurd/translator/firmlink.mdwn14
-rw-r--r--hurd/translator/hostmux.mdwn15
-rw-r--r--hurd/translator/httpfs.mdwn100
-rw-r--r--hurd/translator/netio.mdwn7
-rw-r--r--hurd/translator/nsmux.mdwn27
-rw-r--r--hurd/translator/pfinet.mdwn9
-rw-r--r--hurd/translator/pfinet/implementation.mdwn167
-rw-r--r--hurd/translator/pflocal.mdwn28
-rw-r--r--hurd/translator/proc.mdwn75
-rw-r--r--hurd/translator/procfs/jkoenig/discussion.mdwn177
-rw-r--r--hurd/translator/socketio.mdwn27
-rw-r--r--hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn129
-rw-r--r--hurd/translator/ufs.mdwn38
19 files changed, 925 insertions, 65 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/eth-filter.mdwn b/hurd/translator/eth-filter.mdwn
index 36ef4217..b5dc8f8f 100644
--- a/hurd/translator/eth-filter.mdwn
+++ b/hurd/translator/eth-filter.mdwn
@@ -8,20 +8,45 @@ 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]]."]]"""]]
-`eth-filter` is a translator that implements a very simple stateless firewal.
+`eth-filter` is a translator that implements a very simple stateless firewall.
+
# Source
[[source_repositories/incubator]], dde
-# Usage:
+
+# Usage
For instance, to drop any attempt to access port 22:
- settrans -c /dev/eth0f /hurd/eth-filter -i /dev/eth0 -r "not port 22"
+ # settrans -c /dev/eth0f /hurd/eth-filter -i /dev/eth0 -r "not port 22"
+
+This creates a `/dev/eth0f` device, which is the filtered version of
+`/dev/eth0`. One can then use `/dev/eth0f` instead of `/dev/eth0`:
+
+ # settrans /servers/socket/2 /hurd/pfinet -i /dev/eth0f [...]
+
+..., or run `dhclient /dev/eth0f`, or similar.
+
+See also Zheng Da's [[user/zhengda/howto]].
+
+
+# Open Issues
-This creates a /dev/eth0f device, which is the filtered version of /dev/eth0. One can then configure network by hand using /dev/eth0f instead of /dev/eth0:
+## IRC, freenode, #hurd, 2013-07-27
- settrans /servers/socket/2 /hurd/pfinet -i /dev/eth0f ...
+[[!tag open_issue_hurd]]
-or run dhclient /dev/eth0f, etc.
+ <youpi> ok, so as usual we actually *already* have a firewall
+ <youpi> it's the eth-filter translator from zheng da
+ <youpi> it has just never been really pushed forward...
+ <teythoon> good news :)
+ <youpi> well, the bad news is that it probably doesn't support connection
+ tracking
+ <youpi> since it's just bpf
+ <youpi> using the libpcap syntax
+ <teythoon> well, a stateless fw should do for Debian/Hurds needs for now,
+ right?
+ <youpi> yes
+ <youpi> and it does work indeed
diff --git a/hurd/translator/examples.mdwn b/hurd/translator/examples.mdwn
index 867d4935..4947808e 100644
--- a/hurd/translator/examples.mdwn
+++ b/hurd/translator/examples.mdwn
@@ -16,7 +16,7 @@ or [hurd-extras](http://www.nongnu.org/hurdextras/).
cvs -z3 -d:pserver:anonymous@cvs.savannah.nongnu.org:/sources/hurdextras co <modulename>
-* httpfs translator
+* [[httpfs]] translator
<!-- Prevent ikiwiki / Markdown rendering bug. -->
@@ -28,7 +28,7 @@ or
$ cd tmp/
$ ls -l
-* ftpfs translator
+* [[ftpfs]] translator
<!-- Prevent ikiwiki / Markdown rendering bug. -->
@@ -67,13 +67,13 @@ This is not as fast as `tar czvf newfile.tar.gz all my files`, but at least it's
$ settrans -fgca /servers/socket/2 /hurd/pfinet -i <interface> -a <ip address> -m <subnet mask> -g <gateway ip>
-* Console translator -- setting up virtual consoles
+* [[Console]] translator -- setting up virtual consoles
<!-- Prevent ikiwiki / Markdown rendering bug. -->
$ console -d vga -d pc_mouse -d pc_kbd -d generic_speaker /dev/vcs
-* iso9660fs translator -- 'mounting' your cdrom
+* [[iso9660fs]] translator -- 'mounting' your cdrom
<!-- Prevent ikiwiki / Markdown rendering bug. -->
diff --git a/hurd/translator/exec.mdwn b/hurd/translator/exec.mdwn
index 54abba7e..1dc0ea26 100644
--- a/hurd/translator/exec.mdwn
+++ b/hurd/translator/exec.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2009, 2012 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2009, 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
@@ -11,4 +12,9 @@ License|/fdl]]."]]"""]]
The *exec* server, listening on `/servers/exec`, is responsible for
preparing the execution of processes.
+
+# Open Issues
+
+ * [[open_issues/exec]].
+
* [[open_issues/exec_memory_leaks]].
diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn
index 20faed5e..e2f6b044 100644
--- a/hurd/translator/ext2fs.mdwn
+++ b/hurd/translator/ext2fs.mdwn
@@ -179,6 +179,69 @@ small backend stores, like floppy devices.
That would be a nice improvement, but only after writeback throttling is implemented.
+## Stripped vs. Unstripped `ext2fs.static`
+
+[[!tag open_issue_hurd]]
+
+
+### IRC, freenode, #hurd, 2013-09-17
+
+ <teythoon> I always had some trouble with dropping a rebuild ext2fs.static
+ into my test system and I never figured out why
+ <teythoon> I just followed a hunch and stripped the binary, and all of the
+ sudden it works
+ <teythoon> any ideas why?
+ <tschwinge> teythoon: I quick search found me:
+ <https://savannah.gnu.org/bugs/?8497> and
+ <http://news.gmane.org/find-root.php?message_id=%3c4090243E.2040605%40comcast.net%3e>.
+ <teythoon> tschwinge: ugh, thanks for the pointers ;)
+ <tschwinge> teythoon: They won't help too much I fear. Anyway, good
+ intuition (or whatever) ;-) that you found this out.
+ <tschwinge> teythoon: Not exactly related to stripped/unstripped per se
+ (that is, debug information), but in the past we've had an issue about
+ relro (see binutils/glibc, <http://www.airs.com/blog/archives/189>),
+ where a variable (that erroneously happend to be in such a read-only
+ section, if I remember correct) was tried to be modified -- which worked
+ "sometimes": depending on where exactly it was located in the binary
+ (which shifted around a page
+ <tschwinge> boundary by stripped/unstripped), it'd segfault or not. Burnt
+ several days on that before Samuel (IIRC) eventually figured it out.
+ <teythoon> tschwinge: well, thanks anyway ;)
+
+
+## Increased Memory Consumption
+
+### IRC, freenode, #hurd, 2013-09-18
+
+ <braunr> ext2fs is using a ginormous amount of memory on darnassus since i
+ last updated the hurd package :/
+ <braunr> i wonder if my ext2fs large store patches rework have introduced a
+ regression
+ <braunr> the order of magnitude here is around 1.5G virtual space :/
+ <braunr> it used to take up to 3 times less before that
+ <braunr> looks like my patches didn't make it into the latest hurd package
+ <braunr> teythoon: looks like there definitely is a new leak in ext2fs
+ <teythoon> :/
+ <braunr> memory only
+ <braunr> the number of ports looks stable relative to file system usage
+ <teythoon> braunr: I tested my patches on my development machine, it's up
+ for 14 days (yay libvirt :) and never encountered problems like this
+ <braunr> i've been building glibc to reach that state
+ <teythoon> hm, that's a heavy load indeed
+ <teythoon> could be the file name tracking stuff, I tried to make sure that
+ everything is freed, but I might have missed something
+ <braunr> teythoon: simply running htop run shows a slight, regular increase
+ in physical memory usage in ext2fs
+ <pinotree> old procfs stikes again? :)
+ <teythoon> braunr: I see that as well... curious...
+ <braunr> 16:46 < teythoon> could be the file name tracking stuff, I tried
+ to make sure that everything is freed, but I might have missed something
+ <braunr> how knows, maybe completely unrelated
+ <teythoon> the tracking patch isn't that big, I've gone over it twice today
+ and it still seems reasonable to me
+ <braunr> hm
+
+
# Documentation
* <http://e2fsprogs.sourceforge.net/ext2.html>
diff --git a/hurd/translator/fifo.mdwn b/hurd/translator/fifo.mdwn
new file mode 100644
index 00000000..857922fc
--- /dev/null
+++ b/hurd/translator/fifo.mdwn
@@ -0,0 +1,48 @@
+[[!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]]."]]"""]]
+
+The *fifo* translator implements named pipes (FIFOs).
+
+
+# Open Issues
+
+## Not Terminating
+
+[[!tag open_issue_hurd]]
+
+
+### IRC, OFTC, #debian-hurd, 2013-07-28
+
+ <gg0> seems fifos started dying, as they should. am i wrong?
+ <gg0> ( http://bugs.debian.org/629184 )
+ <azeem> so you're saying the bug should be closed?
+ <azeem> best to comment on the bug then
+ <gg0> i didn't hear anyone working on it, so i'm a bit surprised
+ <azeem> could be due to lower-level fixes to glibc or so
+ <gg0> and given often(:|) i'm wrong, i was asking
+ <pinotree> in two years there have been various changes in glibc and hurd
+ <pinotree> (for example the switch to pthreads)
+ <gg0> yeah seems fixed. mknod'ing one then removing it, doesn't leave any
+ process around
+ <gg0> cool
+ <azeem> then please follow-up on the bug and/or close it
+ <gg0> sure
+ <gg0> the pleasure of closing it/them is yours
+ <gg0> great job, whatever you did :)
+
+
+### IRC, OFTC, #debian-hurd, 2013-07-29
+
+ * gg0 wonders if it can close savannah one as
+ wellhttps://savannah.gnu.org/bugs/?17128
+ <pochu> gg0: wdym?
+ <pochu> gg0: got an example?
+ <gg0> http://bugs.debian.org/629184
+ <gg0> i didn't close it myself
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/hostmux.mdwn b/hurd/translator/hostmux.mdwn
index 5fab2dc5..ef16505b 100644
--- a/hurd/translator/hostmux.mdwn
+++ b/hurd/translator/hostmux.mdwn
@@ -29,3 +29,18 @@ When <code>**/ftp**</code> is accessed, the first directory is interpreted as ho
You can see the new created translator in the process list: <code>**ps ax | grep ftpsfs**</code> . You shoud see <code>**/hurd/ftpfs / ftp.yourhost.com**</code> .
-- [[Main/PatrickStrasser]] - 13 Jul 2004
+
+
+# Open Issues
+
+## IRC, freenode, #hurd, 2013-09-21
+
+[[!tag open_issue_hurd]]
+
+ <jproulx> ls /http://<ip>:<port>/
+ <jproulx> the image came with a global translator though I see it doesn't
+ grokk the alternate port notation.
+ <youpi> oh right
+ <jproulx> I shall return to the fine documentation
+ <youpi> it's a hostmux, it doesn't understand ports
+ <youpi> damn, one thus can't url plain urls with that scheme
diff --git a/hurd/translator/httpfs.mdwn b/hurd/translator/httpfs.mdwn
new file mode 100644
index 00000000..dc4a62f7
--- /dev/null
+++ b/hurd/translator/httpfs.mdwn
@@ -0,0 +1,100 @@
+[[!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]]."]]"""]]
+
+`httpfs` is a virtual filesystem allowing you to access web pages and files.
+
+
+# Source
+
+<http://www.nongnu.org/hurdextras/#httpfs>
+
+
+# Documentation
+
+## IRC, freenode, #hurd, 2013-09-03
+
+[[!tag open_issue_documentation]]
+
+ <congzhang> hi, why I can't cd to /http:/richtlijn.be/~larstiq/hurd/ to do
+ <congzhang> grep?
+ <pinotree> this is not ftp
+ <congzhang> it works for other file
+ <pinotree> ?
+ <congzhang> I can't cd to ~larstiq, I don't know why
+ <pinotree> http is not a filesystem protocol
+ <pinotree> while httpfs could try in representing it as such, it is not
+ something reliable
+ <congzhang> ok, it's not reliable
+ <congzhang> I expect it can expose dir like browser
+ <congzhang> so, the translator just know href from home page, and one by
+ one
+ <pinotree> uh?
+ <congzhang> if ...:80/a/b/c.png exits, but not has a href in homepage, so I
+ can't cd to a, right?
+ <pinotree> you are looking things from the wrong point of view
+ <pinotree> a web server can do anything with URLs, including redirecting,
+ URL rewriting and whatever else
+ <congzhang> so, how to understand httpfs's idea?
+ <congzhang> how httpfs list dir?
+ <pinotree> check its code
+ <congzhang> en, no need it's not reliable
+ <congzhang> it's not work, it's enough
+ <congzhang> I have an idea, for the file system, we explore dir level by
+ level, but for http, we change full path one
+ <congzhang> once time
+ <congzhang> maybe can allow user to cd any directory, and just mark as some
+ special color to make user know the translator was not sure, file exist
+ or not
+ <congzhang> once the file exits, mark all the parent directory as normal
+ color?
+ <rekado> congzhang: you can find more info about httpfs here:
+ http://nongnu.org/hurdextras/
+ <pinotree> congzhang: you're still looking at http from the wrong point of
+ view
+ <pinotree> there are no directories nor files
+ <pinotree> you start a request for a URL, and you get some content back (in
+ case there's no error)
+ <congzhang> you mean httpfs just for kidding?
+ <pinotree> that the content is a web page listing a directory on the
+ filesystem of the web server machine, or a file sent back via the
+ connection, or a complex web page, it's the same
+ <rekado> congzhang: you can only get a list of files if the web server
+ responds with an index of files
+ <pinotree> "files"
+ <rekado> The readme explains how httpfs does its thing:
+ http://cvs.savannah.gnu.org/viewvc/*checkout*/httpfs/README?root=hurdextras
+ <congzhang> if I can't cd to /http:/host/a/b how to get
+ /http:/host/a/b/c.html, even the file exist?
+ <pinotree> you don't cd in http
+ <pinotree> cd is for changing directory, which does not apply to a protocol
+ like http which is not fs-oriented
+ <congzhang> yes, I agree with you, http was not fs-oriented
+ <congzhang> so httpfs was not so useful
+ <rekado> You can access the document directly, though, can't you?
+ <congzhang> rekado: I try once more
+ <congzhang> I can't
+ <congzhang> so, the httpfs need some extend, http protocol was not fs
+ oriented, so need some extend to make it work with file system
+ <pinotree> http is not designed for file system usage, so extending it is
+ useless
+ <congzhang> or, httpfs was not so useful
+ <pinotree> there are many other protocols for file systems
+ <congzhang> I don't think so
+ <pinotree> i do
+ <congzhang> if we can't make it more useful, remove it from hurd rep, or
+ extend it more useful
+ <congzhang> add some more rule, to make it work with file system
+ <pinotree> no
+ <congzhang> some paradox in it
+ <pinotree> which paradox?
+ <congzhang> for http vs file system
+ <pinotree> ???
+ <congzhang> tree oriented and star topology oriented?
+ <pinotree> you don't make any sense
diff --git a/hurd/translator/netio.mdwn b/hurd/translator/netio.mdwn
index 12a3f55c..885b1cc0 100644
--- a/hurd/translator/netio.mdwn
+++ b/hurd/translator/netio.mdwn
@@ -11,15 +11,16 @@ License|/fdl]]."]]"""]]
`netio` is a translator designed for creating socket ports through the
filesystem.
+This is supposed to be replaced by the better [[socketio]].
+
# Source
[[source_repositories/incubator]], netio/master
-This is supposed to be replaced by the better socketio.
# Usage:
-e.g.
+For example:
-cat /tmp/netio/tcp/ftp.gnu.org/21
+ $ cat < ~/tmp/netio/tcp/ftp.gnu.org/21
diff --git a/hurd/translator/nsmux.mdwn b/hurd/translator/nsmux.mdwn
index d156772b..6b3be79c 100644
--- a/hurd/translator/nsmux.mdwn
+++ b/hurd/translator/nsmux.mdwn
@@ -1,12 +1,12 @@
-[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2009, 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]]."]]"""]]
# nsmux
@@ -119,3 +119,24 @@ of the simplest use-case of namespace-based translator selection in
the form of translator `nsmux`. The filter is partially implemented
and this is the immediate goal. Propagating translators down
directories is the next objective.
+
+
+## Open Issues
+
+### IRC, freenode, #hurd, 2013-08-22
+
+[[!tag open_issue_hurd]]
+
+ < youpi> err, is nsmux supposed to work at all?
+ < youpi> a mere ls doesn't work
+ < youpi> I'm running it as a user
+ < youpi> echo * does work though
+ < teythoon> ah, yes, nsmux,,is,,funny :p
+ < youpi> well, perhaps but I can't make it work
+ < youpi> well, the trivial ,,hello does work
+ < youpi> but ,,tarfs doesn't seem to be working for instance
+ < youpi> same for ,,mboxfs
+ < youpi> ,,xmlfs seems to somehow work a bit, but not very far...
+ < youpi> so it seems just nobody is caring about putting READMEs wherever
+ appropriate
+ < youpi> e.g. examples in socketio/ ...
diff --git a/hurd/translator/pfinet.mdwn b/hurd/translator/pfinet.mdwn
index f6f69ea4..bf535b21 100644
--- a/hurd/translator/pfinet.mdwn
+++ b/hurd/translator/pfinet.mdwn
@@ -1,5 +1,5 @@
-[[!meta copyright="Copyright © 2002, 2004, 2005, 2007, 2008, 2011 Free Software
-Foundation, Inc."]]
+[[!meta copyright="Copyright © 2002, 2004, 2005, 2007, 2008, 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
@@ -33,6 +33,9 @@ installation.
* [[DHCP]].
+ * [[IPv6]].
+
+ * [[eth-filter]]: Firewall.
+
* [[Implementation]].
- * [[IPv6]].
diff --git a/hurd/translator/pfinet/implementation.mdwn b/hurd/translator/pfinet/implementation.mdwn
index 9bcf62ef..3e66c870 100644
--- a/hurd/translator/pfinet/implementation.mdwn
+++ b/hurd/translator/pfinet/implementation.mdwn
@@ -27,6 +27,170 @@ implementation.
<youpi> oh
<braunr> http://jl-icase.home.comcast.net/~jl-icase/LinuxTCP2.html
+## IRC, freenode, #hurd, 2013-09-03
+
+In context of the item on [[/contributing]].
+
+ <rekado> About this task: "Make pfinet OK with the ethernet device going
+ away." --- how can I test this? How can I remove the ethernet device?
+ <pinotree> settrans on the ethernet device, handled by the netdde
+ translator
+ <pinotree> that is, make it go away (settrans -fg)
+ <rekado> Ah, I see.
+ <rekado> Thanks
+ <pinotree> check its status before with showtrans
+ <pinotree> then, after having made it go away, set it again
+ <rekado> I don't think I'm doing this right... After `settrans -fg
+ /dev/eth0` I should not be able to access the network anymore, but it
+ still works.
+ <rekado> How can I figure out which of the four network devices is actually
+ used?
+ <braunr> rekado: the file system is used to open files, i.e. access
+ services
+ <braunr> it's not used to revoke access
+ <braunr> once pfinet has obtained a port to the network device, it keeps it
+ <rekado> oh, yes, of course. Sorry, this is all very
+ new to me.
+ <rekado> I'm not sure what the problem is that this task describes. In
+ what way is pfinet "not OK" with the ethernet device going away?
+ <braunr> rekado: the idea is to make pfinet able to cope with a driver
+ crash
+ <rekado> Can I trigger a driver crash for test purposes? (Or do I have to
+ build a purposefully broken driver first?)
+ <braunr> use kill
+ <rekado> Oh, good.
+ <braunr> iirc, netdde doesn't restart correctly :x
+ <braunr> you'll probably have to fix it a bit
+ <braunr> i guess there is some persistent state that prevents it from
+ reinitializing correctly
+ <rekado> okay
+ <rekado> I may need one more pointer: where can I find the netdde code?
+ Grep'ing around I only see it only mentioned as an argument to
+ /hurd/devnode; also: should I work in some incubator branch or directly
+ in the hurd repo?
+ <braunr> rekado: incubator branch
+ <rekado> Okay. Thank you for your patience. I'll play with this in the
+ next few days.
+ <braunr> enjoy
+ <rekado> :)
+
+
+### IRC, freenode, #hurd, 2013-09-05
+
+ <rekado> When I kill the /hurd/netdde process I can no longer access the
+ network (as expected);
+ <rekado> To restore connectivity I run "settrans -g eth0 /hurd/devnode -M
+ /dev/netdde eth0" from the /dev directory.
+ <rekado> When I access the network again everything is fine. (I do see a
+ message telling me "irq handler 11: release an dead delivery port"
+ <rekado> )
+ <rekado> Is it the goal to avoid having to run settrans again to run netdde
+ after it crashes or is killed?
+ <youpi> you don't need to run settrans again
+ <youpi> that should get triggered automatically
+ <rekado> Hmm, after killing netdde I get "Resource lost" when using wget.
+ <rekado> It doesn't seem to be restarted automatically.
+ <youpi> try again
+ <youpi> the first wget makes pfinet try to use netdde and fail, thus crash
+ <youpi> the second wil respawn pfinet
+ <youpi> ideally pfinet shouldn't die, that's a TODO mentioned in the
+ "contributing page"
+ <rekado> Ah, so that's what should be prevented.
+ <youpi> it's just a matter of making pfinet be fine with errors from the
+ eth translator, and simply reopen it instead of dying
+ <rekado> That's the thing I've been trying to figure out.
+ <rekado> when I run wget a second (or third) time I get a different error;
+ "Name or service not known."
+ <rekado> It's only okay again when I use settrans
+ <youpi> maybe the devnode translator also needs some fixing
+ <youpi> it's odd that I don't have the issue though
+ <rekado> I'm using the qemu image, updated just yesterday.
+ <youpi> same here
+ <youpi> anyway, now you know where to put your hands :)
+ <rekado> yes, thanks a lot.
+
+
+### IRC, freenode, #hurd, 2013-09-07
+
+ <rekado> in pfinet/ethernet.c:ethernet_open there's an assertion:
+ edev->ether_port == MACH_PORT_NULL
+ <rekado> This is violated when netdde was killed and the device is
+ reopened.
+ <rekado> I'm not sure what should be done: destroy the port before
+ reopening or drop the assertion?
+ <rekado> If I drop the assertion, Mach seems to handle this just fine.
+ <rekado> Says "irq handler 11: release an [sic] dead delivery port" and
+ then carries on without problems.
+ <rekado> Is this a warning or an error, or can this be ignored?
+ <rekado> (or none of the above?)
+
+
+### IRC, freenode, #hurd, 2013-09-08
+
+ <rekado> I have a simple patch for pfinet that lets it recover from an
+ error in ethernet_xmit when /hurd/netdde and /hurd/devnode have been
+ killed.
+ <rekado> It doesn't work, though, when only netdde has been killed.
+ <rekado> With devnode still around device_open fails with "(ipc/send)
+ invalid destination port"
+ <rekado> I don't know where device_open is defined and why this error is
+ returned.
+ <rekado> I guess the error refers to the "master_device" port returned by
+ file_name_lookup() in ethernet_open()
+ <rekado> Why would file_name_lookup() return an invalid port when netdde is
+ dead but devnode is still running?
+ <braunr> rekado: maybe because devnode needs to perform a fresh lookup as
+ well
+
+
+### IRC, freenode, #hurd, 2013-09-09
+
+ <rekado> braunr: re devnode: devnode only performs a single lookup in
+ parse_opt(), i.e. at start-up.
+ <rekado> I'll try to understand devnode enough to patch it.
+ <braunr> rekado: that's the problem
+ <braunr> it should perform a lookup every time it's opened
+
+[[!message-id "1378730237-8091-1-git-send-email-rekado@elephly.net"]],
+[[!message-id "1378731824-8928-1-git-send-email-rekado@elephly.net"]].
+
+ <rekado> I submitted two patches to the mailing list. I've tested them on
+ Debian GNU/Hurd but based them on the incubator/dde branch.
+ <teythoon> rekado: awesome, reliability fixes are very much welcome
+
+
+### IRC, freenode, #hurd, 2013-09-18
+
+ <rekado> youpi: my apologies for the delay in getting back to you with
+ improvements to my pfinet/devnode patches. Been very busy.
+ <braunr> rekado: development pace on the hurd has always been slow, no need
+ to apologize
+
+## MAC Addresses
+
+[[!tag open_issue_hurd]]
+
+
+### IRC, freenode, #hurd, 2013-09-21
+
+ <jproulx> what command will show me the MAC address of an interface?
+ <youpi> ah, too bad inetutils-ifconfig doesn't seem to be showing it
+ <youpi> I don't think we already have a tool for that
+ <youpi> it would be a matter of patching inetutils-ifconfig
+
+
+## Routing Tables
+
+[[!tag open_issue_hurd]]
+
+
+### IRC, freenode, #hurd, 2013-09-21
+
+ <jproulx> Hmmm, OK I can work around that, what about routing tables, can I
+ see them? can I add routes besides the pfinet -g default route?
+ <youpi> I don't think there is a tool for that yet
+ <youpi> it's not plugged inside pfinet anyway
+
# Reimplementation, [[!GNU_Savannah_task 5469]]
@@ -58,3 +222,6 @@ implementation.
<youpi> I used it for the stubdomains in Xen
<youpi> (it = lwip)
<braunr> ok
+
+Cloudius OSv apparently have isolated/re-used a BSD networking stack,
+<http://www.osv.io/>, <https://github.com/cloudius-systems/osv>.
diff --git a/hurd/translator/pflocal.mdwn b/hurd/translator/pflocal.mdwn
index dc2434dc..fdcc39f1 100644
--- a/hurd/translator/pflocal.mdwn
+++ b/hurd/translator/pflocal.mdwn
@@ -1,13 +1,35 @@
-[[!meta copyright="Copyright © 2000, 2008 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2000, 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 implementation of the `pflocal` server is in the `pflocal` directory, and
uses [[`libpipe`|libpipe]] (shared code with the [[named_pipe|fifo]]
implementation).
+
+
+# Open Issues
+
+## `SO_REUSEADDR`
+
+### IRC, freenode, #hurd, 2013-09-19
+
+ <gnu_srs> Hi, is SO_REUSEADDR supported at all on Hurd? I can only find two
+ entries:
+ <gnu_srs> in libdde-linux26 and pfinet/linux-src, and the functionality
+ seems to be unimplemented.
+ <pinotree> gnu_srs: pfinet supports it
+ <youpi> gnu_srs: grep talks about pfinet/linux-src/net/core/sock.c:
+ case SO_REUSEADDR:
+ <youpi> two times
+ <gnu_srs> Yes, and that is the implementation?
+ <gnu_srs> I wrote a test for AF_INET and it works, but not for AF_UNIX
+ (maybe not so interesting case).
+ <pinotree> pflocal does not support it
+ <gnu_srs> Is that of interest at all?
diff --git a/hurd/translator/proc.mdwn b/hurd/translator/proc.mdwn
new file mode 100644
index 00000000..d5e0960c
--- /dev/null
+++ b/hurd/translator/proc.mdwn
@@ -0,0 +1,75 @@
+[[!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
+
+
+## IRC, freenode, #hurd, 2013-09-13
+
+ <braunr> teythoon: also, as a feature request, i'd like the proc server not
+ to have pid 0, if you have any time to do that
+ <braunr> so it appears in top and friends
+ <teythoon> braunr: noted, that should be easy
+ <teythoon> not using 0 is probably a good thing, many things use pid 0 as
+ something special
+
+
+# Process Discovery
+
+## IRC, freenode, #hurd, 2013-08-26
+
+ < teythoon> somewhat related, I do not like the way the proc server just
+ creates processes for new mach tasks it discovers
+ < teythoon> that does not play well with subhurds for example
+ < braunr> teythoon: i agree with you on proc process-to-task mapping
+ < braunr> that's something i intend to completely rework on propel
+ < braunr> in a way similar to how pid namespaces work on linux
diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn
index d26f05f9..44b8cc77 100644
--- a/hurd/translator/procfs/jkoenig/discussion.mdwn
+++ b/hurd/translator/procfs/jkoenig/discussion.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation,
+[[!meta copyright="Copyright © 2010, 2011, 2012, 2013 Free Software Foundation,
Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -14,12 +14,13 @@ License|/fdl]]."]]"""]]
[[!toc]]
-# Miscellaneous
+# `/proc/version`
-IRC, #hurd, around September 2010
+[[!taglink open_issue_documentation]]: edit and move to [[FAQ]].
+
+
+## IRC, freenode, #hurd, around 2010-09
- <youpi> jkoenig: is it not possible to provide a /proc/self which points at
- the client's pid?
<pinotree> (also, shouldn't /proc/version say something else than "Linux"?)
<youpi> to make linux tools work, no :/
<youpi> kfreebsd does that too
@@ -33,10 +34,103 @@ IRC, #hurd, around September 2010
<youpi> Linux version 2.6.16 (des@freebsd.org) (gcc version 4.3.5) #4 Sun
Dec 18 04:30:00 CET 1977
<pinotree> k
- <giselher> I had some problems with killall5 to read the pid from /proc, Is
- this now more reliable?
- <youpi> I haven't tested with jkoenig's implementation
- [...]
+
+
+## IRC, freenode, #hurd, 2013-06-04
+
+ <safinaskar> ?@?#@?$?@#???!?!?!?!??!?!?!?! why /proc/version on gnu system
+ reports "Linux version 2.6.1 (GNU 0.3...)"?
+ <braunr> safinaskar: because /proc/version is a linux thing
+ <braunr> applications using it don't expect to see anything else than linux
+ when parsing
+ <braunr> think of it as your web brower allowing you to set the user-agent
+ <safinaskar> braunr: yes, i just thought about user-agent, too
+ <safinaskar> braunr: but freebsd doesn't report it is linux (as well as i
+ know)
+ <braunr> their choice
+ <braunr> we could change it, but frankly, we don't care
+ <safinaskar> so why "uname" says "GNU" and not "Linux"?
+ <braunr> uname is posix
+ <braunr> note that /proc/version also includes GNU and GNU Mach/Hurd
+ versions
+ <safinaskar> if some program read the word "Linux" from /proc/version, it
+ will assume it is linux. so, i think it is bad idea
+ <braunr> why ?
+ <safinaskar> there is no standard /proc across unixen
+ <braunr> if a program reads /proc/version, it expects to be run on linux
+ <safinaskar> every unix implement his own /proc
+ <safinaskar> so, we don't need to create /proc which is fully compatible
+ with linux
+ <braunr> procfs doesn't by default
+ <safinaskar> instead, we can make /proc, which is partially compatible with
+ linux
+ <braunr> debiansets the -c compatibility flag
+ <braunr> that's what we did
+ <safinaskar> but /proc/version should really report kernel name and its
+ version
+ <braunr> why ?
+ <braunr> (and again, it does)
+ <safinaskar> because this is why /proc/version created
+ <pinotree> no?
+ <braunr> on linux, yes
+ <braunr> pinotree: hm ?
+ <safinaskar> and /proc/version should not contain the "Linux" word, because
+ this is not Linux
+ <braunr> pinotree: no to what ? :)
+ <braunr> safinaskar: *sigh*
+ <braunr> i explained the choice to you
+ <pinotree> safinaskar: if you are using /proc/version to get the kernel
+ name and version, you're doing bad already
+ <braunr> disagree if you want
+ <braunr> but there is a point to using the word Linux there
+ <pinotree> safinaskar: there's the proper aposix api for that, which is
+ uname
+ <safinaskar> pinotree: okey. so why we ever implement /proc/version?
+ <braunr> it's a linux thing
+ <braunr> they probably wanted more than what the posix api was intended to
+ do
+ <safinaskar> okey, so why we need this linux thing? there is a lot of
+ linux thing which is useful in hurd. but not this thing. because this
+ is not linux. if we support /proc/version, we should not write "Linux"
+ to it
+ <pinotree> and even on freebsd their linprocfs (mounted on /proc) is not
+ mounted by default
+ <braunr> 10:37 < braunr> applications using it don't expect to see anything
+ else than linux when parsing
+ <braunr> 10:37 < braunr> think of it as your web brower allowing you to set
+ the user-agent
+ <braunr> safinaskar: the answer hasn't changed
+ <safinaskar> pinotree: but they don't export /proc/version with "Linux"
+ word in it anyway
+ <pinotree> safinaskar: they do
+ <safinaskar> pinotree: ??? their /proc/version contain Linux?
+ <pinotree> Linux version 2.6.16 (des@freebsd.org) (gcc version 4.6.3) #4
+ Sun Dec 18 04:30:00 CET 1977
+ <kilobug> safinaskar: it's like all web browsers reporting "mozilla" in
+ their UA, it may be silly, but it's how it is for
+ compatibility/historical reasons, and it's just not worth the trouble of
+ changing it
+ <pinotree> that's on a debian gnu/kfreebsd machine
+ <pinotree> and on a freebsd machine it is the same
+ <braunr> safinaskar: you should understand that parsing this string allows
+ correctly walking the rest of the /proc tree
+ <pinotree> and given such filesystem on freebsd is called "linprocfs", you
+ can already have a guess what it is for
+ <kilobug> safinaskar: saying "Linux version 2.6.1" just means "I'm
+ compatible with Linux 2.6.1 interfaces", like saying "Mozilla/5.0 (like
+ Gecko)" in the UA means "I'm a modern browser"
+ <safinaskar> so, is there really a lot of programs which expect "Linux"
+ word in /proc/version even on non-linux platforms?
+ <braunr> no
+ <braunr> but when they do, they do
+
+
+# `/proc/self`
+
+## IRC, freenode, #hurd, around 2010-09
+
+ <youpi> jkoenig: is it not possible to provide a /proc/self which points at
+ the client's pid?
<pinotree> looks like he did 'self' too, see rootdir_entries[] in rootdir.c
<youpi> but it doesn't point at self
<antrik> youpi: there is no way to provide /proc/self, because the server
@@ -56,10 +150,13 @@ IRC, #hurd, around September 2010
<youpi> it "just" needs to be commited :)
<antrik> in either case, it can't hurt to bring this up again :-)
+[[community/gsoc/project_ideas/mtab/discussion]], *IRC, freenode, #hurd,
+2013-09-07*.
+
# root group
-IRC, #hurd, around October 2010
+## IRC, freenode, #hurd, around October 2010
<pinotree> the only glitch is that files/dirs have the right user as
owner, but always with root group
@@ -67,7 +164,7 @@ IRC, #hurd, around October 2010
# `/proc/[PID]/stat` being 400 and not 444, and some more
-IRC, freenode, #hurd, 2011-03-27
+## IRC, freenode, #hurd, 2011-03-27
<pochu> is there a reason for /proc/$pid/stat to be 400 and not 444 like on
Linux?
@@ -112,7 +209,8 @@ IRC, freenode, #hurd, 2011-03-27
/proc uses rather than rely on CLK_TCK
<jkoenig> (so we can choose whatever reasonable value we want)
-IRC, freenode, #hurd, 2011-03-28
+
+## IRC, freenode, #hurd, 2011-03-28
<antrik> jkoenig: does procfs expose any information that is not available
to everyone through the proc server?...
@@ -165,7 +263,8 @@ IRC, freenode, #hurd, 2011-03-28
<antrik> (though I never got around to look at his buggy code...)
<jkoenig> ok
-IRC, freenode, #hurd, 2011-07-22
+
+## IRC, freenode, #hurd, 2011-07-22
<pinotree> hm, why /proc/$pid/stat is 600 instead of 644 of linux?
<jkoenig> pinotree, it reveals information which, while not that sensitive,
@@ -186,7 +285,7 @@ IRC, freenode, #hurd, 2011-07-22
# `/proc/mounts`, `/proc/[PID]/mounts`
-IRC, freenode, #hurd, 2011-07-25
+## IRC, freenode, #hurd, 2011-07-25
< pinotree> jkoenig: btw, what do you think about providing empty
/proc/mounts and /proc/$pid/mounts files?
@@ -206,17 +305,34 @@ IRC, freenode, #hurd, 2011-07-25
i don't remember)
< pinotree> not a strict need
+See also [[community/gsoc/project_ideas/mtab]].
+
-# `/proc/[PID]/auxv`, `/proc/[PID]/exe`, `/proc/[PID]/mem`
+## IRC, freenode, #hurd, 2013-09-20
+
+ <pinotree> teythoon: should procfs now have $pid/mounts files pointing to
+ ../mounts?
+ <teythoon> pinotree: probably yes
+
+
+# `/proc/[PID]/auxv`
Needed by glibc's `pldd` tool (commit
11988f8f9656042c3dfd9002ac85dff33173b9bd).
-# `/proc/self/exe`
+# `/proc/[PID]/exe`
+
+Needed by glibc's `pldd` tool (commit
+11988f8f9656042c3dfd9002ac85dff33173b9bd).
+
+
+## `/proc/self/exe`
[[!message-id "alpine.LFD.2.02.1110111111260.2016@akari"]]. Needed by glibc's
`stdlib/tst-secure-getenv.c`.
+`HAVE_PROC_SELF_EXE` in `[GCC]/libjava/configure.ac`.
+Also used in `[GCC]/libgfortran/runtime/main.c`:`store_exe_path`.
Is it generally possible to use something like the following instead?
Disadvantage is that every program using this needs to be patched.
@@ -314,32 +430,25 @@ This is used in `[LLVM]/lib/Support/Unix/Path.inc`.
report why the test suite failed
-# `/proc/[PID]/cwd`
+## `/proc/self/maps`
-## IRC, freenode, #hurd, 2012-06-30
-
- * pinotree has a local work to add the /proc/$pid/cwd symlink, but relying
- on "internal" (but exported) glibc functions
+`HAVE_PROC_SELF_MAPS` in `[GCC]/libjava/configure.ac`.
+Also used in `[GCC]/intl/relocatable.c`:`find_shared_library_fullname` for
+`#ifdef __linux__`.
-# "Unusual" PIDs
+# `/proc/[PID]/mem`
-Not actually related to procfs, but here seems to be a convenient place for
-filing these:
-
-
-## IRC, freenode, #hurd, 2012-08-10
+Needed by glibc's `pldd` tool (commit
+11988f8f9656042c3dfd9002ac85dff33173b9bd).
- <braunr> too bad the proc server has pid 0
- <braunr> top & co won't show it
+# `/proc/[PID]/cwd`
-## IRC, OFTC, #debian-hurd, 2012-09-18
+## IRC, freenode, #hurd, 2012-06-30
- <pinotree> youpi: did you see
- https://enc.com.au/2012/09/careful-with-pids/'
- <pinotree> ?
- <youpi> nope
+ * pinotree has a local work to add the /proc/$pid/cwd symlink, but relying
+ on "internal" (but exported) glibc functions
# CPU Usage
diff --git a/hurd/translator/socketio.mdwn b/hurd/translator/socketio.mdwn
index 99a28416..de5cf252 100644
--- a/hurd/translator/socketio.mdwn
+++ b/hurd/translator/socketio.mdwn
@@ -11,15 +11,36 @@ License|/fdl]]."]]"""]]
`socketio` is a translator designed for creating socket ports through the
filesystem.
+This is supposed to replace [[netio]].
+
# Source
[[source_repositories/incubator]], socketio/master
-This is supposed to replace netio.
# Usage:
-e.g.
+For example:
+
+ $ cat < ~/tmp/socketio/tcp/ftp.gnu.org/21
+
+
+# Open Issues
+
+## IRC, freenode, #hurd, 2013-06-30
+
+[[!tag open_issue_hurd]]
-cat /tmp/socketio/tcp/ftp.gnu.org/21
+ <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
diff --git a/hurd/translator/ufs.mdwn b/hurd/translator/ufs.mdwn
new file mode 100644
index 00000000..4d611e95
--- /dev/null
+++ b/hurd/translator/ufs.mdwn
@@ -0,0 +1,38 @@
+[[!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]]."]]"""]]
+
+The `ufs` translator supports some kind of the Unix File System. Beware, we're
+not aware of anybody having used/tested it in ages, so maybe it is very broken
+and will eat your data.
+
+
+# IRC, freenode, #hurd, 2013-08-30
+
+[[!tag open_issue_hurd]]
+
+ <Arne`> There might be a copyright problem: <nalaginrut> well, there seems
+ BSD-4clauses in the code:
+ http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/ufs/alloc.c
+ <Arne`> braunr, tschwinge: Do you have any info on that? 4-clause BSD and
+ GPL on the same code are a license incompatibility…
+ <tschwinge> Arne`: I've put it onto my (long) TODO list.
+ <tschwinge> Easiest solution might be: rm -rf ufs.
+ <nalaginrut> will these affected code rewritten? or just modify license?
+ <mark_weaver> only the regents of the University of California could choose
+ to modify the license.
+ <youpi> nalaginrut: one can't modify a licence if one is not the author
+ <youpi> we can simply dump the code
+ <mark_weaver> s/author/owner/
+ <tschwinge> As I suppose ufs is unused/untested for a decade or so, I'd
+ have no issues with simply removing it from the tree, together with
+ ufs-fsck and ufs-utils.
+ <pinotree> tschwinge: or maybe extract the ufs stuff in an own repo, to be
+ imported as branch in incubator or own hurd/ufs.git?
+ <tschwinge> Sure, why not.
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-18 21:52:56 +0000