Merge remote-tracking branch 'darnassus--hurd-web/master'

Conflicts:
	community/meetings.mdwn
	contributing.mdwn
	hurd/translator/pfinet/implementation.mdwn

4 files changed, 14 insertions, 149 deletions

diff --git a/hurd/porting/guidelines.mdwn b/hurd/porting/guidelines.mdwn
index 6afa46fc..c4c864f7 100644
--- a/hurd/porting/guidelines.mdwn
+++ b/hurd/porting/guidelines.mdwn
@@ -335,6 +335,10 @@ Use <sys/cdrom.h> instead.
 
 This is not actually standard; cfsetspeed, cfsetispeed, or cfsetospeed should be used instead.
 
+## <a name="termios"> IUCLC </a>
+
+IUCLC is a GNU extension. `#define _GNU_SOURCE' thus has to be used to get the definition (even if Linux unconditionally provides it, it should not).
+
 ## <a name="errno"> `errno` values </a>
 
 When dealing with `errno`, you should always use the predefined error codes defined with the `E*` constants, instead of manually comparing/assigning/etc with their values.
diff --git a/hurd/subhurd.mdwn b/hurd/subhurd.mdwn
index 55927fdd..e50ea0d5 100644
--- a/hurd/subhurd.mdwn
+++ b/hurd/subhurd.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2013 Free Software
+[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2013, 2014 Free Software
 Foundation, Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -103,7 +103,9 @@ practice [that doesn't work at the
 moment](http://savannah.gnu.org/bugs/?17341).)
 
 You can provide the subhurd with a network card by passing a `-f` option to
-`boot`.
+`boot`.  For instance, if you have a second network card `/dev/eth1` in your
+host hurd, pass `-f eth0=/dev/eth1` to make it appear as device eth0 in the
+subhurd.
 
 Now the subhurd should boot just like a normal Hurd started directly from GRUB,
 finally presenting a login prompt.  The `boot` program serves as proxy for the
@@ -190,6 +192,9 @@ characteristic thread counts.
       ports from the mother hurd to the subhurd
     <teythoon> so that we could pass in a port to the eth-multiplexer
     <teythoon> or use like /hurd/remap as the root translator for the subhurd
+
+[[open_issues/virtualization/remap_root_translator]].
+
     <braunr> eth-multiplexer was created exactly for that iirc,
     <braunr> so it's probably already done somewhere
 
diff --git a/hurd/translator/mtab/discussion.mdwn b/hurd/translator/mtab/discussion.mdwn
index 6bb446a0..89593436 100644
--- a/hurd/translator/mtab/discussion.mdwn
+++ b/hurd/translator/mtab/discussion.mdwn
@@ -1871,6 +1871,9 @@ In context of [[open_issues/mig_portable_rpc_declarations]].
     <teythoon> *while
     <youpi> yep, they're basically the same
 
+[[open_issues/virtualization/remap_root_translator]],
+[[open_issues/virtualization/fakeroot]].
+
 
 ## IRC, freenode, #hurd, 2013-09-06
 
diff --git a/hurd/translator/pfinet/implementation.mdwn b/hurd/translator/pfinet/implementation.mdwn
index 7b2f07aa..31432788 100644
--- a/hurd/translator/pfinet/implementation.mdwn
+++ b/hurd/translator/pfinet/implementation.mdwn
@@ -27,153 +27,6 @@ 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
-
-
-### IRC, freenode, #hurd, 2014-02-12
-
-    <braunr> youpi: btw, the patch you finally decided to write yourself making
-      pfinet continue on driver failure is as expected quite handy :)
-    <youpi> :)
-
-
 ## MAC Addresses
 
 [[!tag open_issue_hurd]]