the standard way of passing file descriptors is by fork/exec.
this allows security is handled by the normal means.
Erik/others, would you please give some feedback on my idea (a join call which
connects two fds together and disowns them from the process). Passing fds
around does not solve the
ours is still on its way, from globalscale tech.
They took at least 3 weeks to ship our order.
Finally they did, but as I said, still on the way, despite
choosing a good delivery. But that may be only when
you buy from europe.
On Sat, Dec 5, 2009 at 7:29 AM, Don Bailey don.bai...@gmail.com wrote:
Mine I bougth some months ago, also from globalscale. They took more
than one month to ship it, but after their notice about the shipment,
it came in two days. It came in a nice packaging box, with all the
cables, and a CD with the source code.
2009/12/5 Francisco J Ballesteros n...@lsub.org:
On Sat Dec 5 03:11:09 EST 2009, s...@nipl.net wrote:
the standard way of passing file descriptors is by fork/exec.
this allows security is handled by the normal means.
Erik/others, would you please give some feedback on my idea (a join call which
connects two fds together and disowns them
On Sat Dec 5 00:12:53 EST 2009, lyn...@orthanc.ca wrote:
Where FD passing is useful is to avoid that fork/exec overhead.
Sorry -- brain in neutral. Where FD passing wins BIG is that the front-end
process doesn't have to do copy-through of all the data between the
network and the back-end
On Sat, Dec 05, 2009 at 08:26:20AM -0500, erik quanstrom wrote:
if you don't need to modify the data futher, then exec the guy who
does.
This is my issue - when I want to exec, too much of the request data has
already been read. I don't want to be calling read(fd, buf, 1) in a loop.
I would
i wonder if there's a complicated volume pricing thing going on where these
companies take orders, accumulating volume so they increase their margins
before they ship. I can't imagine why else they'd drag their feet on it
except that they want to get a good price as a reseller, and don't want to
David Leimbach wrote:
i wonder if there's a complicated volume pricing thing going on where
these companies take orders, accumulating volume so they increase their
margins before they ship. I can't imagine why else they'd drag their
feet on it except that they want to get a good price as a
On Fri, Dec 4, 2009 at 10:29 PM, Don Bailey don.bai...@gmail.com wrote:
So, what is everyone's preferred plug vendor? Out of the three, is there a
preference for people out there hacking on the Sheeva?
Thanks,
I'm sticking with globalscale because they deliver the daughter board
too, and you
On Sat, Dec 5, 2009 at 3:44 AM, Francisco J Ballesteros n...@lsub.org wrote:
If you insist on 'unreading', you could just put a front-end process that
keeps per-request data so that your external process can ask the
front-end for all the data again.
The easiest way to implement unread is not
On Sat, Dec 5, 2009 at 8:26 AM, ron minnich rminn...@gmail.com wrote:
I'm sticking with globalscale because they deliver the daughter board
too, and you have to have that board for debug.
Although, once this all works, I want to by a bunch, rip the board out
of the plug module, stack them up
I mostly agree, but, if you read one char at a time it's likely you'll
become quite
slow, in general. An external process providing `buffering' so you can
seek back if you want, seems to me like a more general solution that does
not require a kernel change.
In any case, if I gave the impression
So, what is everyone's preferred plug vendor? Out of the three, is there a
preference for people out there hacking on the Sheeva?
i ordered through globalscale; 2-3 weeks to ship and a few more days
for delivery. week 2 of waiting.
High volume == affordable, even if not optimal.
The SheevaPlug is just not quite into that range
the volume demand is coming from companies that bundle it with their
home automation, entertainment center and other products. it seems
there's at least one company trying out every
On Sat, Dec 5, 2009 at 9:01 AM, Francisco J Ballesteros n...@lsub.org wrote:
I mostly agree, but, if you read one char at a time it's likely you'll
become quite
slow, in general.
Absolutely right. It's very application dependent. But for an httpd, I
doubt that this slowness would matter.
On Sat, Dec 5, 2009 at 9:09 AM, Skip Tavakkolian 9...@9netics.com wrote:
So, what is everyone's preferred plug vendor? Out of the three, is there a
preference for people out there hacking on the Sheeva?
i ordered through globalscale; 2-3 weeks to ship and a few more days
for delivery. week 2
I would like to pass the extra buffered data to the guy I am execing then let
him read the rest directly from the socket, but I see no existing way to do
that.
httpd passes the headers and any left over buffer it has already read to /magic
apps through a command line param. there's a function
So, I honestly haven't been paying enough attention to Sheeva and Gumstix.
What does everyone think about hacking on both of these? Which one is the
easier platform to develop on/for? While Sheeva is substantially faster,
Gumstix has more interesting expansion cards. I'd love to hear some
I can see two possible solutions for this, both of which would be useful in my
opinion:
- an unread function, like ungetc, which allows a program to put back some
data that was already read to the OS stdin buffer (not the stdio buffer).
This might be problematic if there is a limit to the
I can see two possible solutions for this, both of which would be useful in
my
opinion:
- an unread function, like ungetc, which allows a program to put back
some
data that was already read to the OS stdin buffer (not the stdio
buffer).
This might be problematic if there is a limit to
The OS support I am talking about:
a) the fork behavior on an open file should be available
*without* forking. dup() doesn't cut it (both fds share
the same offset on the underlying file). I'd call the new
syscall fdfork(). That is, if I do
int newfd = fdfork(oldfd);
On Sat, 05 Dec 2009 15:03:44 EST erik quanstrom quans...@quanstro.net wrote:
The OS support I am talking about:
a) the fork behavior on an open file should be available
*without* forking. dup() doesn't cut it (both fds share
the same offset on the underlying file). I'd call the new
To be precise, both fds have their own pointer (or offset)
and reading N bytes from some offset O must return the same
bytes.
wrong. /dev/random is my example.
- erik
I ordered an openrd-client from globalscale and it arrived within
a few days. It's the same SoC (Kirkwood) as the Sheevaplug, but more
(perhaps all) of the connectors are made available, plus vga output for $250.
Looking at mine, I see connectors for 7 usb 2 ports, 2 Gb ethernets,
esata, SMbus,
On Sat, 05 Dec 2009 15:27:02 EST erik quanstrom quans...@quanstro.net wrote:
To be precise, both fds have their own pointer (or offset)
and reading N bytes from some offset O must return the same
bytes.
wrong. /dev/random is my example.
You cut out the bit about buffering where I
Hello,
I've come around a nice hardware to do VM stuff on, so i installed a Debian
xen host (amd64 hypervisor and dom0) on it, and then started to play with
plan9. I followed the
http://www.9grid.fr/wiki/plan9/installing_in_xen_3.0/index.html document to
set up the guest, but right when i try
Sorry, i forgot to add i used the pae version of everything, which got me this
far, the normal versions of the xen9 kernel wouldn't boot on amd64
John Soros sor...@gmail.com wrote on Saturday 05 December 2009
Hello,
I've come around a nice hardware to do VM stuff on, so i installed a Debian
On Sat, Dec 05, 2009 at 12:59:34PM -0800, Bakul Shah wrote:
You cut out the bit about buffering where I explained what I meant.
Your idea seems good, so long as the OS buffers data and keeps it around until
all readers have consumed it there would be no problem. This would be another
possible
28 matches
Mail list logo
