Date: Fri, 07 Mar 2003 22:47:16 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Damien Tougas <damien@tougas.net> Cc: Andrew Boothman <andrew@cream.org>, John Baldwin <jhb@FreeBSD.org>, freebsd-chat@freebsd.org Subject: Re: A question about kernel modules Message-ID: <3E6991F4.F8A10E3A@mindspring.com> References: <XFMail.20030307152559.jhb@FreeBSD.org> <3E69329B.2040803@cream.org> <200303072246.18636.damien@tougas.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Damien Tougas wrote: > On Friday 07 March 2003 07:00 pm, Andrew Boothman wrote: > > >Nope. cdboot loads up a /boot/loader and you are free to load > > >whatever modules you want off the CD just as if you were booting > > >from a hard drive. That said, I personally favor static kernels > > >and only use modules when I'm testing things. > > > > I guess this is really the nub of the question. > > > > Why do you "personally favour" static kernels over modules? > > Yes, that really is the question. I have traditionally always done the same, > compiling everything into my kernel. I guess I am wondering what the point of > kernel modules are, and if they are considered to be a stable, viable way of > 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. 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. 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.. The fact that the API contracts are not as fixed as they should be adds to the uncertainty (e.g. there is no DDI or DKI, as such, in FreeBSD). Basically, it's not really "ready for prime time", in terms of third party binary-only modules, which is the most interesting use for them, by far. > > I, like you, tend to compile everything into my kernel but that's more > > out of habit than for any other reason as I have been compiling kernels > > since about 2.2.7 which I think pre-dates kernel modules. > > I don't know much about the technology behind kernel modules, but I get the > sense that people get used to doing things a certain way, and stick with it > because it is what they have always done, regardless if there is another way > (even if it might be technically better - although I am in no position to be > the judge of that in this situation). If something's in the kernel, proper, I'm guaranteed it woun't have a problem loading, so that when I need it, it will be there. With a module, theres an element of risk, due to reasons stated previously, and the reasons above. > >From a convenience standpoint, kernel modules seem much more practical to me. > > I like the idea of being able to load/unload device drivers, etc. at runtime. > I, however, have no idea what the impact is on things like stability and > performance. 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. -- Terry 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?3E6991F4.F8A10E3A>