Waldemar Kornewald wrote:
Roman Kurakin wrote:
Of course, I will send progress reports on this list. We at Haiku
would really appreciate working together with the FreeBSD team.
By the way, what kind of hardware you are using?
Currently, it is nothing special, just a Dual-Celeron 466 (since I
ga
Roman Kurakin wrote:
Of course, I will send progress reports on this list. We at Haiku
would really appreciate working together with the FreeBSD team.
By the way, what kind of hardware you are using?
Currently, it is nothing special, just a Dual-Celeron 466 (since I gave
my other computer to my
Waldemar Kornewald wrote:
George V. Neville-Neil wrote:
One other model to look at is The Click Modular Router, which is about
modularizing the routing part of the code, as opposed to the end
station code. Look at http://www.xorp.org because Click, and FreeBSD
are in there.
Thanks, this is really
George V. Neville-Neil wrote:
One other model to look at is The Click Modular Router, which is about
modularizing the routing part of the code, as opposed to the end
station code. Look at http://www.xorp.org because Click, and FreeBSD
are in there.
Thanks, this is really interesting.
I have always
At Wed, 6 Oct 2004 18:23:17 +0200,
Max Laier wrote:
> Given the additional locking requirements and the additional checks, lookups
> and function calls I hardly believe that it is a good idea. There might be
> protocols that are easily plugged, but you can certainly do them at the
> netgraph lay
On Wed, Oct 06, 2004 at 07:30:43PM +0300, Petri Helenius wrote:
> Garrett Wollman wrote:
>
> >< ><[EMAIL PROTECTED]> said:
> >
> >>Yes, something in that direction, plus: protocols:
> >>IPv4, IPv6, TCP, UDP, ICMP, IPX, etc.
> >>Just about everything as modules.
> >
> >It is not generally regarded
Garrett Wollman wrote:
< said:
Yes, something in that direction, plus: protocols:
IPv4, IPv6, TCP, UDP, ICMP, IPX, etc.
Just about everything as modules.
It is not generally regarded as a good idea to make artificial
boundaries between (e.g.) IP and TCP.
However from the success of the O
< said:
> Yes, something in that direction, plus: protocols:
> IPv4, IPv6, TCP, UDP, ICMP, IPX, etc.
> Just about everything as modules.
It is not generally regarded as a good idea to make artificial
boundaries between (e.g.) IP and TCP.
-GAWollman
__
On Wednesday 06 October 2004 17:19, Waldemar Kornewald wrote:
> Hi,
> are there any plans to mularize the netstack (maybe: protocol+interface
> modules)?
> Would it be difficult to modularize it?
One problem you will hit here, is that you will have to do a lot of additional
locking for structures
Hi,
Roman Kurakin wrote:
are there any plans to mularize the netstack (maybe:
protocol+interface modules)?
You mean smth like (device driver)+ng_cisco+ng_iface or what?
Yes, something in that direction, plus: protocols:
IPv4, IPv6, TCP, UDP, ICMP, IPX, etc.
Just about everything as modules.
Bye,
Hi,
Waldemar Kornewald wrote:
Hi,
are there any plans to mularize the netstack (maybe:
protocol+interface modules)?
You mean smth like (device driver)+ng_cisco+ng_iface or what?
rik
Would it be difficult to modularize it?
I am also interested in your opinion about it:
Does it make sense to modular
Hi,
are there any plans to mularize the netstack (maybe: protocol+interface
modules)?
Would it be difficult to modularize it?
I am also interested in your opinion about it:
Does it make sense to modularize the netstack? Why would a
monolithic/modular netstack be better?
We at Haiku are inclined
On Tue, Jul 31, 2001 at 11:46:09AM -0700, Brooks Davis wrote:
> I've updated the patch to fix a bug in ether_input and wrap
> vlan_input(_tag) in marcos to enable locking later. This patch also
> reflects the latest fixes to the txp driver. I've included it below or
> you can find it at:
>
> ht
I've updated the patch to fix a bug in ether_input and wrap
vlan_input(_tag) in marcos to enable locking later. This patch also
reflects the latest fixes to the txp driver. I've included it below or
you can find it at:
http://people.freebsd.org/~brooks/patches/vlan.diff
Apply the patch as befo
Please review and test the following patch. It adds cloning support to
vlan devices and allows loading and unloading of VLAN support. The
downside of the this loadability is that it currently appears to require
enabling VLAN support on NICs that support it all the time which I am
concerned may h
15 matches
Mail list logo
