On Mon, 2006-01-16 at 21:09 -0800, David S. Miller wrote:
> From: Willem de Bruijn <[EMAIL PROTECTED]>
> Date: Mon, 16 Jan 2006 09:21:18 +0100
>
> > true, it's not new. The reason I ended up with it was purely practical and
> > even grew out of a single-module system. Streams fitted our use-case,
> The only paper i know of that sort of mentions stackable dst (this years
> after they existed) was in OLS 2-3 years back where they are mentioned
> in conjunction with
"Linux IPv6 Networking, [...]":
http://archive.linuxsymposium.org/ols2003/Proceedings/All-Reprints/Reprint-Yoshifuji-OLS2003.pd
On Tue, 2006-17-01 at 13:29 +0100, Willem de Bruijn wrote:
> Stackable routes are interesting, and indeed
> simple. They are miles apart from my work, and certainly not innovative. They
> are interesting to this discussion, however.
>
Depends on your definition of innovative - seems you draw
> I'm talking about stackable routes, which is in the destination
> cache and is at the core of how all routing works in the Linux
> kernel.
I misunderstood you there. Stackable routes are interesting, and indeed
simple. They are miles apart from my work, and certainly not innovative. They
are i
From: Willem de Bruijn <[EMAIL PROTECTED]>
Date: Tue, 17 Jan 2006 11:55:44 +0100
> About your remark: I have studied linux networking so far as it has
> crossed my path. IPSEC, the only place for which XFRM is being used
> it seems, was scheduled for later. You don't expect to see a
> different fr
> But you haven't even studied how the Linux networking works, so how
> would you know? I guess time is better spent reinventing the wheel.
> Since you don't know, by definition you're spewing. You don't know
> the Linux networking, and therefore you don't know whether existing
> mechanisms can s
From: Willem de Bruijn <[EMAIL PROTECTED]>
Date: Mon, 16 Jan 2006 09:21:18 +0100
> true, it's not new. The reason I ended up with it was purely practical and
> even grew out of a single-module system. Streams fitted our use-case, which
> is to run code in userspace, kernelspace and on the networ
On Mon, 2006-16-01 at 09:21 +0100, Willem de Bruijn wrote:
> The reason I ended up with it was purely practical and
> even grew out of a single-module system. Streams fitted our use-case, which
> is to run code in userspace, kernelspace and on the network-card.
> Communicating across 3 environm
> in that case i misunderstood - your example seems to be talking about
> functional packet processing "nodes" and how you connect them in a
> graph. At least thats where the streams connotation seems to have come
> in. And again my take is the fundamental ability to specify instances of
> those no
John Que wrote:
Hello,
I wonder if can anybody can say what is the advantages/disadvantages
of the linux networking kernel layer comapred to STREAMS network layer
(of Solaris for examples).
From my experience up to day , I am used to it that the Linux took the best
of all worlds. I don't k
On Mon, 2006-16-01 at 00:05 +0100, Willem de Bruijn wrote:
> > Well, if you are doing research you need to know whats out there so
> > you can a) learn from it b) avoid reinventing the wheel
>
> That speaks for itself. I'm not completely ignorant and have read most that
> has been published at de
> Well, if you are doing research you need to know whats out there so
> you can a) learn from it b) avoid reinventing the wheel
That speaks for itself. I'm not completely ignorant and have read most that
has been published at decent venues. Thing is, I don't find such publications
about innovati
On Sun, 2006-15-01 at 21:21 +0100, Willem de Bruijn wrote:
> > Your lack of knowledge about netfilter shows very clearly here.
>
> Again, I never stated that netfilter is a purely functional framework.
> Although my lack of netfilter indeed is unfortunate, it is of no direct
> concern.
>
> > H
> Linux TCP/IP doesn't work like this.
I never said it did, I said that *functional frameworks* worked like this. For
the most part I believe Linux TCP/IP does work like this, though. I'll skip
routing when making this point.
Although Linux has indirect function calls to choose between a TCP a
On Sunday 15 January 2006 12:50, Willem de Bruijn wrote:
> int tcp(char * pkt, int plen){
> if (!ip(pkt, plen))
> return -1;
> //[... process tcp stuff ..]
> return 0;
> }
Linux TCP/IP doesn't work like this.
> Why do people keep developing stream-like architectur
On Sun, Jan 15, 2006 at 12:50:38PM +0100, Willem de Bruijn ([EMAIL PROTECTED])
wrote:
> >I wonder if can anybody can say what is the advantages/disadvantages
> > of the linux networking kernel layer comapred to STREAMS network layer
> > (of Solaris for examples).
>
> hi John,
>
> I'll take a
>I wonder if can anybody can say what is the advantages/disadvantages
> of the linux networking kernel layer comapred to STREAMS network layer
> (of Solaris for examples).
hi John,
I'll take a stab at this question, since I'm working on a stream-like
framework in/op top of Linux anyway. Firs
17 matches
Mail list logo
