Merge remote-tracking branch 'fp/master'

Conflicts:
	open_issues/secure_file_descriptor_handling.mdwn

1 files changed, 164 insertions, 0 deletions

diff --git a/hurd/translator/pfinet/implementation.mdwn b/hurd/translator/pfinet/implementation.mdwn
index a77f1b10..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]]