Interesting read:
http://cacm.acm.org/magazines/2009/6/28495-whither-sockets/fulltext
If I am right, the filesystem based networking interface offered by Plan 9
has the three limitations discussed here:
* performance overhead: app requesting data from a socket typically needs
to perform 2 syste
First off, I really am a big fan of filesystem interfaces as used in Plan
9 - after all my PhD work was based on the model :)
My objective here is to debate and understand how the points made in the
paper relate to the Plan9 networking model.
* performance overhead: app requesting data from a s
Did you do this on Plan 9 or bring some of the filesystem sanity of another OS?
Actually my work was based on 9P based synthetic filesystems
implemented using Npfs (see
http://docs.google.com/Doc?id=dcb7zf48_503q8j84)
These filesystems resided in resource constrained embedded devices which
perhaps you think this is doging the question, but the cannonical
plan 9 approach to this is to note that it's easy (trivial) to have a n
reader threads and m worker threads s.t. i/o threads don't block
I'll agree. With multi threading the network read/write operations
could be pipelined to m
do you have a comparison to other similar projects like
1. styx on a brick
http://www.vitanuova.com/inferno/rcx_paper.html
2. 9p for imbedded devices
http://iwp9.inf.uth.gr/iwp9_proceedings08.pdf
and or other information on your work? in particular,
what hardware are you using?
I am trying to understand the end objective of
the JTAG work discussed in one of the threads last week (sorry, I'm behind on my mails!).
There was one response that said: "The hope is that it would help debug
usb/bt device issues on kw."; but beyond this I could not make out the use
case for thi
I am not sure this fits into a /proc kind of interface because
JTAG lets you access the bare hardware. Nemo has just pointed to me
that a process is not the
same as a running kernel, and maybe the abstraction does not fit that
well.
Often cross debugging of embedded systems does not take place o
