From owner-freebsd-chat Mon Mar 10 8:20:49 2003 Delivered-To: freebsd-chat@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B5A037B401 for ; Mon, 10 Mar 2003 08:20:47 -0800 (PST) Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.157.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F57E43FB1 for ; Mon, 10 Mar 2003 08:20:46 -0800 (PST) (envelope-from mark@grondar.org) Received: from storm.FreeBSD.org.uk (Ugrondar@localhost [127.0.0.1]) by storm.FreeBSD.org.uk (8.12.7/8.12.7) with ESMTP id h2AGKjIo044731; Mon, 10 Mar 2003 16:20:45 GMT (envelope-from mark@grondar.org) Received: (from Ugrondar@localhost) by storm.FreeBSD.org.uk (8.12.7/8.12.7/Submit) with UUCP id h2AGKjrZ044730; Mon, 10 Mar 2003 16:20:45 GMT X-Authentication-Warning: storm.FreeBSD.org.uk: Ugrondar set sender to mark@grondar.org using -f Received: from grondar.org (localhost [127.0.0.1]) by grimreaper.grondar.org (8.12.7/8.12.7) with ESMTP id h2AGJXIg027470; Mon, 10 Mar 2003 16:19:33 GMT (envelope-from mark@grondar.org) From: Mark Murray Message-Id: <200303101619.h2AGJXIg027470@grimreaper.grondar.org> To: Terry Lambert Cc: freebsd-chat@FreeBSD.ORG Subject: Re: A question about kernel modules In-Reply-To: Your message of "Mon, 10 Mar 2003 07:33:27 PST." <3E6CB047.5D517419@mindspring.com> Date: Mon, 10 Mar 2003 16:19:33 +0000 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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