Date: Sat, 08 Mar 2003 08:56:37 +0000 From: Mark Murray <mark@grondar.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: Damien Tougas <damien@tougas.net>, Andrew Boothman <andrew@cream.org>, John Baldwin <jhb@FreeBSD.ORG>, freebsd-chat@FreeBSD.ORG Subject: Re: A question about kernel modules Message-ID: <200303080856.h288ubIg021994@grimreaper.grondar.org> In-Reply-To: Your message of "Fri, 07 Mar 2003 22:47:16 PST." <3E6991F4.F8A10E3A@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert writes: > > configuring my kernel. If there are good reasons why I should not use them > > (or not use them in specific situations), I would be intersted in knowing > > what those are. > > The dependency tracking sucks, and so does demand-loading. If > you look at the module code with the idea of loading *at least > one* ethernet driver before you could load IP, and having to > load IP before you could load TCP, and then look at the code to > see what this would take, you will be enlightened. 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. Other tweaks would need to be done if you need IPX instead of IP. > There are also certain options which cause structure sizes to > change, which are associated with particular things. As an > example, the IPSEC stuff can't really be modularized, because > there's per connection state that has to be there for it to > be happy. Possibly. > Another issue having to do with structure size is that if the > module you are trying to load was not compiled with the same > options as the kernel you are trying to load it into, even if > all the version stuff matches, including the proposed new > versioning data, the structure sizes expected by the module > and by the kernel can be different. A good example of this is > something like "WITNESS" or "INVARIANTS", etc.. Hmm. Maybe its time for a export of certain compile-time options. > The normal performance cost is all interfaces being indirected > through a pointer. For most interfaces, this overhead is there > anyway, so that all access is uniform. For other things, like > schedulers, for example, the functions are linked directly, so > they have to be resolved at compile time. Certian things (like the scheduler) would be harder to make into modules. This is true. 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?200303080856.h288ubIg021994>