summaryrefslogtreecommitdiff
path: root/hurd/translator/pfinet
diff options
context:
space:
mode:
Diffstat (limited to 'hurd/translator/pfinet')
-rw-r--r--hurd/translator/pfinet/implementation.mdwn172
1 files changed, 171 insertions, 1 deletions
diff --git a/hurd/translator/pfinet/implementation.mdwn b/hurd/translator/pfinet/implementation.mdwn
index 77162d8a..31432788 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
@@ -53,6 +53,82 @@ implementation.
<youpi> it's not plugged inside pfinet anyway
+## IRC, freenode, #hurd, 2014-01-15
+
+ <braunr> 2014-01-14 23:06:38 IPv4 socket creation failed: Computer bought
+ the farm
+ <braunr> :O
+ <youpi> hum :)
+ <youpi> perhaps related with your change for "lo" performance?
+ <braunr> unlikely
+ <youpi> I don't see what would have changed in pfinet otherwise
+ <braunr> mig generated code if i'm right
+ <braunr> lib*fs
+ <braunr> libfshelp
+ <braunr> looks plenty enough
+ <braunr> teythoon's output has been quite high, it's not so suprising to
+ spot such integration issues
+
+
+### IRC, freenode, #hurd, 2014-01-16
+
+ <braunr> teythoon: so, did you see we have bugs on the latest hurd packages
+ :)
+ <braunr> for some reason, exim4 starts nicely on darnassus, but not on
+ another test vm
+ <braunr> and there is a "deallocate invalid name" error at boot time
+ <braunr> it's also present with your packages
+ <teythoon> yes
+
+ <braunr> not being able to start exim4 and other servers on some machines,
+ apparently randomly, is a bit frightening to me
+ <braunr> as the message says, "most probably a bug"
+ <teythoon> yes
+ <braunr> so we have to get rid of it as soon as possible so we can get to
+ the more interesting stuff
+ <teythoon> but there is no way to attribute this message to a process
+ <braunr> well, for those at boot time, there is
+ <teythoon> ?
+ <braunr> if i disable exim, i don't get it :p
+ <teythoon> oh ?
+ <braunr> but again, it doesn't occur on all machines
+ <braunr> and that part is the one i don't like at all
+ <teythoon> still, is it in exim, pfinet, pflocal, ... ?
+ <teythoon> no way to answer that
+ <braunr> ah right sorry
+ <braunr> it's probably pfinet, since exim says computer bought the farm on
+ a socket
+ <braunr> pflocal had its same pid
+ <teythoon> ok
+ <braunr> and after an upgrade, i don't reproduce that
+ <braunr> good, in a way
+ <braunr> there still is the one, after auth
+ <teythoon> yes
+ <teythoon> i'm seeing that too
+ <braunr> (as in "exec init proc auth"
+ <braunr> shouldn't be too hard to fix
+ <braunr> i'll settle on this one after i'm done with libps
+ <gnu_srs> (15:21:34) braunr: it's probably pfinet, since exim says computer
+ bought the farm on a socket:
+ <gnu_srs> remember my having problems with removing a socket file, maybe
+ related, probably not pfinet then?
+ <braunr> gnu_srs: unlikely
+ <braunr> that pfinet bug may have been completely transient
+ <braunr> fixed by upgrading packages
+ <gnu_srs> braunr: k!
+
+ <braunr> and exim4 keeps crashing on my hurd instance at home
+ <braunr> (pfinet actually)
+ <braunr> uh, ok, a stupid typo ..
+ <braunr> teythoon: --natmask in the /servers/socket/2 node, but correct
+ options in the 26 one .... :)
+
+
+### IRC, freenode, #hurd, 2014-01-17
+
+ <teythoon> braunr: *phew*
+
+
# Reimplementation, [[!GNU_Savannah_task 5469]]
## [[community/gsoc/project_ideas/tcp_ip_stack]]
@@ -66,6 +142,10 @@ implementation.
<braunr> hm, why not
<braunr> i would still prefer using code from netbsd
<braunr> especially now with the rump kernel project making it even easier
+
+[[open_issues/user-space_device_drivers]], *External Projects*, *The Anykernel
+and Rump Kernels*.
+
<youpi> well, whatever is easy to maintain up to date actually
<braunr> netbsd's focus on general portability normally makes it easy to
maintain
@@ -86,3 +166,93 @@ implementation.
Cloudius OSv apparently have isolated/re-used a BSD networking stack,
<http://www.osv.io/>, <https://github.com/cloudius-systems/osv>.
+
+
+## IRC, freenode, #hurd, 2014-02-06
+
+ <akshay1994> 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.
+ <braunr> akshay1994: what are you interested in ?
+ <akshay1994> I was going through the project ideas. Found TCP/IP Stack, and
+ CD Audio grabbing interesting.
+ <braunr> cd audio grabbing ?
+ <braunr> hm why not
+ <braunr> akshay1994: you have to understand that, when it come to drivers,
+ we prefer reusing existing implementations in contained servers than
+ rewriting ourselves
+ <braunr> the networking stack project would be very interesting, yes
+ <akshay1994> Yes. I was indeed reading about the network stack.
+ <akshay1994> So we need an easily modularise-able userspace stack, which we
+ can run as a server for now.
+ <akshay1994> And split into different protocol layers later.
+ <braunr> hum no
+ <braunr> we probably want to stick to the model we're currently using with
+ pfinet
+ <braunr> for network drivers, yes
+ <braunr> i strongly suspect we want the whole IPv4/IPv6 networking stack in
+ a single server
+ <braunr> and writing glue code so that it works on the hurd
+ <braunr> then, you may want to add hooks for firewall/qos/etc...
+ <braunr> (although i think qos should be embedded to)
+ <braunr> 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
+ <braunr> the rump project might make porting even easier
+
+[[open_issues/user-space_device_drivers]], *External Projects*, *The Anykernel
+and Rump Kernels*.
+
+ <akshay1994> 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
+ <braunr> a true hurdish stack would
+ <braunr> i strongly doubt we'll ever have the man power to write one
+ <braunr> i don't really see the point either to be honest :/
+ <akshay1994> haha!
+ <braunr> but others have better vision than me for these things so i don't
+ know
+ <akshay1994> So, what are the problems we are facing with the current
+ pfinet implementation?
+ <braunr> it's old
+ <braunr> meaning it doesn't implement some features that may be important,
+ and has a few bugs due to lack of maintenance
+ <braunr> 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 :)
+ <akshay1994> 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!
+ <braunr> yes
+ <braunr> the very idea of a userspace stack itself has little implications
+ <braunr> 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
+
+ <akshay1994> 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
+ <akshay1994> But i feel, I'll get over it. Any tips?
+ <braunr> akshay1994: it's not straightforward
+ <akshay1994> 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
+
+ <antrik> 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
+ <braunr> antrik: i don't see how something like the current pfinet would
+ prevent that
+
+
+# IRC, freenode, #hurd, 2013-10-31
+
+ <braunr> looks like there is a deadlock in pfinet
+ <braunr> maybe triggered or caused by my thread destruction patch
+
+[[open_issues/libpthread/t/fix_have_kernel_resources]].