Re: hurd internet through qemu

On Thu, May 1, 2008 at 5:36 AM, Joshua Stratton <[EMAIL PROTECTED]> wrote: > On Thu, May 1, 2008 at 12:07 AM, Shakthi Kannan <[EMAIL PROTECTED]> > wrote: > > > Hi, > > > > --- On Thu, May 1, 2008 at 2:59 AM, Joshua Stratton > > <[EMAIL PROTECTED]&

Re: hurd internet through qemu

On Thu, May 1, 2008 at 12:07 AM, Shakthi Kannan <[EMAIL PROTECTED]> wrote: > Hi, > > --- On Thu, May 1, 2008 at 2:59 AM, Joshua Stratton > <[EMAIL PROTECTED]> wrote: > | Does anyone using the Hurd through qemu find the networking a little > flaky? > \-- &

Re: hurd internet through qemu

; <http://bddebian.com/~wiki/mailing_lists/<http://bddebian.com/%7Ewiki/mailing_lists/> > >. > Please keep discussions on public mailing lists, see > <http://bddebian.com/~wiki/community/communication/<http://bddebian.com/%7Ewiki/community/communication/> > >. >

Re: client-side memory buffers

> > > Do you think the client-side > > memory model is worthwhile? And would the server allocating the memory > > passing it to the client using the Mach semantics allow this client-side > > memory model while avoiding the ability for clients to unmap the > > data? > > Yes, I think such accounting

Re: client-side memory buffers

On Wed, Apr 2, 2008 at 12:25 AM, Neal H. Walfield <[EMAIL PROTECTED]> wrote: > At Tue, 1 Apr 2008 18:01:25 -0600, > Joshua Stratton wrote: > > On Tue, Apr 1, 2008 at 3:50 PM, Neal H. Walfield <[EMAIL PROTECTED]> > wrote: > > > > > Please don't to

Re: client-side memory buffers

On Tue, Apr 1, 2008 at 3:50 PM, Neal H. Walfield <[EMAIL PROTECTED]> wrote: > Please don't top post. > > At Tue, 1 Apr 2008 10:48:02 -0600, > Joshua Stratton wrote: > > > > The problem you described was the client owning the memory object, > sending > >

Re: client-side memory buffers

On Tue, Apr 1, 2008 at 12:32 PM, Pierre THIERRY < [EMAIL PROTECTED]> wrote: > Scribit Joshua Stratton dies 01/04/2008 hora 10:48: > > The problem you described was the client owning the memory object, > > sending it to the server, and the server having the ability to unmap &

Re: Hurdish TCP stack (was: updated proposal)

at 9:20 AM, Richard Braun <[EMAIL PROTECTED]> wrote: > On Tue, Apr 01, 2008 at 08:07:23AM -0600, Joshua Stratton wrote: > > > It's clearly a mistake to map the directory tree to the protocols > stack. > > > The TCP implementation is a global layer, it handles n

Re: client-side memory buffers

2008 08:11:30 -0600, > Joshua Stratton wrote: > > On Tue, Apr 1, 2008 at 2:28 AM, Neal H. Walfield <[EMAIL PROTECTED]> > wrote: > > > The problem is exactly the same as that with L4's data spaces. When > > > the server maps and accesses the memory obje

Re: client-side memory buffers

On Tue, Apr 1, 2008 at 2:28 AM, Neal H. Walfield <[EMAIL PROTECTED]> wrote: > At Mon, 31 Mar 2008 21:23:41 -0600, > Joshua Stratton wrote: > > > > I was on the irc channel talking about the feasibility using client-side > > memory buffers for a new network stack.

Re: Hurdish TCP stack (was: updated proposal)

> > > > I think this approach would fit nicely into the Hurd's translator > > architecture. However, I'm not sure if I like the directory structure > they > > use. I would think the network interface should be shown like > > > > /net/eth0/tcp/2 > > > > It might be worthwhile--but possible bad sty

Re: client-side memory buffers

On Mon, Mar 31, 2008 at 9:23 PM, Joshua Stratton <[EMAIL PROTECTED]> wrote: > I was on the irc channel talking about the feasibility using client-side > memory buffers for a new network stack. Based on some feedback about > difficulties of implementing this in the Hurd, I thou

Re: Hurdish TCP stack

> > Supposedly all network connections use this interface (TCP, UDP, LP). > > What is LP?... LP is a special protocol written by the Plan9 team that is something in between TCP and UPD. They wanted a reliable stream but as fast as UDP and a few other benefits. They said TCP was too slow. I'm

client-side memory buffers

I was on the irc channel talking about the feasibility using client-side memory buffers for a new network stack. Based on some feedback about difficulties of implementing this in the Hurd, I thought I would ask anyone if they thought this would be especially difficult--particularly Marcus and Neal

Re: Hurdish TCP stack (was: updated proposal)

interface should be shown like /net/eth0/tcp/2 It might be worthwhile--but possible bad style?--to duplicate both hierachies so on may browse the connections by device or generally. Any preferences/comments on this? Josh On Mon, Mar 31, 2008 at 10:42 AM, Joshua Stratton <[EMAIL PROTECT

hurd internet through qemu

I have followed few pages of setting up the Hurd's network through qemu, however it seems that eth0 is never configured on boot so the following command breaks because no eth0 device has been configured. # settrans -afgp /servers/socket/2 /hurd/pfinet -i eth0 -a 10.0.2.15 -g 10.0.2.2 -m 255.255.25

Re: Hurdish TCP stack (was: updated proposal)

Hey, I did some reading up on the Plan9 design for their network hierarchy. I think it's interesting. I wouldn't mind using it just so the layout would be more commonplace (for those who may have used Plan9). I also like the access to the interface statistics. Plan9, from what I've read, tries

Re: updated proposal

I thought a directory structure might be a more intuitive interface. It doesn't matter too much to me, as long as it stays intuitive down the road. I guess since it's really only going to implement two layers of the OSI model, it doesn't matter. A list might be more accessible. Thanks for the fe

updated proposal

Olaf made some comments on my proposal and wanted to know a bit more about my actual implementation in the Hurd itself. I've done added a bit more to the proposal to explain what I feel is a good implementation. Basically, I was thinking the network stack could be divided into different translato

Re: tcp/ip rewrite for summer of code

ity of the individual protocols would be a great fit for Hurd. Josh http://www.cs.utah.edu/~jstratto/soc_hurd/<http://www.cs.utah.edu/%7Ejstratto/soc_hurd/> On Thu, Mar 27, 2008 at 5:23 AM, Joshua Stratton <[EMAIL PROTECTED]> wrote: > I've rewritten my proposal based on some

Re: tcp/ip rewrite for summer of code

. Josh On Wed, Mar 26, 2008 at 9:05 PM, Joshua Stratton <[EMAIL PROTECTED]> wrote: > > > As far as security and efficiency is concerned, I highly recommend > > reading 'Network Subsystems Reloaded: A High-Performance, Defensible > > Network Subsystem'[1]. >

Re: tcp/ip rewrite for summer of code

> > > As far as security and efficiency is concerned, I highly recommend > reading 'Network Subsystems Reloaded: A High-Performance, Defensible > Network Subsystem'[1]. > > 1. > http://www.cs.jhu.edu/~sarat/usenix-net-2004.ps > > Having a capabil

tcp/ip rewrite for summer of code

Hello, I recently entered a proposal for the TCP/IP rewrite for Google's Summer of Code. I would like to invite anyone who has access as a mentor to check it out. For those of you who don't, I put the details of the proposal, my planned schedule, my experience, and my interests on an external we