I've rewritten my proposal based on some feedback from the mailing list. Once again, more about the proposal and myself can be found off Google's website at:
http://www.cs.utah.edu/~jstratto/soc_hurd/ I really liked the paper Pierre referenced and think a modular approach with client-based memory management would provide a great network stack for Hurd being fault-tolerant, secure, and modular with negligible performance penalty. If those interested in the network stack could read my new proposal, I'd like to get some additional feedback as to how I could refine this idea. 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]. > > > > 1. > > http://www.cs.jhu.edu/~sarat/usenix-net-2004.ps<http://www.cs.jhu.edu/%7Esarat/usenix-net-2004.ps> > > > > Having a capability-oriented network stack would be great, BTW. > > > Thanks, Pierre. That was an interesting paper. I would love to implement > this kind of implementation for Google SoC, even though it's a bit more > complicated than I imagined. They seemed to get some great benefits for > only minor drops in peak bandwidth. Their actual implementation doesn't > seem unfeasible. The idea of having clients handle resources seems very > different to me, but provide some incredible advantages. I think it would > need some additional helper library could encapsulate a bit of this on the > client side if the developer chose to. Would this type of implementation be > something you guys would want to see as a Google Summer of Code? > > Thanks, > Josh > > > > > > Quickly, > > Pierre > > -- > > [EMAIL PROTECTED] > > OpenPGP 0xD9D50D8A > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.6 (GNU/Linux) > > > > iD8DBQFH6q7Pxe13INnVDYoRAjAXAKDnHiuXTlAIguilg7fs/b6Os0BokQCfTcTQ > > xOQ4ujb355LholWcOvBBw4Q= > > =5MAz > > -----END PGP SIGNATURE----- > > > > >
