diff options
Diffstat (limited to 'hurd/translator/pfinet/implementation.mdwn')
| -rw-r--r-- | hurd/translator/pfinet/implementation.mdwn | 164 |
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 + [1;5C[1;5C[1;5C[1;5Cnew 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]] |