Date: Mon, 10 Mar 2003 16:19:33 +0000 From: Mark Murray <mark@grondar.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: freebsd-chat@FreeBSD.ORG Subject: Re: A question about kernel modules Message-ID: <200303101619.h2AGJXIg027470@grimreaper.grondar.org> In-Reply-To: Your message of "Mon, 10 Mar 2003 07:33:27 PST." <3E6CB047.5D517419@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert writes:
> > That is not the way you would do it. Each Ethernet module would
> > require IP, which in turn would co-require TCP and co-require UDP
> > etc. If you tried to load IP with no ethernet driver, you'd get
> > the loopback device, and TCP/UDP etc.
>
> You've sort of got that backward, I think. I can have all sorts
> of protocols that *aren't* TCP that run on top of IP, and I can
> have all sorts of protocols that aren't IP that run over an
> ethernet interface.
Still, I made the point that some dependancies run "backwards".
> The ethernet interface might just be a promiscuous mode interface,
> with a BPF sitting on top of it, and nothing else (for example),
> or that Novell answer to the lack of a sliding window in SPX,
> TCP/IPX, might be an option, too.
So look at it as a "Provides" vs "needs" thing. Loading an ethernet
card will premptively get you all the modules needed to abstract the
general class of network interfaces.
> The point is that it's all about producer/consumer relationships,
> and consumers need producers, but not the other way around.
Yes, but the production direction meets somewhere in the middle.
Example (where 'A->B' implies 'B needs what A produces'):
NICa -> ethernet.card.driver -> network.abstraction <- IP <- TCP
^ ^ ^
NICb -> ethernet.card.driver ---+ | +----UDP
|
loopback.device ----------+
and so on. This is at the module dependancy level, so DONT look at this
as a sockets programmer and find layering faults at the ISO layer model
level, it is NOT an ISO network stack diagram.
It means that the network.abstaction is a kind of nexus on which
the loadable modules can attach while creating a complete networking
subsystem in the kernel.
> > Other tweaks would need to be done if you need IPX instead of IP.
>
> Yes. The direct calls to ip_output() would need to be indirected
> through the PCB, so it could be properly stacked. That's just a
> minimal thing, though.
It is not as simple as a stack, for module dependancies. But yes,
it is not hard to provide the dependancy hooks.
> I can demonstrate this one. The real problem with IPSEC in the
> TCP/IPv4 case is that it was poorly retrofit from the KAME code
> into the IPv4. This caused a number of problems, one of which
> was your total number of connections supportable shrunk *a lot*
> when you enabled IPSEC, even if none of your connections were
> using it (we had done this for VPN support).
Assertion, not demonstration.
> > Hmm. Maybe its time for a export of certain compile-time options.
>
> You mean as sysctl's? Or you mean in an exported options file?
Anything that works.
M
--
Mark Murray
iumop ap!sdn w,I idlaH
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200303101619.h2AGJXIg027470>