tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Thinking about "branes" for netbsd...



On Sat, May 05, 2012 at 09:32:36AM +1000, Darren Reed wrote:
> On 5/05/2012 4:24 AM, Mouse wrote:
> >>> By not stopping at "I can configure this policy", but rather going
> >>> all the way to "No other policy can possibly be configured" I think
> >>> you make the mechanism less generally useful and I'd sort of like to
> >>> see the justification for that.
> >> You're right, it isn't desirable to be so restrictive.
> > 
> > I agree.  It strikes me as rather restrictive to mandate that which
> > routing table is used is tied to which process is responsible for the
> > traffic - especially since sockets can be shared by multiple processes,
> > meaning that either you have to somehow forbid the same socket from
> > appearing in the open file tables of processes using different branes,
> > or you have to tag the data in the socket's send queue with which brane
> > the writing process was in at the time of writing, or you have to
> > attach branes to sockets as well as processes, or you have to make the
> > brane association work only for immediately-sent traffic (eg, UDP but
> > not TCP), or something of the sort.
> 
> It would appear that various people did not fully read what I proposed
> or perhaps misunderstood it. What I wrote is that a brane would become
> an entire instance of networking and that global structures, etc, would
> disappear. If it helps you (or others) to understand it by thinking of
> branes in terms of support for virtual routers then I'm happy for you
> to do so but it is by no means limited to that.

I think we are all finding out that your ideas and enthusiasm for
branes resonate with others' ideas and enthusiasm about similar but
not-quite-alike overhauls of NetBSD networking.  Let's take that
resonance and run with it---not all in different directions, I hope!

There may be less enthusiasm for branes in particular than there is for
multiple routing tables and for a network stack with a more rational
structure.

Dave

-- 
David Young
dyoung%pobox.com@localhost    Urbana, IL    (217) 721-9981


Home | Main Index | Thread Index | Old Index