From c4ad3f73033c7e0511c3e7df961e1232cc503478 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 26 Feb 2014 12:32:06 +0100 Subject: IRC. --- hurd/translator/pfinet/implementation.mdwn | 180 ++++++++++++++++++++++++++++- 1 file changed, 179 insertions(+), 1 deletion(-) (limited to 'hurd/translator/pfinet') diff --git a/hurd/translator/pfinet/implementation.mdwn b/hurd/translator/pfinet/implementation.mdwn index 3e66c870..7b2f07aa 100644 --- a/hurd/translator/pfinet/implementation.mdwn +++ b/hurd/translator/pfinet/implementation.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2000, 2008, 2013 Free Software Foundation, +[[!meta copyright="Copyright © 2000, 2008, 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -166,6 +166,14 @@ In context of the item on [[/contributing]]. rekado: development pace on the hurd has always been slow, no need to apologize + +### IRC, freenode, #hurd, 2014-02-12 + + youpi: btw, the patch you finally decided to write yourself making + pfinet continue on driver failure is as expected quite handy :) + :) + + ## MAC Addresses [[!tag open_issue_hurd]] @@ -192,6 +200,82 @@ In context of the item on [[/contributing]]. it's not plugged inside pfinet anyway +## IRC, freenode, #hurd, 2014-01-15 + + 2014-01-14 23:06:38 IPv4 socket creation failed: Computer bought + the farm + :O + hum :) + perhaps related with your change for "lo" performance? + unlikely + I don't see what would have changed in pfinet otherwise + mig generated code if i'm right + lib*fs + libfshelp + looks plenty enough + teythoon's output has been quite high, it's not so suprising to + spot such integration issues + + +### IRC, freenode, #hurd, 2014-01-16 + + teythoon: so, did you see we have bugs on the latest hurd packages + :) + for some reason, exim4 starts nicely on darnassus, but not on + another test vm + and there is a "deallocate invalid name" error at boot time + it's also present with your packages + yes + + not being able to start exim4 and other servers on some machines, + apparently randomly, is a bit frightening to me + as the message says, "most probably a bug" + yes + so we have to get rid of it as soon as possible so we can get to + the more interesting stuff + but there is no way to attribute this message to a process + well, for those at boot time, there is + ? + if i disable exim, i don't get it :p + oh ? + but again, it doesn't occur on all machines + and that part is the one i don't like at all + still, is it in exim, pfinet, pflocal, ... ? + no way to answer that + ah right sorry + it's probably pfinet, since exim says computer bought the farm on + a socket + pflocal had its same pid + ok + and after an upgrade, i don't reproduce that + good, in a way + there still is the one, after auth + yes + i'm seeing that too + (as in "exec init proc auth" + shouldn't be too hard to fix + i'll settle on this one after i'm done with libps + (15:21:34) braunr: it's probably pfinet, since exim says computer + bought the farm on a socket: + remember my having problems with removing a socket file, maybe + related, probably not pfinet then? + gnu_srs: unlikely + that pfinet bug may have been completely transient + fixed by upgrading packages + braunr: k! + + and exim4 keeps crashing on my hurd instance at home + (pfinet actually) + uh, ok, a stupid typo .. + teythoon: --natmask in the /servers/socket/2 node, but correct + options in the 26 one .... :) + + +### IRC, freenode, #hurd, 2014-01-17 + + braunr: *phew* + + # Reimplementation, [[!GNU_Savannah_task 5469]] ## [[community/gsoc/project_ideas/tcp_ip_stack]] @@ -205,6 +289,10 @@ In context of the item on [[/contributing]]. hm, why not i would still prefer using code from netbsd especially now with the rump kernel project making it even easier + +[[open_issues/user-space_device_drivers]], *External Projects*, *The Anykernel +and Rump Kernels*. + well, whatever is easy to maintain up to date actually netbsd's focus on general portability normally makes it easy to maintain @@ -225,3 +313,93 @@ In context of the item on [[/contributing]]. Cloudius OSv apparently have isolated/re-used a BSD networking stack, , . + + +## IRC, freenode, #hurd, 2014-02-06 + + Hello Everyone! Just set up my Hurd system. I need some help + now, in selecting a project on which i can work, and delving further into + this. + akshay1994: what are you interested in ? + I was going through the project ideas. Found TCP/IP Stack, and + CD Audio grabbing interesting. + cd audio grabbing ? + hm why not + akshay1994: you have to understand that, when it come to drivers, + we prefer reusing existing implementations in contained servers than + rewriting ourselves + the networking stack project would be very interesting, yes + Yes. I was indeed reading about the network stack. + So we need an easily modularise-able userspace stack, which we + can run as a server for now. + And split into different protocol layers later. + hum no + we probably want to stick to the model we're currently using with + pfinet + for network drivers, yes + i strongly suspect we want the whole IPv4/IPv6 networking stack in + a single server + and writing glue code so that it works on the hurd + then, you may want to add hooks for firewall/qos/etc... + (although i think qos should be embedded to) + sjbalaji: i also suggest reusing the netbsd networking stack, + since netbsd is well known for its clean portable code, and it has a + rather large user base (compared to us or other less known projects) and + is well maintained + the rump project might make porting even easier + +[[open_issues/user-space_device_drivers]], *External Projects*, *The Anykernel +and Rump Kernels*. + + okay! I was reading the project idea, where they mention that + a true hurdish stack will use a set of translator processes , each + implementing a different protocol layer + a true hurdish stack would + i strongly doubt we'll ever have the man power to write one + i don't really see the point either to be honest :/ + haha! + but others have better vision than me for these things so i don't + know + So, what are the problems we are facing with the current + pfinet implementation? + it's old + meaning it doesn't implement some features that may be important, + and has a few bugs due to lack of maintenance + maintenance here being updating the code base with a newer + version, and we don't particularly want to continue grabbing code from + linux 2.2 :) + I see. I was just skimming through google, about userspace + network stacks, but I think I might need to first understand how the + current one works and interacts with the system, before proceeding + further! + yes + the very idea of a userspace stack itself has little implications + it basically means it doesn't run in system mode, and instead of + directly calling functions, it uses RPCs to communicate with other parts + of the system + + braunr: I looked at the netBSD net-stack, and also how hurd + (and mach) work. I'm starting with the hacking guide. Seems a little + difficult :p + But i feel, I'll get over it. Any tips? + akshay1994: it's not straightforward + I know. Browsing through pfinet gave me an idea, how complex a + thing I'm trying to deal with in first try :p + + +### IRC, freenode, #hurd, 2014-02-09 + + braunr: the point of a hurdisch network stack is the same as a + hurdish block layer, and in fact anything hurdish: you can do things like + tunelling in a natural manner, rather than needing special loopback code + and complex control interfaces + antrik: i don't see how something like the current pfinet would + prevent that + + +# IRC, freenode, #hurd, 2013-10-31 + + looks like there is a deadlock in pfinet + maybe triggered or caused by my thread destruction patch + +[[open_issues/libpthread/t/fix_have_kernel_resources]]. -- cgit v1.2.3